We’re building absurdly simple semi-disposable systems-- not even sure I’d call them robots-- that phone data up to the cloud. That said, these also apply to my previous job building more conventional vehicles.
Two related items:
1). Reading mcap rosbags requires a full-- and version-synchronized-- workspace. That’s a pretty big limitation. What I want is to rapidly iterate everything about the system-- message types, topics, node graph, everything-- generating data the whole time and then be able to go back and view logs from 18 months ago without having to dig and figure out which repo versions to check out. If, for example, I’d stored the repo versions in the bag file I’d be in real trouble. Everything necessary to do this is in the mcap files so presumably it’s a matter of updating the rosbag2 APIs. I looked into it; not trivial, although certainly possible.
I assume Foxglove has a good answer to this and everyone who runs into it just pays for their service. Its not horrendously expensive or anything. I haven’t submitted a PR either, so whatever.
2). Lack of optional fields in the ROS IDL. As you may know, this is a common method for dealing with schema evolution. Given that this is available in DDS I’m curious why it was omitted; perhaps some sort of safety critical / MISRA thing? We’ve worked around the issue by translating everything to protobuf before it goes off-vehicle. This works fine for the limited data our comically simple systems send, but would be a real bummer for a large system.
Not really sure what action is even possible on #2, but you asked.
I assume both of this are old complaints rehashed many times during the ROS2 design meetings, so maybe not useful for your purposes. Still, any explanations I can pass back to our Cloud People would be very helpful. Especially on Item 2.