Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time ref beloning to which measurement #76

Open
Youras opened this issue Sep 30, 2022 · 3 comments
Open

Time ref beloning to which measurement #76

Youras opened this issue Sep 30, 2022 · 3 comments

Comments

@Youras
Copy link

Youras commented Sep 30, 2022

Hello,
I am wondering which sensor time message from time_ref topic belongs to which sensor measurement message.
Should the header.seq. value be compared? or the time of arrival stamped by ros timestamps? Cause there is some difference, e.g. for 100 Hz acceleration measurements, see figure below:

IMU_timestamps_seq

As seen in the figure, the timestamped messages of acc and time_ref are almost simultaneously, is this a coincidence and caused by the delay coming from the analog and/or digital low pass filters for the acc? Since, they differ in the header.seq by a value of two which would lead to a delay of approx. 20 ms.

Could you clarify this and maybe confirm the acc delay? I used the MTi-620 in responsive mode.

Many thanks in advance!

@Steven-GH
Copy link

Hi @Youras,

If your MTi device is configured to output SampleTimeFine (which it should be, as otherwise the imu/time_ref topic would not be published) then the MTi will output all of its Acceleration data samples together with its corresponding SampleTimeFine value, as a single data packet.

Upon arrival of this data packet, the imu/time_ref and imu/acceleration topics are created and the header.seq and header.stamp values are assigned by ROS. Only the time_ref field of the imu/time_ref topic is filled with the SampleTimeFine value.

I am not sure what causes the difference in header.seq value here, but considering the above, if the two topics have the same ROS timestamp then I would expect them also to correspond to each other.

@Youras
Copy link
Author

Youras commented Sep 30, 2022

Thanks. for your fast answer @StevenXsens

Okay if time_ref and acc come with the same data packet, then the delay of the low pass filter shouldn't be measurable this way. I can also confirm that /imu/angular_velocity share the same header.seq value with /imu/time_ref at approx. same ROS time stamp.

I forgot to mention, that above I was comparing with /filter/free_acceleration, not with the raw acc data.

  1. Do time_ref and free_acceleration still come with the same data packet?

  2. Are the digital low pass filters for the accelerometer and the gyroscope the same (and therefore share the same time delay)?

  3. Apart from that, when does the SampleTimeFine function actually stamp the time? In the Output Message Generator? considering the following Block diagram:

IMU_blocks

@Steven-GH
Copy link

Hi @Youras,

Apologies for the delayed response; I was unavailable for the past two weeks.

  1. The time_ref and free_acceleration messages are indeed grouped together as a single data packet. In fact, the time_ref (SampleTimeFine) timestamp is added to every data packet that is sent out by the MTi.
  2. The block diagram you copied here actually does not apply to the MTi-620, but to the MTi 100-series. One of the differences is that the MTi 100-series uses analog accelerometers/gyroscopes whereas the MTi-620 uses digital sensors. Unfortunately I do not have details regarding the low-pass filtering but I can say that we take care of properly synchronizing the accelerometer and gyroscope data.
  3. The SampleTimeFine value represents the time at which each 400 Hz sampling interval starts. The SDI (Strap-Down Integration) block is responsible for this, integrating sensor data sampled at high rates (several kHz depending on your MTi model) down to 400 Hz.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants