u/NickShipsRobots

Saw another "just use Cyclone" comment today, got little tired of this honestly

For me it's not even real choice as I work with micro-ROS and Fast DDS is hardcoded in micro-ROS agent on host side. Switching to Cyclone just means extra integration work for nothing.

Also I think people are optimizing wrong thing in general. In our case serial link between microcontroller and host was the biggest latency contributor, not DDS at all. Took us embarrassingly long time to realize this lol

So before going deep into DDS comparison, first check where your actual bottleneck is. And if you do compare, test on your own hardware, don't trust numbers from internet. Setup is too different everywhere to make general conclusions.

If anyone's actually swapped the RMW in their micro-ROS agent, would like to know how that went. Doesn't seem worth it to me.

Ok so I was debugging someone's code last week. They replaced PID loop with neural network. Why?? It was slower, harder to debug, and not even better. I think just looked cool in the presentation lol

I get it, ML is great for perception, manipulation, stuff you can't just write rules for. But for control loop? Come on. PID, LQR, MPC – predictable, you know what they do, you can fix them at 3am when everything is on fire.

Also somebody will need to maintain this code in 3 years. Good luck explaining neural network to that person:)

But maybe I am missing something here. Anyone actually replaced classical control with ML and was happy with result?

Went to a robotics event last month. Lost count of how many booths said "AI-powered" on the banner lol

Asked a few engineers what was actually running – classical controllers, pre-trained detection models, one guy who genuinely couldn't explain what the AI part was doing.

The collateral damage is what bugs me most. When everything gets the same sticker, the projects that actually did something novel get lumped in with the ones that slapped "AI" on a PID loop. Buyers get burned, the whole category pays for it.

Filter I've been using: take the AI component out. Does the thing stop working, or just get slightly worse? "Slightly worse" is a feature, not a foundation.

Maybe I'm just getting cynical... do you still find the label useful when evaluating something, or do you just go straight to asking the engineers?

I work on a small robotics hardware team. We build perception and connectivity modules - the kind of stuff that sits between sensors and your compute stack and is supposed to just work. ROS 2 is a big part of how we think about integration, so we spend a lot of time in this space.

Sensor integration is one of those problems that quietly eats weeks. Driver hunting, power routing, timing debugging. Then repeat the whole thing for every new sensor on every new project. At some point our team just got tired of it and decided to fix it properly.

We built an extension module that puts a MikroBUS socket on our platform and, more importantly, runs the ROS 2 node on the board itself. It publishes directly to a topic. Your main compute just subscribes. No driver work on your end at all.

The video shows my coworker plugging in a MikroElektronika IMU Click Board. Topic appears instantly in ROS 2. That's the whole demo because that's genuinely the whole process.

Two transport options are supported depending on the setup:

• GMSL - high bandwidth, single coax, up to 15m, sub-ms latency. Cameras and sensors share the same link.
• CAN - deterministic, longer reach, automotive-grade reliability.

The reason MikroBUS was worth targeting: MikroElektronika's Click Board ecosystem has 1,900+ boards: IMUs, GNSS, ToF, gas sensors, motor drivers, environmental monitors. The abstraction scales.

Happy to go deep on the ROS 2 implementation, how we're handling the node lifecycle on the module, transport layer trade-offs, whatever's interesting. What sensor would you actually want to run first?

https://reddit.com/link/1sx9as6/video/u48jd88ohrxg1/player