(wasn’t sure where to post this, but figured there might be people here who’d have run into a similar situation and might have some ideas)
Resources are always finite, but on embedded platforms they’re sometimes really limited.
This poses challenges when producing and/or consuming messages which potentially can be very large: PointCloud2s, Images, CostMaps but even something like JointTrajectory and other unbounded lists.
With Micro-ROS (rclc, rclcpp) the current approach requires sufficient memory be available for “all” sizes of messages an application wishes to receive/send. A trade-off must be made, which essentially comes down to limiting the maximum size such that resources are not exhausted.
But unlike perhaps Images, things like trajectories don’t really have a “suitable upper limit” to their length, and consequently their in-memory sizes. It’s certainly possible to define some arbitrary limit, but there’s bound to be many use-cases which would easily go over that limit and now can’t be supported by an application.
I’m wondering whether it would be possible to implement a sort of SAX-like style of ROS message processing which doesn’t require incoming (or outgoing) messages to be (de)serialised fully in-memory before it’s presented to the application layer.
(for those not familiar with this: SAX XML parsers essentially work with parse events which cause application callbacks to be called by the parser while processing an XML document stream, one-element-at-a-time. This allows for very efficient parsing of XML, as only the current “context” needs to be present in-memory, instead of the entire document tree, as with DOM-like parsers)
This is probably non-trivial – I haven’t looked at how Micro-ROS/Micro-CDR implements (de)serialisation yet – but could result in reduced memory usage in Micro-ROS clients, as there are quite a few use-cases where per-element processing of incoming requests would be possible.
(a valid counter-argument could be to “just use a reliable topic”, and an intermediary node which decomposes a (really) large message into smaller bits and forwards them over that topic to the client application. Having this kind of support in the RMW (or some suitable other place) however would be ideal, as it could be made generic, wouldn’t require an additional node and would be ubiquitously available out-of-the-box)
Edit: it could be this is an xy-problem, and this is not a problem at all, in which case I should’ve RTFM-ed better. I’d also be happy with pointer to said manual or examples then.