11 ms·

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

numpad0 1mo ago
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.
- rokbenko 1mo ago
  [dead]
rokbenko 1mo ago
[dead]
tamimio 1mo ago
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.
- lagrange77 1mo ago
  Oh wow thanks, you might have saved me a lot of time and anger.

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.

rokbenko 1mo ago
[dead]

rokbenko 1mo ago

[dead]

tamimio 1mo ago

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.

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