[RFC] Metadata uORB message

[TSC21]

This is an RFC for a possible solution on propagating uORB metadata.

Motivation
While implementing time sync on the microRTPS bridge, I was able to verify that we don't have a good mechanism in the uORB msgs that allows us to properly implement protocols or algorithms that require an handshake, with identification of the parts communicating and to identify the message exchange sequences.
Considering that the usage of uORB is not anymore enclosed to the flight controller, there's a need on updating the msg structure and the API to support communication with a component outside of the flight controller.

Suggested solution
Create an header uORB msg that contains the following fields:

• timestamp: we already have these on all uORB msg, but now it would be included inside an header metadata structure. This could imply an update on the publisher APIs, which allow to automatically setup the timestamp field at the time of publish by default (otherwise, can be set manually);
• sys_id: in someway, this could be similar to what the comp_id in Mavlink does, but in a first stage the main idea is to identify the source of the messages being in the flight controller or on the companion computer (client and agent of the microRTPS bridge). It could be further extended to identify different components of the system, or even in a multi-autopilot redundancy system, identify each autopilot;
• seq: serves to identify the message sequence - it's not mandatory to be filled, as this is might only be useful for handshake sequences;
• frame_id: kind of inheriting from what is found on the std_msgs/Header ROS message, allows to identify the frame of reference of the data. It's not applicable to all messages.

I appreciate some comments and suggestions on how we can make the above possible.

For your interest and comments @bkueng, @dagar, @jkflying, @julianoes, @LorenzMeier. Thanks!

[jkflying]

I think frame_id is too heavy, otherwise I'm in favor of this. Right now every uorb message needs to manually have the timestamp added anyway. The seq_id I also see as being useful for knowing if we are dropping uorb messages on a client side.

The sys_id is to me the bare minimum to know who the message was sent from.

The other place for problems I see is in some places we have nested uorb messages, we probably don't want to pay for the header on all of them.

[TSC21]

The other place for problems I see is in some places we have nested uorb messages, we probably don't want to pay for the header on all of them.

All nested uORB msgs will only have the header at the top level msg. That needs to be something to take into consideration and maybe have a check on the uORB generation code to verify that same part.

[dagar]

• timestamp: absolutely should be there and real metadata (set within uORB publication). I was trying to get there incrementally. [WIP] uORB::Publication automatically set timestamp #13970
• seq: I'd be in favor of including this as a replacement to the uint32_t generation that's the core of every uORB::Subscription. https://github.com/PX4/Firmware/blob/9cd8bb4f889f1cda33941a99056061b0e5d2b9bf/src/modules/uORB/Subscription.hpp#L149
• frame_id: fine as long as it's optional (so not in a general header?)
• sys_id: seems wasteful within PX4, can we add in the bridge?

[dagar]

Some uORB timestamp history. #10178 (comment)

[TSC21]

• timestamp: absolutely should be there and real metadata (set within uORB publication). I was trying to get there incrementally. [WIP] uORB::Publication automatically set timestamp #13970

Ah great didn't know that PR exists. Then we are aligned.

• seq: I'd be in favor of including this as a replacement to the uint32_t generation that's the core of every uORB::Subscription. https://github.com/PX4/Firmware/blob/9cd8bb4f889f1cda33941a99056061b0e5d2b9bf/src/modules/uORB/Subscription.hpp#L149

That sounds good to me. Although, I found an interesting detail that I missed before: https://github.com/PX4/Firmware/blob/master/msg/templates/urtps/microRTPS_transport.cpp#L234. Though I am not really sure of the value of this one, since it seems to be reset every time it gets sent.

• frame_id: fine as long as it's optional (so not in a general header?)

We could created a nested header type for it for sure. Or a different header type to not overdo it.

• sys_id: seems wasteful within PX4, can we add in the bridge?

I think that's probably possible yes: https://github.com/PX4/Firmware/blob/master/msg/templates/urtps/microRTPS_transport.cpp#L239.

[TSC21]

Some uORB timestamp history. #10178 (comment)

Yes I recall that. Probably a good time to do it.

[TSC21]

For the sake of this discussion, I am going to explore more the header metadata which follows with the RTPS packets and see if they are useful enough to our use cases. I any case, I do think it's relevant that some of this metadata gets propagated for internal uORB messages as well.

@dagar regarding the sys_id being wasteful. What if we have two FMU's connected under the same network - which is totally possible, considering that DDS allows that? The use case could be redundancy. I am just thinking a bit ahead here.

[dagar]

@dagar regarding the sys_id being wasteful. What if we have two FMU's connected under the same network - which is totally possible, considering that DDS allows that? The use case could be redundancy. I am just thinking a bit ahead here.

My main concern is how it will impact logger. We already struggle to create ekf2 replayable logs on older systems. Adding a seq (moving the internal generation) will already be a lot, but I think it's worth it for subscribers and tools to better see what's happening.

[bkueng]

So essentially what you want is MAVLink?

timestamp: we already have these on all uORB msg, but now it would be included inside an header metadata structure. This could imply an update on the publisher APIs, which allow to automatically setup the timestamp field at the time of publish by default (otherwise, can be set manually);

timestamp is a fixed field in ULog and cannot be moved or renamed.

I agree with @dagar, we cannot just add large headers, we're operating in a different environment compared to a companion (or where ROS runs).

[TSC21]

So essentially what you want is MAVLink?

No, I don't want MAVLink. And this is not what I want, it's about what we require so we can properly use the uORB API to communicate with the companion on a DDS domain.

timestamp: we already have these on all uORB msg, but now it would be included inside an header metadata structure. This could imply an update on the publisher APIs, which allow to automatically setup the timestamp field at the time of publish by default (otherwise, can be set manually);

timestamp is a fixed field in ULog and cannot be moved or renamed.

OK. ULog could be adjusted for that and add backwards compatibility, but avoiding that trouble: is it fine for you that we could add the other fields directly to the message, instead of a separate structure?

I agree with @dagar, we cannot just add large headers, we're operating in a different environment compared to a companion (or where ROS runs).

Although the header structure is similar to what you find in the ROS header message (I should have avoid the comparison), this has nothing to do with ROS. Actually, the plan is to avoid to use ROS on deployed systems and just use a dedicated DDS domain where the companion and the FMU are participants. Now the main issue here is if we want to be able to properly do that, we need an API that allow us mechanisms to exchange data between two different systems. uORB isn't prepared for that but if we want to make this happen, we need to find a solution that balances what we need and the limitations of the systems.

The main purpose of this RFC is that we find a solution for the problem - not adding more problems to the problem. So what I ask for is that if you see a problem on the solution, please show it but then propose a solution that you think it fits. Otherwise, we will always be stuck in a discussion without actually finding anything useful. Thanks

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[TSC21]

Still relevant

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.