Modelling and Model-Checking a ROS2 Multi-Robot System using Timed Rebeca

In the world of robotics, building a single machine that moves and thinks is difficult enough. Building a team of them that works together without crashing into each other is a different kind of challenge entirely. These machines, often called autonomous mobile robots, are designed to navigate real environments, avoiding walls, people, and one another while trying to reach specific destinations. The software that runs them is incredibly complex, relying on a constant stream of data from sensors like lasers to understand where they are and what is around them. Because these robots operate in a continuous physical world, their movements are smooth and fluid, changing by tiny fractions of a second and millimeters of distance. However, the computers that control them think in discrete steps, processing information in distinct chunks of time. This gap between the smooth reality of physics and the step-by-step logic of code creates a dangerous blind spot. If the software is not perfectly tuned, a robot might move too fast for its sensors to catch an obstacle, or two robots might arrive at the same intersection at the exact same moment, leading to a deadlock where neither can move.

To solve this, researchers need a way to test every possible scenario a robot team could face before they ever turn on the real machines. This is where a field called formal verification comes in. Instead of running a simulation a few times and hoping for the best, formal verification uses mathematical logic to check every single path a system could take. It asks a simple but powerful question: is there any possible sequence of events, no matter how unlikely, that causes the system to fail? For a team of robots, this means proving that they will never collide, never get stuck forever, and will always reach their goals. The challenge has always been that real robots move in a continuous world, while these mathematical proofs require the world to be broken down into a grid of fixed steps. If the steps are too big, the proof misses small but critical accidents. If the steps are too small, the computer gets overwhelmed by the sheer number of possibilities and cannot finish the calculation.

A team of researchers at Mälardalen University and KTH Royal Institute of Technology in Sweden has developed a new way to bridge this gap. They created a system that allows engineers to design a multi-robot team using a specialized modeling language called Timed Rebeca, which treats each robot as an independent actor that reacts to messages. This model is then rigorously checked by a computer to ensure safety. Crucially, the team also wrote the actual software for the robots using a standard system called ROS2, ensuring that the mathematical model and the real code were perfectly aligned. They did not just simulate the robots; they built a version of the model that was abstract enough to be checked by a computer but detailed enough to reflect the real physics of the machines. By doing this, they could predict rare and dangerous failures that standard simulations often miss.

The researchers focused on a scenario involving five robots moving across a fifty-by-fifty grid, a space roughly the size of a large warehouse floor. They set up a complex environment where the robots had to navigate around obstacles and cross each other's paths to reach their targets. In the real world, these robots use laser scanners to detect objects, taking measurements hundreds of times per second. The team had to figure out how to translate these continuous laser beams and smooth movements into the discrete steps required for the computer to check the logic. They discovered that there is a strict relationship between how fast a robot moves and how often it scans its surroundings. If a robot moves too quickly, it can travel the entire distance between two scans without the sensor noticing an obstacle in its path. The researchers proved that for their model to be accurate, the robot's speed had to be limited so that it could not cross a grid cell faster than the time it took for the sensor to update. This rule, derived from a fundamental principle of signal processing, ensured that the digital model did not miss any potential collisions.

To make the computer check feasible, the team had to simplify the world without losing the truth of the problem. They represented the robots not as smooth shapes, but as rectangles moving from one square cell to another, turning in forty-five-degree increments. They calculated the time it took to move between these cells based on the robot's speed and the size of the cell. They also pre-computed complex trigonometric values, such as the sine and cosine of angles, and stored them in lookup tables so the computer did not have to calculate them from scratch every time. These optimizations allowed the model checker to explore millions of possible states in a matter of minutes. When they ran the check, the computer could tell them with absolute certainty whether a specific set of rules would lead to a crash or a safe arrival.

The results of their experiments were striking. In cases where the robots were programmed with safe speeds and varied wait times, the model checker confirmed that all five robots would reach their destinations without ever colliding or getting stuck. The researchers then ran the actual ROS2 code in a simulation, and the robots behaved exactly as the model predicted, navigating the crowded space successfully. However, when they changed the parameters to create a dangerous situation—such as making all the robots move at the exact same speed or setting the scan rate too low for the speed—the model checker immediately found a flaw. It identified a specific sequence of events that would lead to a collision. When they ran the real code with these same dangerous settings, the simulation crashed in the exact same way the model had predicted. In one test, the model found a collision after exploring only a few thousand states, while the real simulation failed three out of five times, confirming that the danger was real and predictable.

The study also highlighted the importance of timing. In one scenario, the researchers set the robots to move at a speed that was just barely too fast for the sensor update rate. The model checker found that this small violation of the safety rule made a collision almost inevitable, regardless of how the robots were programmed to avoid each other. The computer showed that the robots would arrive at a crossing point at the same time, and because they could not see each other in time, they would crash. The real simulation confirmed this, with the robots failing to avoid each other in every single run. This demonstrated that the model was not just a theoretical exercise but a practical tool that could catch subtle, dangerous errors that human engineers might overlook.

The researchers acknowledged that their approach has limits. The current method requires engineers to manually build both the mathematical model and the real code, which is a time-consuming process that could introduce human error. They also noted that while their system could handle five robots on a fifty-by-fifty grid, scaling it up to a hundred robots or a much larger map would quickly overwhelm the computer's memory. The bottleneck is the sheer number of possible paths the robots can take; as the number of robots and the size of the map increase, the number of combinations grows so fast that the computer runs out of space to store them. Despite these limitations, the work proves that it is possible to create a digital twin of a complex robotic system that is both simple enough to check and accurate enough to trust.

This research offers a new path for developing safe autonomous systems. By treating the design of robot software as a process of building and verifying a mathematical model first, engineers can identify fatal flaws before a single robot is built or deployed. The team showed that by carefully balancing the level of detail in the model with the need for computational efficiency, it is possible to verify that a multi-robot system will behave safely in the real world. Their work suggests that the future of robotics lies not just in building smarter machines, but in building better ways to prove that those machines will not fail when it matters most.