in regard to this thread : Running Egomotion Module with realtime sensor data (iteration of the sample) - #10 by ashwin.nanda
I have not received a confirmation on the sync logic.
Dear @ashwin.nanda ,
Is the query to clarified "the fusion depends on sensordatatimestamp which contains a measured timestamp in the payload at an instance, not the arrival time? " Or any other additional query?
dear @SivaRamaKrishnaNV the query was regarding this
“We take the measurement by their timestamp and if the timestamp doesn’t increase or decreases we’ll ignore it.
Between GPS and IMU data, if the measurement from GPS comes with more latency (example: IMU data comes up to timestamp 10s and then a GPS measurement comes at timestamp 9.8s), we will still use the GPS measurement and correctly perform the calculation based on the timestamp from the GPSFrame.”
my question was : just be clear, so the fusion depends on sensordatatimestamp which contains a measured timestamp in the payload at an instance, not the arrival time.
in ref to the example: the gps is lagging by 0.2s because IMU data already has the payload exactly for timestamp and time at t=10s?
@SivaRamaKrishnaNV this is just to clear my sync strategy with a parser for CAN signals, as you mentioned egomotion source code isnt publicly avaialble. I am relying on GPS first sync.
If at t=10, you have IMU data with timestamp t=10 and you have received GPS timestamp with t=9.8. Now you consider GPS measurement in your calculation even though is it is 0.2 lagging in time.
1 Like