Recently, we want to achieve robot auto-navigation by using laser SLAM based on ROS system.but we found that ROS could not meet the requirements for real-time response.
We are making a mobile car platform（based on ubuntu16.04 and ros kineckt）, requiring the speed of the car can reach 2m/s, and in the car to rely on laser sensors for slam and obstacle avoidance. By testing, the laser sensor sends a stop command to the drive from an obstacle that detects the distance from the 4m to the system response, and the time of the process (T1) is from 40ms to 100ms. However, the possible maximum of T1 is not 100ms, may be greater, this period of time is uncontrollable. We want T1 to have a controllable maximum (such as 50ms), and the smaller the maximum, the better.
We try to give Ubuntu RT_PREEMPT real-time patch, and lock memory,set the process priority and schedule strategy to the all the nodes we used. But there is no improvement.
Through investigation，we now have two plans:
1 learn and use Open RObot COntrol Software（OROCOS-RTT）
2 learn ros_control (realtime_tools) method.
Ask experienced predecessors to give advice, help, or different solutions.thanks for your advise.
But maybe these are all positive points. There are some other advantages of ROS, like the very fact the there are lot more people involved in its maintenance and the number of active users is much higher.
There are also numerous examples on ros_control. I have only used this one which is a node for communication with an industrial KUKA via some KUKA defined RSI standard.
ROS itself is not designed for real time. It is hard to get good real time performance based on ROS although your best practice on memory allocation, PREEMPT_RT patch, scheduler. Actually, I am also looking at real time, but using ROS2.
from you question it is hard to understand the root of the problem. Is it throughput or latency/jitter?
It is hard to believe that a SLAM algorithm, that usually runs at less than 30 hz, might have any problem of latency when PREEMP_RT is installed.
I agree that ROS 1 is not meant to be used to build real-time system, but usually you notice this limitation with control algorithms that runs at 200+ Hz.
Using Orocos without understanding what the problem is, it is probably the wrong thing to do. Additionally, I suggest you to first understand what makes orcos different from ROS and in which cases it helps
My instinct is telling me that your problem is not real-time but a wrong utilization of your CPU. May be you are running an algorithm that can be parallelized to use all the CPUs of your system at once and meet your time constraints.
I suggest you to carefully profile your application to understand what the bottleneck is.
EDIT: If you do think the problem is latency and NOT throughput, try using ros_control and nodelets.
Hi,
thanks for your advise.
We are making a mobile car platform（based on ubuntu and ros1）, requiring the speed of the car can reach 2m/s, and in the car to rely on laser sensors for slam and obstacle avoidance. By testing, the laser sensor sends a stop command to the drive from an obstacle that detects the distance from the 4m to the system response, and the time of the process (T1) is from 40ms to 100ms. However, the possible maximum of T1 is not 100ms, may be greater, this period of time is uncontrollable. We want T1 to have a controllable maximum (such as 50ms), and the smaller the maximum, the better.
Can you give me any suggestion in this case?
thank you！
A ROS 1 system made up of multiple nodes is inherently non-deterministic. You will probably have to do a lot of work to make T1 have a fixed maximum.
One approach you can take is to rewrite the nodes you are using for your process to be nodelets. That will remove the uncertainty of the communication between nodes, which should give a more stable processing loop.
Another option is to switch to ROS 2. There are facilities in ROS 2 that are designed for solving this problem. The downside is you will likely need to do a lot of porting work, but I think that in the long term this approach would give the best result.
There is also going to be a talk by Ingo Lütkebohle from Bosch about exactly this sort of problem at ROSCon. If you can’t make it to ROSCon, the talks will be available online after the conference finishes, and they will probably be live streamed as well.
As Geoff already mentioned, I will be talking about such things at ROSCon in more detail.
Some of the things you could check in your system:
What’s your CPU load? If it’s high -> What else is running on the machine?
What’s your sensor data-rate?
What’s your sensor delay (the time between the physical measurement and when the sensor sends it out)?
Are your components time-triggered (ros::Rate or ros:Timer) or data-triggered (subscriber callback)? For minimal latency, data-triggering is preferable
Is NO_DELAY enabled on your subscribers?
What’s the computational complexity of your obstacle avoidance algorithm?