Simulator: Delay between Measurement Timestamp and Message Timestamp

[christian-lanius]

Hi everyone,
Thanks for your work on the simulator. I am trying to use it with Apollo 5.0, but I have problems w.r.t. the localization.
The IMU/GPS messages are both reported by Apollo to be offset by a nearly constant number of cycles. Even after running the simulator for half an hour, this value does not change:

and I have a problem with the localization module: There is a timestamp issue between the measurement and the message timestamp:

We can find this same delay in the /apollo/localization/msf_status messages generated by the rtk localization module in Apollo:

We can however increase this delay arbitrarily, simply by pausing the simulation using the pause button in the interactive mode. After continuing the simulation, the delay has increased, not by the total pause time, but approx. proportional to it. We can also increase this delay by resizing the window. Starting the simulator in windows mode, we can click on the border and resize the window, which will increase the delay proportional to the time it took to resize the window.

A second problem, which might or might not, be related to this, is an apparently wrong timestamp in the gps pose topic. Looking at the /apollo/sensor/gnss/corrected_imu and /apollo/sensor/gnss/best_pose topics, the timestamp reported by the /apollo/sensor/gnss/best_pose is completely wrong: It reports (right now) 1255344916.973999977, which corresponds to a date in 2009, for both measurement and header timestamp

while the current unix timestamp is correctly used in the corrected_imu topic. I am not sure how/if this relates to the issue with having a reported offset between the IMU.

It would be great if someone could have a look at this and confirm that the observed timestamp for the gnss is indeed wrong, or if I am misunderstanding anything.

Kind regards,
Christian

[hadiTab]

@christian-lanius I'm currently looking into this and hopefully should have a fix soon.
To give some context, the timestamp 1255344916.973999977 is in the GPS time system and refers to October 17, 2019. It seems like there is a mix up in the time for measurement and timestamp for GPS related topics.

[ntutangyun]

this is a live screenshot I just took.

Thanks to @hadiTab 's explaination, now I understand that the /apollo/sensor/gnss/best_pose is in GPS time system.

however, I'm using Apollo 5.0 fork, and it's clear that /apollo/localization/pose message (published by Localization module) is always several seconds ahead of even the module's input gnss/imu etc.

After creating a separate c++ program as well as CyberRT component only printing out the system timestamp, it turns out that the message from lgsvl simulator actually lags for about 6.9 seconds. The Localization message follows the system timestamp as well as the separate CyberRT component.

I wonder if anyone is encountering same issues ? Thank you.

[ntutangyun]

I changed how simulator manager computes current time and managed to reduce above mentioned lag from 7 seconds to about 0.05 seconds.

below is the update: /Assets/Scripts/Managers/SimulatorManager.cs
```c#
void FixedUpdate()
{
// CurrentTime += Time.fixedDeltaTime;
CurrentTime = (DateTime.UtcNow - unixEpoch).TotalSeconds;
CurrentFrame += 1;

    if (!IsAPI)
    {
        PhysicsUpdate();
    }
}

```
I'm not sure what other problems this would bring. Thus haven't submitted a pull request yet.

Please help verify this. Thanks