Is ROS (Robot Operating System) mandatory?

Question

Do we have to build ROS for robotic research/application? What is the main advantage? When or in which situations ROS is mandatory?

Answer 1

I'm back to a computer!

Like I said in this comment, ROS is generally not mandatory. ROS is one platform among many, famous mostly due to Willow Garage giving away free robots at some point in time to whoever wrote the most ROS modules. That said, it's not the best platform possible, and is certainly nothing overly special. Particularly, the said contest resulted in a lot of low-quality modules just to get the numbers higher.

Over time, the quality of the ROS modules have got better and there are a lot of them as well. Using ROS therefore, you have the benefit of reusing a lot of what's already done. You can read here some reasons why you may want to use ROS.

With that in mind, you should look out for the side effects as well.

Distributed Control

With ROS, you have many nodes that talk with each other through the network. This is sometimes good and easy, but generally results in a wildly varying delay in reception of messages. As a result, you would have to have a large control delay to make sure all messages arrive, which means you cannot react fast to events, which in turn means you have to move your robot at slower speeds so as not to miss those events.

Believe it or not, people actually do robot control through ROS (MoveIt! is the name of the relevant set of components). Slow. Unsafe. But easy!

Non-Real-time

Even when not distributed, ROS is not a real-time platform. That means you are at complete discretion of the Linux kernel to schedule your tasks at any time it sees fit. This is ok for some applications, but not ok for others. So you need to look at your own requirements. Do you need to have a guarantee that your task would finish within a known time frame? If so, you need a real-time system.

Hosted Runtime Environment

Another point to consider is that, while ROS is a general protocol of communication, it's essentially only supported for hosted environments. Hosted means the code runs on top of a kernel, as opposed to freestanding which means the code directly controls the hardware (e.g., on a microcontroller).

If your robotics application is run close to hardware, and therefore you would require a program that runs on a microcontroller, ROS is of no help to you.

Platform Lock-in

Last but not least, developing for ROS results in a platform lock-in. This means that if in the future, for one reason or another, you decide to base your work on another robotic platform, such as OROCOS, YARP, etc, that would be excruciating.

You would also be somewhat locked to Linux. Linux is the best, no doubt, but one day you may end up having to support another system, such as QNX, VxWorks etc, and you would have problems there as well.

---

If you are writing for microcontrollers, then forget about ROS. If you are writing high-level modules, I highly recommend writing portable code. For example, say you have developed a new sensor, and you want to write a module that acquires data from this sensor, which is connected to your computer via the CAN bus.

What you could do in this situation is to write an independent library, with functions that are able to work with your sensor and acquire data. You could even think of spawning a thread in the library that acquires and enqueues data periodically.

Once you have this helper library, you are free to write a CLI, GUI, ROS module, OROCOS module, YARP module, connect to Matlab, or whatever else you want to use to interact with your sensor.

Final note: what I've said here is generally applicable to all robotics platforms and not just ROS.

Answer 2

"ROS" is a relative term, the APM runs full custom code specifically designed for quadrocopter control where a custom ROS might be desirable to keep from crashing, on the other hand the Navio+ runs on a Linux kernel and runs code other than the autopilot, and still manages to keep from crashing. Most ROSs are really a set of functions on top of an existing OS as opposed to writing an os from the ground up. As with anything, it depends.

Answer 3

Disclaimer: This answer is somehow a reaction to the Shahbaz' post, so it has a pro-ROS bias.

I do not think that ROS is mandatory, but it is a great starting point and worth the time to invest. It started within Willow Garage, but this company vanished and ROS is still alive, used and developed. Most of ROS is fully open source and also commercially usable so there is no way that ROS is just going to vanish if a company is no longer interested in it. The code quality of course differs between the core modules and implementations of cutting edge algorithms that some phd student published with his paper.

ROS is picking up more and more speed in industrial settings (I'd be surprised if there is a significant portion of robotics startup worldwide that do not use ROS). Some algorithms are going to be further maintained and developed by the ros-industrial consortium and if you have a look at the members, it's a good bet that ROS is going to become a standard in the industry:

http://rosindustrial.org/ric/current-members/

The distributed way of using ROS helps a lot to create and maintain new packages, especially within teams. The message and action definitions help a lot in defining interfaces so that hardware and algorithms can be exchanged quickly. It also helps to integrate new team members as a new node will node bring down other nodes if it crashes (as long as it does not eat all the RAM..) so it's rather safe to integrate partially working nodes into the running system as their effect is limited. The communication uses TCP which is reliable and fast (on a local machine), so that message passing is very quick (several hundred Hz for a control loop is possible).

Non-Real-Time

ROS is currently not realtime as the vast majority of algorithms have no need for realtime. Sensing or planning does not have realtime constraints in most cases (how many people are building self driving high speed cars?). It's enough if the final control loop runs in realtime and this can in many cases be done directly on the motor (to which the final position is send e.g. via CAN). Real Time however is one of the core goals of ROS2 (https://github.com/ros2/ros2/wiki/Real-Time-Programming) so even if you need this in the future for the whole system, ROS has you covered.

If you really want to run stuff embedded, there is of course a connection to arduino, so that you can write ROS messages directly on the arduino which then are send via serial connection.

Running ROS on Windows is currently rather a pain, but as Windows is moving closer to Linux (even starting to have something bash-like), it's only a matter of time until it's possible. (But who wants to run a robot with windows anyway?)

Hardware Interfaces and Algorithms:

I think this really is a strong point for ROS. A lot of commercially available robots already come with a ROS interface or someone already invested some time to implement the interface. Most commercial arms can be used in MoveIt so much of the work to get an application to run with a specific arm can be reused with another hardware.

Community:

Another strong point for ROS. New algorithms get a ROS-interface very quickly and a lot of people had the same problems as you so you will find someone to help you.

http://download.ros.org/downloads/metrics/metrics-report-2016-07.pdf