3 ms·

We have a handful of devices built on STM32, RP2040, RP2350, RP Pico and RP Pico-W running bare metal firmware and green threads for task management. These wer

We have a handful of devices built on STM32, RP2040, RP2350, RP Pico and RP Pico-W running bare metal firmware and green threads for task management. These were generally designed to communicate over UART (to a physically-connected host) or a LAN (wired or wireless) using MQTT topics and plain text message formats. We have a primary, core machine built around Linux SOMs like NVidia's Orin or the RPI5, which could run real software (like ROS). I expect to have dozens and eventually many hundreds of nodes in a variety of facilities. So far, things were going pretty well, though very sparse in terms of tooling. For example, I've got a makeshift midi controller (for physical knobs) that uses a Python script, debug connectors, and messy gnuplots to do PID tuning. I got pretty pumped about the Foxglove Studio product and pulling on that thread led me into the (completely awesome) YT channel "Articulated Robots" (https://www.youtube.com/@ArticulatedRobotics https://www.youtube.com/@ArticulatedRobotics), which led us down a path to seriously considering a move toward ROS2. I wrote it off a couple years ago (2021/2022-ish) for a handful of reasons: a) The move from ROS1 to ROS2 triggered my PTSD from my time at Google where everything had 2 versions: One that's deprecated, and One that's not ready yet. It also triggered trauma from Python's ongoing and complete disregard for backward compatibility. b) It's obviously designed to run on Linux, but I have a bunch of low-cost bare metal micros driving around. What the hell kind of robotics platform doesn't (by default) run on microcontrollers? c) CMake is already one of the absolute worst piles of trash I've ever encountered in nearly 25 years of software development. Wrapping CMake (twice now!?), which is already a crap wrapper is so obviously such an awful idea that it's tough for me to trust anyone who had part in that decision. d) C++. No thank you. Slow builds are a non-starter. C is fine IMO. Now, I've spent 4-5 days watching videos, doing tutorials and bringing up ROS2 topics and basically fiddling around with it and just learned that Google(ish) bought the core team, which has me deeply concerned about the future of the platform. I'm actually still kind of interested in the DDS portion of ROS2, but the whole mess trips my spidey sense and has me feeling like dragons be lurking. Seeing this thread with so many people speaking so negatively about it has me desperately wanting more information. Can anyone point me to anything that presents concrete problems and (better) alternative systems that work?

rcxdude 2y ago
The one over-arching issue I'd point to is that network pub-sub is the way to connect different parts of your system in ROS, and that's a bad default, and an even worse single option. For most data-flow, you probably don't want to be hitting a serialisation step at all, but if you do, you probably want to be thinking carefully at the system level about how to move it around (how much data, what latency, from what kind of system to what other kind of system, how to deal with failures, corruption, etc), not just throwing it all into a general one-size-fits all approach. ROS systems tend to have multiple key control loops running through a transport that really likes to foul them up, and make for slow, unreliable behaviour. Most robotics projects that use it can get to it doing something pretty quickly, but getting it to work more than 20% of the time is a huge struggle. Otherwise, concrete problems are a bit harder to talk about, because they're very diffuse: while ROS has a lot of components and tools you would want in a robotics system, and they are all integrated together, the average quality is very low: they are on average slow, buggy, hard to use, and tend to lack important features, from build systems to GUIs. While it's tempting to use a it out of the principle that you shouldn't be duplicating work, in general I would say most robotic applications are far better served by using a custom framework that better fits their system design, using appropriate libraries for each part, but not an off-the-shelf do-everything framework (and it feels like there are gaps that could make this less effort, but in my experience writing your own replacements for ROS components is less effort than dealing with all the problems that come with using it: it's shockingly low effort to reach feature parity). (NB I haven't touched ROS for a while, but it doesn't seem like this has improved much, though there's been plenty of code churn)
- anymouse123456 2y ago
  This is super helpful. We're digging into Zenoh as a potential "library" level integration. Do you have any experience/thoughts on their tools?

rcxdude 2y ago

The one over-arching issue I'd point to is that network pub-sub is the way to connect different parts of your system in ROS, and that's a bad default, and an even worse single option. For most data-flow, you probably don't want to be hitting a serialisation step at all, but if you do, you probably want to be thinking carefully at the system level about how to move it around (how much data, what latency, from what kind of system to what other kind of system, how to deal with failures, corruption, etc), not just throwing it all into a general one-size-fits all approach. ROS systems tend to have multiple key control loops running through a transport that really likes to foul them up, and make for slow, unreliable behaviour. Most robotics projects that use it can get to it doing something pretty quickly, but getting it to work more than 20% of the time is a huge struggle. Otherwise, concrete problems are a bit harder to talk about, because they're very diffuse: while ROS has a lot of components and tools you would want in a robotics system, and they are all integrated together, the average quality is very low: they are on average slow, buggy, hard to use, and tend to lack important features, from build systems to GUIs. While it's tempting to use a it out of the principle that you shouldn't be duplicating work, in general I would say most robotic applications are far better served by using a custom framework that better fits their system design, using appropriate libraries for each part, but not an off-the-shelf do-everything framework (and it feels like there are gaps that could make this less effort, but in my experience writing your own replacements for ROS components is less effort than dealing with all the problems that come with using it: it's shockingly low effort to reach feature parity). (NB I haven't touched ROS for a while, but it doesn't seem like this has improved much, though there's been plenty of code churn)

anymouse123456 2y ago
This is super helpful. We're digging into Zenoh as a potential "library" level integration. Do you have any experience/thoughts on their tools?