Is it time to discuss rosidl?

[MoffKalast]

@gbiggs

It’s also worth noting that, if you really prefer the 100% centralised approach of roscore, even for remote connections, both Zenoh and DDS allow this in their design. You just need to implement it - and with Zenoh and FastDDS, at least, that’s just a configuration change.

Yes that’s the only kind of setup I’ve ever seen work consistently, running the DDS on loopback, centralized discovery, etc. Then I get sort of ROS 1 performance at several times the CPU load. Depending on the share of rclpy nodes of course.

@gbiggs

Have you filed issues about this? Have you brought it to the PMC meeting for discussing potential improvements? Have you proposed potential improvements?

Have you also measured the drop in performance over pure Zenoh (or over “no transport at all”) for your application and confirmed that the drop is more than your application can withstand, and outweighs the functional benefits that are gained from using ROS?

Well fwiw I did bring the aforementioned benchmark to @mjcarroll 's attention a few months back and to his credit he did patch some of the serialization overhead in both cyclone and zenoh with the suggested caching fix which should be live in Lyrical now. How much that helps in practice I’m not sure yet, because it only ships with Lyrical and I don’t have any representative test environment for it yet. While I’m still stuck on Jazzy anything I eval on it can be handwaved with “might be fixed in Lyrical”. So not much point in doing that yet until there’s more Jetty updated sim setups and that will take some time. But sure, I can send some actual numbers over on Zulip once I have something concrete set up.

Of course the functional benefits of ROS are immense, but far more so during research and prototyping than in final deployment when everything is very clearly defined, and where every layer of inefficiency makes the system more expensive per unit.

@gbiggs

This is a slippery slope argument.

Very well, I take that back. My point was, a single design choice has dragged along a significant amount of bloat that has imo caused more harm than good, at least in the short term. Yes there are known shortcomings in ROS 1, and there are also known shortcomings in ROS 2.

@gbiggs

I see robots every day in production use in the world working well with DDS or Zenoh, not “no transport at all”.

I still think the general industry attitude is that the ones that do manage to get something working it’s despite the DDS, not because of it. They’re mostly dragged along kicking and screaming because they need Nav2. But that’s just what I’ve heard.

@gbiggs

in my opinion, a solved problem, other than perhaps the default configuration not working that way (yet).

Maybe I’m getting off topic here, but I cannot stress enough how important it would be to make sure the defaults for all RMWs are at least, hm… usable? Good might be asking for too much. Relying on the vendors for that has not produced any results, there’s just a bunch of configs circulating around with nobody exactly sure what option helps with what. Perhaps those guys running it all super duper well in production can help give the rest of us plebs a hand?

@gbiggs

rcl::buffer with IceOryx would not require the actual data to go via RAM, the camera driver could place it directly in VRAM and the other node(s) could use it there

Okay that’s big if true. Looking forward to it I would be surprised if some additional overhead doesn’t sneak in to remove basically all the gain of the approach though, we usually can’t have nice things.

[zc_Liu]

Thanks for the feedback. Fair point — I stretched the rosidl representation discussion into a separate state-semantics/diagnostics idea, which is probably better evaluated independently rather than in this thread.