uorb subscriber get oldest generation in queue

[AlexKlimaj]

@ShawnFeng0

[shawnfeng0]

generation is an unsigned type that can overflow. If it overflows, we cannot guarantee to get the oldest data at initialization. Getting the latest data on initialization ensures that initialization behavior is always consistent.

[dagar]

generation is an unsigned type that can overflow. If it overflows, we cannot guarantee to get the oldest data at initialization. Getting the latest data on initialization ensures that initialization behavior is always consistent.

Per uORBDeviceNode we could separately track if we've had at least _queue_size publications.

[shawnfeng0]

generation is an unsigned type that can overflow. If it overflows, we cannot guarantee to get the oldest data at initialization. Getting the latest data on initialization ensures that initialization behavior is always consistent.

Per uORBDeviceNode we could separately track if we've had at least _queue_size publications.

Yes, but every time we publish a message we need to execute a few more lines of code. Do new subscribers really need old messages?

[AlexKlimaj]

Could we just update this behavior for messages with a queue? Leave the old behavior for messages without a queue.

[shawnfeng0]

Could we just update this behavior for messages with a queue? Leave the old behavior for messages without a queue.

Messages without queues themselves don't suffer from this problem.

[shawnfeng0]

I think it's reasonable that new subscribers will start processing new messages when they get them. Do new subscribers really need old messages?

If our purpose is the reliable transmission of messages (such as executing commands from ground stations), the existing uorb mechanism cannot do it, and it cannot be done by simply retrieving old messages.

By the way, are there any plans for uorb to support reliable data transfer? @dagar