This post comes as a reply to the post written by Antti Alhonen from Pulurobotics, where he stated his reasons for not using ROS on the robotics products of his company.
Having read the article, I do agree with him that not every robotics product must use ROS. It depends. ROS introduces an overhead in the development process that it may not be worth the trouble depending on the type of robot we are building. For example, very simple robots that can work with a small controller board, like for example the Sphero robot, may not require to use ROS (however, here there is the code that ROSifies a Sphero robot, and here a post about how to develop ROS programs for that robot using that ROSification). So, I completely agree that for those little robots with no (actual) computer onboard, ROS is not worth the price.
However, mobile base with navigation and sensors to autonomously interact with people… definitely yes!
What is the most optimal in terms of engineering, may not be the most optimal in terms of business.
I would even say more: what is more optimal in terms of personal satisfaction of the engineer that is creating the robot, may not be the most optimal in terms of business. It think that the key term here is personal satisfaction.
Engineers, we always want to redo everything, because we don’t like to have to read and understand what the previous engineer has done:
The previous programmer’s work is very bad (even if the program has been doing its job for x years already). I can do it better from scratch than reading and understanding his messy code.
This is a typical attitude in us, engineers. We always prefer to do it ourselves (I am guilty of that!), and we feel satisfaction of doing it. Of course, if we had all the time of the world, and infinite resources, then it would be a good decision to build our own and optimized system. However that is never the case. We need to meet deadlines, and worst than that, we need to maintain our business in the long run. So reusing what has already being done by others is key if we are in the market… unless we only want to spend the investor’s money and have fun (but it that case, we are not building a business, we are doing a hobby).
Just as an anecdote, while I was working at Pal Robotics building humanoid robots, the electronics chief wanted us to develop from scratch the sensors that the robot was going to use. Imagine the overhead for a company that doesn’t know how to build a camera, now having to design a camera, while anybody else can go to the ROS Components store and buy one that is plug and play in the robot in a matter of minutes. Yes, the bought camera has a given shape that cannot be changed, and one has to deal with that for the sake of simplicity and speed. Furthermore, at the end of the day, the camera company knows a lot better than us how to create a camera, and it is very unlikely that we are going to build something better.
Two big (wrong) claims of the article
There are two big claims in the article that I think are wrong.
The first one
We have developed everything from scratch, and have reached the same level of actual functionality with a team of three in six months than what it usually takes for a team of ten people to achieve in 2-3 years using ROS (based on what we have seen while analyzing the market).
From the page of Pulurobotics, I see that they are developing a mobile platform that moves around, using SLAM to navigate and exploration to autonomously create the maps. On what relates to the software part, those things can be done by a single person in a matter of hours by using ROS.
- SLAM. This is done off-the-shelf with ROS. Right now. 30 minutes to set a navigation system up in a ROS running robot (I have multiplied by ten the amount of time that I really think is needed, for a safety margin). Check this wiki page for information about the ROS navigation stack. Check this online course to learn how to use the navigation stack.
- Autonomous mapping (exploration). Also done. Check this code for multiple robots doing autonomous mapping with ROS (can be used from 1 robot to many), and this other video about how to set it up in 5 minutes.
- Need to communicate with the tablet on top? Use ROS Bridge and have your app sending commands to the base in a matter of hours.
So I don’t agree at all with the first claim.
Second wrong claim
ROS would actually solve around 10% of our problems. The rest 90% would get twice as tedious, at least.
ROS can solve off-the-shelf 90% of your software problems. I’m pretty sure that many of the things their robot needs, is already done inside ROS, and can be reused in that project. Also ROS has the tools for debugging and maintaining the code. It also has have the system to simulate the robot and test prior to deployment. I mean… that is huge!
Again, I don’t agree.
I do agree on the 90% tedious claim. It is tedious to have to learn and adapt to a framework that one doesn’t master, and make our system compatible with it, that is, to ROSify the robot (in the same way as building Unit Tests for code checking is a pain). But the question here should be, what is the best for my business?
Main problem of the post: not having a software background
From an analysis of Pulurobotics’s website, I think that the author and his team are mostly mechanical and electronics engineers and lack a strong software background.
While I was at Pal Robotics, mechanics engineers had a said at our lab for things that were very simple:
That is as easy as writing the software.
Writing software, as perceived from mechanics and electronics, is just a simple thing that can be done in a matter of minutes, and that we, software developers, are over-complicating (for some obscure reason).
Software is the limiting factor in robots
Let me clarify for the sake of truth: the main barrier in robotics preventing us from having robots everywhere is at the level of software, not at the level of electronics, not at the level of mechanics. Of course, electronics and mechanics can be improved a lot, but they are not limiting today the fact that we have a robot that drives our cars. What is preventing those robots to exist is the software. This point is beautifully explained by Gajamohan Mohanarajah, CEO of Rapyuta Robotics in his TEDx presentation, where he shows how a PR2 robot can clean a full room when remote controlled by a human. The mechanics to do that is already on place and working. The electronics too. The only point missing is the software, and that is why some person must remote control it.
It is software where the final barrier is. And by saying that, I’m not trying to start a kind of religious war. I’m just stating a fact, like the video of Gajamohan beautifully expresses.
However, thinking of software as something simple is not their fault. Mechanics and electronics engineers suffer the problem of not being able to iterate fast (building a new version of a mechanical piece or electronic board can take days for them, but for us it just takes some seconds to change the code and relaunch). So, they cannot understand how is it that it takes us so long to do the program right, when development can be so fast. Also, anybody can do a program that does something. So, the perception that software is easy task.
Reasons to adopt ROS in a startup
The reasons why I believe that ROS is key for a robotics startup:
- Creating the MVP. I may accept that you do not use ROS for your product. But, what about building the MVP? (Minimum Viable Product). Again, are we talking about building a business or a hobby? If it is a business, you cannot build your product from scratch, develop all the fancy electronic boards and mechanics, and then hope to see if there is a market. You first create an MVP and test it with the public. No way there is a faster way to create such an MVP of a service robotics product than with ROS.
- Time to market and maintenance. You cannot build a complex robotics product faster if you need to develop all the software. Is going to take ages to have the software right. Unless you contract a team of software developers, good software developers, I mean, expensive ones. And remember that the team will have to build, not only the robot software, but the tools to debug and find errors (all that provided off-the-shelf by ROS).
- Community ready to use your product. The number of people that knows ROS is increasing year after year. You need your product to be adopted fast. Also, you need that people from the world start developing for your robot. Finally there is the access to the community. By not making a ROS product, your product is completly out of the ROS circuit, so you cannot have access to all the code that is writen by third parties. You will have to start creating your own community. That is an overhead.
- Recruitment. It’s easier and faster to recruit for people with ROS knowledge that will be up to speed at your company faster.
As you can see, all the reasons I argue are business related. None are about the engineers are experiencing while developing.
While you are doing your first SLAM algorithm that works, your competitors are already making the robot understand vocal commands + SLAM + manipulation by using ROS. And the things just get worst as the project evolves, and you need to maintain the software.
Conclusion
In my opinion, I think that the article is more about doing the things one likes to do than doing an effective work. Being efficient but not effective. I think that for a startup, the opposite must be the aim (being effective, not efficient). Also the article is stating a lack of knowledge of ROS and how it can speed up the product to market time and simplify in the future the maintenance of the product.
I do understand that ROS has a stepped curve of learning, specially if you are not a software developer. That is why at our company, The Construct, we have built an online academy for fast learning of ROS (Robot Ignite Academy). I heavily recommend everybody to give it a try for free here and see how easy it could be to learn ROS with a good method (additionally, in case you like it, you can use the discount coupon MVP01201 for a 10% discount).
I can only say that Pulurobotic’s competitors are do using ROS. Here of some of the competitors that use ROS:
- Robotnik Summit XL
- Milvus Robotics MRP2
- Neobotix MPO-700
- Husarion ROSbot
- Pal Robotics PMB-2
- ClearPath Ridgeback
Judge by yourself.
Definitions:
- Efficient: doing tasks very fast
- Effective: doing the tasks that matter
The writer mentions his companies ‘Code Academy’ and offers a free trial.
Funny in looking at said website what I saw started at 15 Euro per month and further options were all more expensive.
You can try the first chapter of each course for free. That is a free trial, since first chapters contain many exercises to work with.
I have cross skills in software engineering, automated manufacturing systems, and another field. One company in the other field spends one billion dollars a day to service humans. I want to reach a large market like this with human-friendly robotics. My question is this:
Suppose you wanted to build a bipedal robot that needed to have “reasonable” resemblance and strength of a human. I can arrange for training, testing & certification with my customer base in this other field. It only needs to perform a well-defined, limited number of tasks that have not changed in years.
I have watched your Construct videos. You’re great.
I’m still in ROS’ steep learning curve making slow but steady progress, but I never give up.
Would ROS be a good platform to start with? Or, is another company’s methodology better?
It would NOT have to drive a car, fly, cross a battlefield, chase bad guys, walk down a slope, or anything like that, and serve mostly on flat floors in a confined area. It may have to climb a few steps, though, but not up a flight of stairs.
I was thinking ROS can easily handle everything above the waist, but what about legs – a must have.
I appreciate your advice in advance.
John
Hi John,
for the control of the legs in real time you would need to use OROCOS and interface it with ROS as the whole robot framework.
Please, have a look at the ROS Developers Podcast #1 where we interview Luca Marchionni from Pal Robotics (https://www.theconstruct.ai/rdp-001-programming-human-size-humanoid-robots-luca-marchionni/) and he explains how he does for controlling human size humanoid robots with ROS.
Both of you (The Construct and Pulurbotics) have valid points, simply you are looking at robotics from different views (and maturity levels). To date I have built several mobile robotic platforms. My first robot used a simple integrated board (arduino), and the current iteration uses a NUC i7. From my experience building mobile robots, Pulurobotics will become very limited down the road. They will then investigate the root cause for the limitations, and will end up adding more hardware. Once they add more hardware, they will find themselves adopting some sort of middleware to manage all the data. This is what happened to me and my robots. ROS is amazing, and the Construct is a great tool for navigating a very complex tool.
Ricardo, thanks for using your experience to provide arguments for ROS. It’s always better to provide a proper response to arguments which can steer people in the wrong direction. I hope you make this response public and not simply an email to your customers.
Keep up the good work!
Mike
I completely agree with you Mike. The level of maturity is what creates the necessity to have something more complex like ROS.
Thanks a lot for your comments
Pulurobotics gives out quite an offer:
http://pulurobotics.fi/blog/pulurobotics-blog-1/post/see-you-at-fosdem-2018-15
”
We will also give you an opportunity to pre-order for Pulu S, that will be equipped with FOUR 3D TOF -sensors, able to see 360 degrees around it in DIRECT SUNLIGHT. The developer price for the model is
PULU – S
999.00 EUR VAT0%
when ordered at Fosdem. Delivery latest July 2018,
Recommended Retail Price will be 1999.00 Eur VAT0%.
”
CAN THIS BE ACHIEVED WITH ROS?
Price is not directly related with ROS. ROS is free. What makes the robot more or less expensive is the material you put on it. So, to answer the questions, yes, you can create the same robot with ROS for that price.
Robotnik Summit XL
Milvus Robotics MRP2
Neobotix MPO-700
Husarion ROSbot
Pal Robotics PMB-2
ClearPath Ridgeback
Can i have any of these for less than $20K?
You are actually promoting Pulurobot with this comparison. Theri price is 1/10th of these :).
Your informercial is good all the way until you start selling.
Thanks for your comment.
I’d be happy that Pulurobot succeeds in their business. If I can promote them, I’d be also happy. That is not the point.
The point is that using ROS decreases the time to market and maintenance time. That is not an opinion, is a fact.
If you can do a robotic product for 20K$ without ROS, somebody else can do the same robotic product in half the time with ROS and reduce the maintenance time. That guy will beat you at the market.
I guess you are from research background. Have you ever seen any commercial product driven by ros? Have you ever deal with a tight BOM budget for a real working industrial product? Making a real product by not customerising your own PCB and by purchaing ready-to-use product, I think this is a joke. The optimum is to buy module and redesign own PCB.
Sure, you can build a prototype with ROS, but when come to real product, I don’t think so.
We have been testing ros code with clearpath HUSKY AGV, they are great and also very expensive. But for the real product, we re-write every single line of code using pure c/c++ with STM32F407 and Jetson TX2 Module.
Simply put, ROS is not for real product for now, I am totoally with Pulurobotics.
I do agree with most of your points. However,
Robotnik Summit XL
Milvus Robotics MRP2
Neobotix MPO-700
Husarion ROSbot
Pal Robotics PMB-2
ClearPath Ridgeback
are poor examples of “real robot products”. These robots are in fact platforms marketed towards research and universities where people build upon them using ROS. I am looking for more examples where a company was able to deploy ROS on larger scale as a real product, i.e. including the maintanance, updates, etc. ; not only as a prototype (and yes, as you write, ROS is great for MVP). I can think of Clearpath Otto.
This was meant to be a comment in itself, not a reply to that comment above.
The mechanical and hardware engineers don’t recognize the reason why software came into existence: to solve the hard, complex problems that were beyond the capability of mechanics and hardware. Note, I did not say beyond the engineers.
Ubiquity Robotics builds a platform similar in concept to the Pulu, bit using ROS. Because We use ROS, adding CA sensor like a Lidar takes less than an hour. It is also possible to use inexpensive single board computers like the Raspberry Pi 3B.
It is true that ROS has a formidable learning curve. Our joke is that it is a learning cliff! However sites like Learn Turtlebot with ROS and many other online books have made this easier.
So all in all I am in total agreement with this article. For a Startup, using ROS is a no brainer. First rule of software development is never write anything from scratch if existing code already exists.
Hello, I thought I’d take this opportunity to chime in from the perspective of a developer who is trying to learn ROS “just for fun”.
First of all, I know nothing about robotics. I immediately loved the design and architecture that ROS promotes. I understood the concepts really, really fast, because it makes complete sense. What’s more, none of the concepts felt strange to other more traditional SW fields. I also loved the promise of the awesome things that one can achieve with it’s already available plugins.
Having said that, I can’t remember learning anything in the past 10 years that even remotely resembles the amount of friction that ROS has for newcomers. I love the tooling they provide, the amount of plugins it has, but I think the developer experience has been relegated to the extreme. Also the community may be huge for the current size of the field, but is not nearly as “vibrant” as other more common fields. I think there’s tons to learn and improve. And while I’m more inclined to think like Ricardo (author of this article) I can totally see where the criticism to ROS comes from.
I love robot ignite academy’s courses, and think I’ll sign up for a few of them, but IMO no platform should require you to pay monthly to a 3rd party in order to learn the basics. I mean it’s great that it’s an option, but I think it’s not a good first impression.
Cheers!
ROS is bad software that lacks a real purpose. Most of the features of ROS seem to exist because the people developing and using the software don’t realize there are other alternatives. It is funny how you characterize the criticism of ROS as coming from people who aren’t developers. In my experience, ROS caters to non-developers by providing them “easy to use” alternatives to more conventional software techniques.
For example, instead of learning how to interface with a lidar driver using C++ or C, you will use rostopics. Supposedly this is easier, but can I ask how? If the person is already writing C++, then what advantage is there to use ROS as a middle-layer to communicate with this lidar? Why create ros nodes, publishers, etc. acting as middleware? All it does is bloat your code, add a lot of overhead (ROS is needlessly inefficient and has memory leaks) and cause confusion.
Every sort of sensor I’ve come across has had both a C/C++ interface and a ROS interface. Typically the C/C++ interface is much more intuitive and easy to understand, while the ROS part is much messier as a result of having to work around ROS’ bizzare quirks.
Whenever I hear a self-driving startup is “based on ROS,” I imagine that car is going to kill people.
Thanks for your opinion. I really don’t agree with you. The future of robotics is with ROS, whether you like it or not. We’ll see anyway…
I have a lot of experience with ROS, ROS2 and MQTT specifically, and with embedded system in general. From my experience, I have drawn some basic observations and conclusions.
ROS is way overdesigned and not very well planned, by people who had a specific project in mind. If you are designing the exact device they had in mind, with their exact development environment, then ROS will work acceptably well. If you are starting a project from scratch, and it is at all different from their original problem, then ROS will drive you crazy.
ROS was designed for an arduino-like development experience, and uses that same single thread design to try to simplify the task of collecting, disseminating and processing data. There are several problems that this causes. First, the effort required to handle anything other than the boilerplate, “read a sensor every x seconds”, is much larger because ROS forces you to use their event-loop style processing. The second is that the failure mode of this a general slow-down of information processing, where it is practically impossible to prioritize processing. Normal embedded systems use two-tier processing. Event handler like ROS, and background processing that happens whenever higher priority tasks are not interfering. In these embedded systems, every event (called an interrupt) is given a priority, and some events can be allowed to interrupt others, and some have to wait depending on the developers design. ROS does not handle this at all well. ROS is also overkill if you already have an operating system on your device. Because ROS is designed to be an OS (duh, R.O.S.), it duplicates a great deal of the implementation of features that a real-time or regular embedded OS already has, and many of the implementation details in ROS are dictated by the fact that it has to be an OS. With ROS, there is no way to skip this part, and just pick what you want, ROS is all-or-nothing. My last observation is that the ROS build environment is just plain $#!7. They worked form the assumption that the entire system needs to be part of the same build system, and that everything should be compiled at once. At best, this is overkill for 90% of the projects out there, and at worst it is idiotic. I have worked on several different ROS projects, and in every case, the build system has been far more trouble than it is worth.
If all your project really needs is IPC of some kind, you are running Linux already, and want simple, then I recommend MQTT. It is simple, it is straightforward, and it is flexible enough to handle almost every use case. The secret to effectively using MQTT is to have every local device run its own MQTT broker, and setup the brokers with bridging. This gives you an effectively decentralized system, while still maintaining the advantages of having a broker (much easier multi threading and solves a lot of messaging issues that ROS kind of ignores).
ROS1/2 has so many installation permutations that it is almost impossible to install correctly. I have tried several times to install ROS2 on a raspberry pi 4B+ running raspbian buster, and it just ends up with errors that cannot be explained or resolved. I think you are better off just using good old fashioned Python or C++. I have already built several robot cars from scratch using Python3, and was hoping to take advantage of any ROS2 functionality as I experiment with LIDAR but I think I’ll just stick with the Python3 option….
I guess you are from research background. Have you ever seen any commercial product driven by ros? Have you ever deal with a tight BOM budget for a real working industrial product? Making a real product by not customerising your own PCB and by purchaing ready-to-use product, I think this is a joke. The optimum is to buy module and redesign own PCB.
Sure, you can build a prototype with ROS, but when come to real product, I don’t think so.
We have been testing ros code with clearpath HUSKY AGV, they are great and also very expensive. But for the real product, we re-write every single line of code using pure c/c++ with STM32F407 and Jetson TX2 Module.
Simply put, ROS is not for real product for now, I am totoally with Pulurobotics.