Robot Operating System: Why we decided on ROS, gave up, and then returned.
Ahh, Robot Operating System, my old friend…
In the last couple months, my team and I have developed a love-hate relationship with this widely used robotics platform. If you are interested in building a robot, you will probably have similar questions: What is ROS? Should I use it?
- What is ROS?
So when our team decided to build a robot to enter in the AUVSI SUAS drone competition, we started to explore the different (open source) software libraries/tools we had to work with. During our research, we came across ROS: Robot Operating System. Link:http://www.ros.org/
Not actually an operating system, ROS is a open source set of tools/libraries built to help make robot developers’ lives easier. It runs on Linux (Whoo!) which is another win. We started to look into ROS more, excited.
2. Why did we (temporarily) ditch ROS?
But as we worked, we found out that ROS wasn’t the perfect software solution we thought it was at first. We encountered some problems — many were minor, but I have pointed out the biggest ones below. As I will explain later, we found solutions to these problems. NOTE: THESE ISSUES MAY NOT APPLY TO YOUR USE CASE.
- Limited RPi support: we are using a raspberry pi because it is cheap, light, small, uses close to no power, and runs linux. However, since the RPi runs on an ARM based processor, it can be a little bit of a pain to compile for/install some programs. When we looked on the docs, ROS Kinetic was the latest version that was officially documented for use on the pi. We were a bit annoyed.
- The examples led us to believe that ROS had very limited modern C++ support (v14+) which was also a bit of a bummer.
- BIGGEST PROBLEM: We searched quite a bit, but ROS simply didn’t come with Python 3 support! This was probably the turning point for us, since Python 2 is really not something we want to use — it’s old, outdated, doesn’t get any new development, and is just a pain.
3. Why it’s not that great of an idea to ditch ROS
- As it turns out, a lot of open source robotics code integrates with ROS, and only with ROS.
- We couldn’t help feeling that we were missing out on a lot of pre-written boilerplate
- Everywhere we looked, people were using ROS
4. Our temporary solution: ROS2
While searching, we came across ROS2: a library in the works (by the same developers) to solve a lot of the problems we (and other devs) had come across while using ROS. It seemed great, except it wasn’t complete nor did it have a stable API. So in the end, it didn’t really work out. One of the major problems was that since most of the ROS packages hadn’t been ported yet, the boilerplate we aimed to avoid still had to be written from scratch.
5. How we fixed our ROS issues
In the end, we decided that ROS was still probably the best option for us. So, I asked for help with our issues on StackOverflow, and someone was nice enough answer all of them. Below are the solutions to the problems from above.
- Turns out RPi support isn’t bad, it’s just not well documented. Take a look at this. It’s not specifically for RPi, but the tutorial works on latest Raspbian.
- Even though ROS itself isn’t written using new standards, one can make use of most of the new stuff by editing your CMakeLists.txt — there are a few different ways of doing this, so I recommend you just google it.
- ROS doesn’t usually come with Python 3 support, but it can be compiled with some flags to change that. This same link also explains how to do that.
So in the end, we decided to use ROS with all its features, support, and headaches :)
TL;DR: Although ROS isn’t for all use cases, it will probably be useful for your project.
