0
$\begingroup$

I have a general question about ROS - since it is NOT a real-time operating system(nor is Linux which it runs on), why can it be used for robotics applications which almost always have real time performance needs?

Basically unless you can put an upper bound on your perception and motion task times I don't understand how anything can actually work on a physical system - can someone explain?

$\endgroup$
  • $\begingroup$ can it be used on robots that require real time response? $\endgroup$ – jsotola Sep 19 at 19:13
2
$\begingroup$

Let's start with a pick and place robot (a robot arm with a camera and a suction cup that recognizes object in a bin and picks them individually). We can move the robot above the box, and simply wait until we have a captured an image, segmented the objects and computed grasping points and collision free trajectories. We then move to robot to a grasping position, activate the pump and wait until we have grasped something. No need for any real-time in the perception and motion planning part. The motors however have to be controlled in a real-time loop so that they are moving synchronous and immediately stop as soon as a human comes to close to the robot. This part needs to be hard real time. The whole system could for example be built by a ROS-part that does perception and motion planning and an ABB-Robot (with its own fast(!) realtime controller) that now and then gets new goal poses from the ROS-part and executes them while sending its current configuration back to ROS.

The most important issue here is that we can stop the robot while we are thinking. This does not work if your robot is a drone or a fast moving car. In the drone cases, we need at least a (fast) real time flight controller that keeps the drone flying while we for example send image data to a ground station to decide where to fly next.

In many applications, only small subsystems (mostly the motors) need to be controlled in real-time and the higher level tasks (perception, planning, reasoning, visualization, logging, multi-robot coordination) can take as long as they want. Trying to implement them in real time would be extremely difficult and completely unnecessary.

Update:

Another important point about real-time vs non-real-time is its definition.

It does NOT(!) mean that the system can process sensor data very quickly and can therefore react immediately to new sensor data (e.g. child running in front of car). It only means that the system guarantees to perform a computation within a certain time limit. It is perfectly possible that this time limit is in the range of seconds. For a motor controller (as used above), you need a real-time system that has a guaranteed maximal computation duration in the ms-range. So even if you port ROS to real-time (which is currently done with ROS2), you don't magically are able to control fast moving robots.

So real-time is required, but not sufficient for controlling (the moving parts of) robots.

$\endgroup$
  • $\begingroup$ So for mobile robot applications it becomes completely useless - ex, Tesla and the other car auto-pilots need a RTOS in order to function. I think ROS will always be kind of a gimmick until it's ported to real time because you can't trust it for real applications. $\endgroup$ – FourierFlux Sep 19 at 22:21
  • 2
    $\begingroup$ "kind of a gimmick" See, you obviously never worked in robotics, so I don't even consider this rude, but just childish. No one said that ROS can be used in every application, and a lot of real, commercial applications are running on ROS (locusrobotics.com, fetchrobotics.com, magazino.eu all run on ROS, and simply have a look at the members of the ros-industrial consortium: rosindustrial.org/ric/current-members (and most of them have been members, before anyone thought about ROS2). $\endgroup$ – FooTheBar Sep 20 at 6:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.