Open tbolin opened 4 years ago
https://github.com/KTH-SML/motion_capture_system/blob/d5371e8becbddf91530d0d8697c6d4ffac4c00f6/mocap_qualisys/src/QualisysDriver.cpp#L132 The current calculation for the time stampa of a received 6DOF pose does not account for any delay in the link between the QTM server and receiver. Neither does it recognize that the delay can vary. Suggestion 1: Update _start_time_local if a received time would cause the time stamp to lie in the future. Suggestion 2: Add a token delay (around 1 ms) to the timestamp, to compensate for the delay. Suggestion 3: Remove the weird smoothing found here: https://github.com/KTH-SML/motion_capture_system/blob/d5371e8becbddf91530d0d8697c6d4ffac4c00f6/mocap_qualisys/src/QualisysDriver.cpp#L138
Another time smoothing issue in https://github.com/KTH-SML/motion_capture_system/blob/8e4d7737a7c5d13f9d4628d57a129e2ea3806140/mocap_base/src/KalmanFilter.cpp#L113
tbolin
commented
4 years ago tbolin
commented
4 years ago
https://github.com/KTH-SML/motion_capture_system/blob/d5371e8becbddf91530d0d8697c6d4ffac4c00f6/mocap_qualisys/src/QualisysDriver.cpp#L132 The current calculation for the time stampa of a received 6DOF pose does not account for any delay in the link between the QTM server and receiver. Neither does it recognize that the delay can vary. Suggestion 1: Update _start_time_local if a received time would cause the time stamp to lie in the future. Suggestion 2: Add a token delay (around 1 ms) to the timestamp, to compensate for the delay. Suggestion 3: Remove the weird smoothing found here: https://github.com/KTH-SML/motion_capture_system/blob/d5371e8becbddf91530d0d8697c6d4ffac4c00f6/mocap_qualisys/src/QualisysDriver.cpp#L138