What would be so bad about relying on ROS in any way?

One horrifying facts I've read about it is that ROS1 is completely non-realtime and non-deterministic, so much so that its ROSBAG data logs aren't time or sequence accurate. So you can collect the sensor inputs and simulate programmatic behavior, but it's acucrate only if you were lucky. And everyone has to either use it or devote massive amount of resource recreating it right way because there's just immense amount of useful packages available for ROS.

Because ROS sucks. If you have ever had the chance to work with it, you will know, here’s a heads-up/recap on why:

- multiple configs all over: xml, cmake, yaml, “””launch file”””, urdf, and others, im not joking, those are all configs!

- you might have a node running but it’s technically not? The mystery mostly that the node isn’t publishing, why? Well, there are gazillions of reasons, maybe qos mismatch, wrong topic name space, timestamp issues, frame ID, etc etc

- the debugging is distributed, so a failure you see (assuming you found it anyway), it could be actually from another process, interface, driver, you name it.

- so many dependencies, you have ros itself, then ubuntu, then gazebo, python, other libraries needed to build, so you could spend a whole week troubleshooting just because one of these mismatch something else.

- ros1 sucked, look it up, realtime limitation, security, discovery, tooling etc, so they made ros2, supposedly better, but the unnecessary complexity added is abysmal, dds, qos profile, call back groups, lifecycle nodes, and other cluster fuck of stuff.

- you have also with implied status, so different terminals can and will behave differently, you got sourced workspaces, environment variables, automatic discovery, overlay order and others, can work in one terminal setup but not in another.

- a lot of packages were done for specific robot or by a student who was doing some school work, that package will not just work on the same set up you have, I have seen robots of the same model and the package won’t work because the motor driver is slightly different. Also, that package is mostly abandoned anyway.

And you have all the security concerns with all that stuff above, that’s why it never gets added to the same network where serious automation things are happening, in fact, I have never ever seen ROS used in real commercial products, for good.

First time I got to work with it I thought it’s just me, so I ended up building the drone platform from scratch in much easier and simpler way, only to find most of the industry share the same idea.

I can rant more but my take away, if you can do something without it, do it, don’t try to rely on it, it’s like 100x worse than kubernetes, once you are fully invested in it and building everything around it, it will be hard to replace.

Oh wow thanks, you might have saved me a lot of time and anger.

Sounds interesting, could you elaborate on what you do with?

Not much to say, really; it controls my house in Home Assistant using an LLM, and a STT/TTS server. It acts as the Home Assistant Voice Preview Edition, with a trigger word and whatnot.

It's basically like giving an Alexa, Siri, or Gemini a body. It moves, show "emotions", comments when someone enter the room, uses the camera to see who entered the room and comment on that, make comments when my 3D printer finishes, things like that.

I can also turn on lights, the TV, the AC, ask about the weather, and other basic assistant stuff, ofc.

> It moves, show "emotions", comments when someone enter the room, uses the camera to see who entered the room and comment on that, make comments when my 3D printer finishes, things like that.

So basically you're using it as an AI mother in law, nice.

Huh, that's pretty cool! How much of that behavior did you need to roll yourself vs what was already there?

There is an application for Reachy that makes it so you can connect to Home Assistant, but it's broken and seems abandoned, so I forked it, fixed it, and customized it. That gets you 80% of the way. The rest is based on automations built inside Home Assistant.

And since Reachy's software and SDK are pretty open, it's trivial for a coding agent to learn how to communicate with the robot to achieve your desired outcome.

Godverdomme

Very cool idea and my evolution to a scorpio was fun and educational.

I actively do it in a way, where i steer and understand the important bits. Because otherwise the cognitive and technical debt would annoy me to a point, where i would want to do software at all.

Took me a few minutes to realise it's not a domain name search engine.

So you want him to make a piece of software that models a probability distribution rock solid.

Maybe “rock solid” could be understood as slightly hyperbolic (though it is metaphorical, so hard to say whether it is really hyperbole), but, it is possible to predict some things probabilistically with a high degree of accuracy. Depending on the task, a high enough degree of accuracy sounds doable, and if it offers a sufficiently convenient fallback to an actual human when it fails, that sounds like it could be quite a bit nicer than navigating a phone tree menu?

Classical voice to text combined with NN based voice to text, I would imagine can be highly accurate, and that’s probabilistic.

> could be understood as slightly hyperbolic

Of course, you're right. I didn't intend to criticise him.

I just think that it's not a good idea to transfer this megatrend to healthcare.

Yes, those systems can be highly accurate, but as we all have experienced, this is not a stable or consistent property. A very good model can give you an ingenious answer one minute and an utterly dumb one the next. My guess is that it's simply a consequence of the extremely high complexity of the 'plant' (natural language, language interfacing with the real world), leading to some highly non linear behaviour.

Yes

Yeah, interestingly it feels equally bland as the 90s pendants.

I thought exactly the same at first. But then i wondered if that still holds true with today's advanced thinking, RLHF involved, frontier models. I guess to a certain extend it did indeed behave better, as a reaction to his self description into account.

EDIT: I mean, those systems accumulated so much complexity around the attention based next token predictor.

Yeah, in my experience, there's nothing about:

1. LLM thinking 2. RLHF 3. The latest frontier models

that does anything to change this fundamental "suggestibility" of LLMs.

But who knows, maybe I'm wrong.

Training the LLM to do things that the user didn’t explicitly ask for is a good way to get complaints from the users. Doesn’t matter if those things are best practices.