Without taking away anything from the substance or achievement of this release, I find phrases like "openpilot is an operating system for robotics." always quite fishy.
No, it's not an OS for robotics. You can't do actual robotics stuff with it, like drive actuators to control limbs or grippers, do motion control or SLAM or perception or any of the usual robotics stack.
Their website correctly says openpilot is an open source advanced driver assistance system that works on 275+ car models of Toyota, Hyundai, Honda, and many other brands. Should've stuck to that.
Thinking about it some more, it's probably just another engagement baiting strategy to get attention and I'm their gullible puppet. Well played.
George Hotz says: "we developed a proper successor to ROS. openpilot has serialization (with capnp) and IPC (with zmq + a custom zero copy msgq). It uses a constellation of processes to coordinate to drive a car."[1] And Comma sells a robot that runs Openpilot: https://comma.ai/shop/body
> You can't do actual robotics stuff with it, like drive actuators to control limbs or grippers, do motion control or SLAM or perception or any of the usual robotics stack.
A lot of the "usual robotics stack" is not going to be relevant for the new wave of consumer robotics that is coming soon. It will be enabled by end-to-end machine learning and stuff like traditional SLAM methods will not be a part of that. The Bitter Lesson[2] is coming for robotics.
In the robotics community, the stuff coming out of George Hotz has always been considered a kludgy mess, and unsuitable for serious work. Dude is a talented hacker, but the idea that this will replace ROS is kind of a joke.
With due respect, this has to be one of the most ignorant takes on robotics I have read in a while. Yes, you can always slap serialization and ZMQ on your framework. That doesn't make it an OS.
And no, the usual robotics stack is not going away anytime soon. Maybe develop some actual useful robots before posting like an expert on robotics topics.
I enjoy Hotz as a hacker, but I'm really allergic to this kind of oversold language. "[W]e developed a proper successor to ROS" is a past tense statement, as if they've already done this thing. In reality, at best they have presented a roadmap for a thing that could approximate ROS one day.
The point of the bitter lesson is "leverage compute as best you can" not "use DNNs everywhere just because". Oftentimes your available compute is still a crappy ARM machine with no real parallel compute where the best DNN you can run is still not large nor fast enough to even be viable, much less a good fit.
And well some classical algorithms like A* are mathematically optimal. You literally cannot train a more efficient DNN if your problem needs grid search. It will just waste more compute for the same result.
Besides, the nav stack is not really the point of ROS. It's the standardization. Standard IPC, types, messages, package building, deployment, etc. Interoperability where you can grab literally any sensor or actuator known to man and a driver will already exist and output/require the data in the exact format you need/have, standard visualizers and controllers to plug into the mix and debug. This is something we'll need as long as new hardware keeps getting built even if the rest of your process is end to end. It doesn't have to be the best, it just needs to work and it needs to be widely used for the concept to make sense.
The future of consumer robotics will not be built on "a crappy ARM machine with no real parallel compute". Traditional robotics has failed to produce machines that can operate in the real world outside of strictly controlled environments, and more of the same isn't going to change that. Fast hardware for running DNNs will be a hard requirement for useful general purpose robots.
I agree that it'll be needed, but that hardware that can provide enough compute at acceptable wattage is yet to materialize. Only once that changes the equation will change. Today you'd be surprised how many production UGVs run off an actual Pi 4 or something in a comparable compute ballpark.
I believe the idea is that openpilot replaces the usual robotics stack with an end to end neural net.
While I agree operating system is usually a marketing term, it does feel correct in this case as it is the operating system for the Comma Three, which can operate cars but also this thing: https://www.comma.ai/shop/body
Could someone explain the joke? I've been dabbling with learning robotics and I've been confused by how ROS and ROS2 both appear to be actively developed/used. Is ROS2 a slow-moving successor version (like Python 3 was) or a complete fork?
Slow-moving successor, which the community isn't exactly going wild over. It offers modest improvements in exchange for a painful upgrade process, and many of the original issues with ROS1 remaining unsolved.
The other half of the joke is that ROS was never an operating system either.
Well there is one thing that ROS 2 does better, you can declare params directly inside nodes and reconfigure them all without building extra config files. And it doesn't stop working if your local IP changes.
But the rest are firmly downgrades all around. It's slower (rclpy is catastrophically bad), more demanding (CPU usage is through the roof to do DDS packet conversions), less reliable (the RMWs are a mess), less compatible (armhf is kill). The QoS might count as an improvement for edge cases where you need UDP for point clouds, but what it mostly does on a day to day basis is create a shit ton of failure cases where there's QoS incompatibility between topics and things just refuse to connect. It's lot more hassle for no real gain.
Config generally feels more complex though, since there isn't a central parameter server anymore. The colcon build system also just feels more complex now, which I thought was already impressively complex with catkin.
Yep it takes super long to get parameters from all nodes cause you need to query each one instead of the DDS caching it or something.
And yeah I forgot, there's the added annoying bit where you can't build custom messages/services with python packages, only ament_cmake can do it so you often need metapackages for no practical reason. And the whole deal with the default build mode being "copy all" so you need to rebuild every single time if you don't symlink, and even that often doesn't work. The defaults are all around impressively terrible, adding extra pitfalls in places where there were none in ROS 1.
No it’s much worse, python3 was all round better, it just took a while to get all your dependencies ported which made the transition hard. Judging by the comments it doesn’t seem like people agree that ROS2 is even all round better from ROS.
It's funny this topic came up today because I have a group of students working on a ROS2 project and at our meeting this afternoon they had a laundry list of problems they've been having related to ROS2. I'm thinking our best option is to use ROS1...
You're right ROS2 isn't all round better than ROS so the transition will never happen fully.
FWIW I'm working on an actual replacement for ROS, I'll post it to ShowHN one day soonish :P
Isn’t the software for training end-to-end NN to be used in automation?
Just a first version that it’s used for cars, and they have been using it for their own robot.
No, it's not an OS for robotics. You can't do actual robotics stuff with it, like drive actuators to control limbs or grippers, do motion control or SLAM or perception or any of the usual robotics stack.
Their website correctly says openpilot is an open source advanced driver assistance system that works on 275+ car models of Toyota, Hyundai, Honda, and many other brands. Should've stuck to that.
Thinking about it some more, it's probably just another engagement baiting strategy to get attention and I'm their gullible puppet. Well played.