HN Reader

For a while new grads had a severe lack of hands on ROS experience. Though many companies don't use ROS, it is so entrenched in the industry that most solutions look similar enough for transferrable skills. (Src: was hiring mgr in robotics)

Highly recommend if you want to get into robotics you have ROS experience and demos / stories at hand.

I loathe ROS as much as the next guy but is there any serious free alternative with much community?

Based on the Andino robot project [1] the price is greater than USD 250 [2] I wonder how far we can push the price down for schools. For example, putting an [old] mobile phone (with a camera and replacing the battery), and moving to ESP32 and use another OS.

[1] https://github.com/Ekumen-OS/andino/

[2] https://docs.google.com/spreadsheets/d/1TMbENKlHr4g9bBA-EPNu...

While it's used in industry sometimes, ROS is really one of those by-and-for-academia tools. There's a reason it's near-universally reviled, and why "migrate off of ROS" is a standing goal at a lot of robotics companies.

There's also a reason why it's a standing goal, rather than a completed goal.

It does little or nothing really well, but it does everything kind of okay.

There's a lot of "alternatives", most of which do something much better, sometimes much much much better, than ROS, but none of which can replace it all completely. PyRobot, Viam, OROCOS, Webots, all of these do some things much better than ROS, but none of them can drop in and easily replace everything without a lot of developer time, often adding new features to the platform.

I tried to use ROS2 twice in my professional career. Both times ended up with massively bloated build pipeline code, significantly longer build times, and massively bloated Docker images.

Don't use ROS2. The benefits just aren't worth it. It's great for school but it's terrible for production.

Those of you who use ROS in production, do y'all use ROS 1 or 2? Do you maintain your own fork? I'm curious how people do this, with the upcoming Noetic deprecation.

Ok I will just say it. ROS sucks and is a nightmare to use. When it does work it doesn't work well. I am not sure why we continue to use this outdated programming method. I have several robot. All of them could use ROS but I choose not to torture myself with what a mess that would be. Now a days coding or programming does not have to be unenjoyable. If you want to not use the dreaded ROS method to kill your brain then use ChatGPT 1.o this will change the way you code forever and you will actually enjoy it and look forward to coding with it. It takes the nightmare away that ROS created. No one wants to use ROS let's be honest. So finally there is a better way. ChatGPT 1.o makes ROS to look like an outdated mess.

i am dealing with ros these days for calibrating my custom hardware. it really is gROSs.

Thankfully, I have fully isolated ROS parts into their own dockerfiles.

Any thoughts on the take over of ROS developers by Google/Intrinsic ?

Recommendations? I'm seeking a robotics course akin to prompt engineering, LangChain, or LangGraph that prepares me for the 'ChatGPT' moment in robotics. While SLAM navigation and similar topics are vital, it feels reminiscent of five years ago when one needed to master machine learning to create their own ML models. Nowadays, most LLM models are API-based and don't require an ML background.

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), 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?

Is ROS 2 approachable for a teenager interested in electronics and what hardware would you recommend for them (considering it as a present for a family member)?

This is exactly what I am researching right now. I am working on a project build a robot that maps its surroundings and walks around. The goal is to learn some AI (slam and camera based ML) and also hardware (Robot itself).

I am thinking of raspberry pi with cameras and then using just building the slam algo from scratch. Is this a good option or am I trying to bite off more than I can chew. I understand ML theory but haven't done any other than the basic 101 ML programs and the coursera course. I am fluent in OS (systems), C, python.

Can folks with knowledge opine on this? Are there better ways to learn ML? I chose the robot so I can have something to keep on building/adding

I'm new to embedded systems programming and looked into ROS recently, without using it, while figuring out a minimal software stack for a UAV project (px4 over ArduPilot for the flight controller, but what to run on a "companion" computer is open ended). [my XP is in cloud infra, RESTful microservices, web apps, videogames]

Researchers, hobbyists, and some industry professionals (for prototyping?) seem to love ROS for its big community, logging/debugging/visualisation tools (rosbag, rviz), the pub/sub architecture (easy integration and loose coupling with third party modules), existing support for many sensors/peripherals/hardware components; plus off-the-shelf libs for SLAM, navigation, inverse kinematics, etc.

But ROS is hated by others for its custom build system (on top of CMake), the custom language-agnostic IDL for message types (like Protobuf but worse, esp. for versioning and backwards compatibility), non-determinism and untestability of the pub/sub model (esp. for safety-critical stuff), overengineering and layers of indirection / learning curve, poor performance, and high platform lock-in.

Looking at ROS as a robotics noob, it seems like useful 'muddleware' for toy projects, but where every sub-problem that it abstracts away from you can be solved better by other existing tools. I'm looking more into: Mobile Robot Programming Toolkit [1], Yet Another Robot Platform [2], genom3 [3], and Open Robot Control Software [4] (all C++). Or the Rust ones like RoboPLC [5], Dora-rs [6], Copper-rs [7], and Basis [8] (which supports Protobuf!).

If you're not using ROS for a "serious" project, do you use other middleware offerings or just pick 'n' mix lower-level libs tailored for your use cases?

[1] https://mrpt.org

[2] https://www.yarp.it

[3] https://git.openrobots.org/projects/genom3

[4] https://orocos.org/

[5] https://github.com/roboplc/roboplc

[6] https://github.com/dora-rs/dora

[7] https://github.com/copper-project/copper-rs

[8] https://github.com/basis-robotics

Worked with ROS in research, industrial, and warehouse spaces for 12 years now, with fleets of hundreds to thousands of robots, tens to hundreds of thousands total worldwide. If there's one thing I could convince people of, it's to never use ROS to communicate between hosts.

If you want to use ROS for IPC on the same host, fine. That can all be debated but okay. But if you want to communicate to different robots, especially over WiFi, ROS is missing most of what you need, and it's things that roboticists do not need to reinvent as the Web has been grappling with these issues for a lot longer by millions of more developers.

- You will have to worry about versioning, either on your terms of when you're inevitably forced to

- Even if you don't plan on operating multiple versions in harmony (years later you'll regret believing you could get away with this), you have to deal with the edge effects of when you upgrade them remotely/on-site.

- ROS API definitions ("ROS Messages") are defincient. Yes, you really need to support `null` but you also need a whole lot more expessiveness in general. You'll invent your own string-but-actually-json message at some point.

- You end up manually dealing with well-trodden problems like compression, authentication, authorization.

- Failed comms, reconnecting, retrying, etc. will be a huge pain.

I think the simplest question to ask yourself/team is: "Could this be an HTTPS API? Could this be a Websocket? Do we even have the correct skills on the team to answer this question or did we only hire ROS people?"

The ROS project has terrible governance, and the community suffers heavily from groupthink.

I just got banned from their forum for questioning what the ROS Foundation has done in the past two years--specifically on the build system. Yes, their middleware is unforgiving of alternative ways other than their wrong and outdated development practices, but their community is more religiously attached to their precious tools for development.

This is the post I wrote: https://discourse.ros.org/t/build-systems-package-management...

ROS is painful to work with and doesn’t scale well. It’s a shame Microsoft abandoned Robotics Developer Studio over a decade ago.

Robotics Developer Studio started off in a promising direction. It had the CCR (Coordination and Concurrency Runtime) and the DSS (Decentralized System Services) which together made it possible to coordinate real time robotics in a RESTful environment across distributed hardware. It had also had full access to .NET. There’s never been anything quite like it since. Unfortunately MS pulled the plug before it had a chance to mature into an easy-to-use well documented platform.

Had a recent conversation with nephew about his robotics study, and it seems he’s overwhelmed with ROS, OpenCV, Python, AI transformers tutorial hell.

Told him we should go together to industrial expo - starting from 3d printing, molding, material science and robotics and spend some time together to hack into hard core C++ SDKs used by big tech like Nvidia and Co, and look how to developed linear algebra and statistic on real life examples.

His dream is to automate small mid business manufacturing, and become a Steve Job like figure one day.

What’s the good information and resources to follow and educate about real life robotics?

Any tips or even sarcastic comments are welcome. Please help to be a cool uncle ;)