Consider packet time in obstacle distance message

[obicons]

This attempts to address the concern that I raised in this issue. I realize this solution might not be perfect, but I hope I can be advised further in this area.

Thanks to developers for their review, and their efforts creating ArduPilot :)

[obicons]

Thank you for your valuable feedback, @magicrub!

Would you suggest adding a function to convert between UTC and time since system boot to AP_RTC? That might be the easiest way to implement the changes.

[magicrub]

Would you suggest adding a function to convert between UTC and time since system boot to AP_RTC?

Have you looked at AP_RTC yet? Using get_utc_usc() will probably work for you as-is. Otherwise, yes. New time conversion helper functions should be added there.

[magicrub]

This still doesn't address the core problem: _last_update_ms is compared against local since-boot time since not all systems have GPS and non have correct UTC time at boot time. So, everyone everywhere would need to convert to this method which is a huge change of complexity.. and then, even if we did that.. then what? That's not changing any behavior here

[obicons]

This still doesn't address the core problem: _last_update_ms is compared against local since-boot time since not all systems have GPS and non have correct UTC time at boot time

The idea is that _last_update_ms stores the local boot time, since that is the only format supported by all platforms. If the received timestamp is in UTC, then we attempt to convert to local boot time. If that cannot be accomplished, we fallback to the previous behavior. API consumers are then able to more reliably check for message staleness. Right now, there is no way to tell how old a message really is, even if the system supports UTC.

[timtuxworth]

Pardon my intrusion, but it strikes me that the way you are calculating the time since boot from the message might be incorrect by (at least) the latency between the time the message was originally sent and the time it is processed on the FC. Maybe it would be better to calculate and store a "time difference between boot time and UTC" - which should be updated each time the clock is updated. Then if you receive a UTC time in a message, calculate the time since boot by subtracting the "time difference between boot time and UTC" from it.

[IamPete1]

I recommend taking a look at the jitter correction code here:

https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_RTC/JitterCorrection.cpp

Its is used to convert between on board and off board time stamps in the GPS driver, and other places.