Hi Olli & Francisco,
I wasn’t aware of this discussion until now (several months later).
@olliw42 @OXINARF @WickedShell You’re approaching the problem from a wrong mindset. UAVCAN GNSS broadcasters do not need to report their lag to subscribers because the UAVCAN protocol provides built-in means of network-wide time synchronization. The standard GNSS Fix message includes a timestamp that is made in the network-shared time base. If the autopilot is synchronized with the network time base (of course it should be, and it’s easy to do), the lag of each received message can be trivially obtained by subtracting the timestamp of the GNSS message from the timestamp of the moment when the EKF begins processing of the message.
Please observe that unlike the currently used lag-based approach, this is the direct solution of the problem that can be extended towards other sensor feeds, and other data flows. The sensor timestamping approach is widely used in robotics in general. The current lag-based approach is flawed in many ways, most importantly it doesn’t account for the latency of the data bus itself, whereas the proper timestamping approach does.
Concerning the message standardization issues: the idea expressed by Olli that there can’t be a decent vendor-neutral standardized message, and that, therefore, vendors should opt for vendor-specific messages, is entirely wrong. There is plenty of examples of solid well-designed standards in the aerospace industry that work well by abstracting away the implementation differences and converging a huge variety of equipment produced by various vendors to a simple common interface. I understand that some might want to point out that there were highly unsuccessful attempts to achieve the same goals in other industries, such as NMEA 0183, which I agree is a disaster, but one particular flawed implementation says nothing about the concept itself.
As has been explained in the chat room linked earlier, the addition of vendor-specific messages would defeat one of the primary purposes of UAVCAN, which is to define a standardized data interface that can be used by any sort of equipment from different vendors out of the box. When one proposes that vendor-specific messages are acceptable, they apparently aren’t thinking outside the narrow limits of the most basic UAV applications where the usage of CAN bus is limited to carrying measurements from the sensors to the autopilot and from that to actuators. The vendor-specific messaging approach would immediately break apart even in a slightly more complicated scenario.
Consider, for example, a camera that wants to geotag its images by using GNSS data from the CAN bus (like Mapir cameras that support UAVCAN do). The task is trivial as long as there is a standard data bus interface that can be relied upon by the vendors of the camera, the GNSS receiver, and the autopilot. Shall one resort to vendor-specific definitions, the whole ecosystem immediately falls apart. I hope this example is illustrative enough. Needless to say, the example applies to other use cases beyond cameras and GNSS receivers.
The above is the key reason why tunneling of other protocols, such as I2C/UART/SPI, over the CAN bus is never going to happen in UAVCAN.
I invite @EShamaev to this discussion, perhaps he has something to add.
Pavel.