Guidelines for Testing ROS-based Robots in the Real-World

Interested in testing ROS-based robots in the real-world?

We conducted a study to collect exemplars from the ROS community to assist developers and QA teams in ensuring ROS-based robotic systems’ reliability in real-world scenarios. Thanks to all who took their valuable time to answer our questionnaire (link) earlier this year.

We are thrilled to share the results of our study! It is a set of 20 guidelines with concrete exemplars (e.g., tools, methods, and code snippets) to assist with runtime verification and field-based testing for ROS-based robotic systems.

The guidelines are documented in a dedicated website:

For further details, there is a full paper in ArXiV:

Ultimately, we believe the guidelines should be a live piece of work and grow with this fast-evolving community. We prepared instructions: contribute to the guidelines!.

Let me know what you think!

Ricardo D. Caldas


Thanks for sharing!

We become more and more convinced that the major field-test improvement is achieved when you provide your robot with a speaker, sound_play and a simple interface (let’s say topic /say) via which nodes can report when something goes haywire or via which the robot explains what it is currently thinking/doing. Imagine the robot says not enough disk space instead of you finding after the test that the bags would not fit!


Interesting approach @peci1!

Sounds like some form of runtime monitoring though instead of checking at runtime with some specification, it informs the operators. I like it because it involves the operator in the checking rather than specifications (which are often hard to find)! Do you have some experiments or any a report explaining how has the sound_play package been used in a field test?

No formal reports we’d have written. But years of usage. We have a robot with problematic motor drivers, and when the driver node decides it is time to reset them, which takes a few seconds, it stops the robot and says what it is doing so that the operator is not confused. Similarly, we have audio warnings for low battery level which is also quite useful during experiments. Our compass calibration tool gives audio instructions to the operator regarding when to start and stop rotating the robot.

We also had project-specific audible feedback like reporting when GNSS fix covariance grew above a specified limit. Or, when DARPA personnel extracted our robots from tunnels during SubT challenge, the robots talked to them to confirm they are correctly estopped or they also said jokes :slight_smile:

Recently, we added our robots the ability to introduce themselves when there are people visiting our lab. It is kind of subpar to intro by humans (the TTS is not easy to comprehend), but very popular.

The good thing about sound_play is it offers a topic for specifications of the sound to play/say, so we also sometimes run one sound interpreter on the robot itself and another one on the operator PC so that the operator can hear the audible feedback even when the robot is far away. And the only thing that is transmitted over network is the text to say, no audio streaming.