The “Chaos” of the Physical World and the Frustration of Real-Robot Testing

 In my daily scientific research life, deriving formulas and writing code occupy the vast majority of my time.

Putting the completed localization and mapping algorithms into a microcomputer, hoping that they will run smoothly in a real environment—this is almost a daily wish of mine.

These algorithms are generally referred to as SLAM (Simultaneous Localization and Mapping). It is one of the core technologies for enabling robots to achieve autonomous navigation in unknown environments.

When I first started working with this type of algorithm, I had a common obsession among science and engineering students—I always felt that only by assembling various sensors onto a small cart and letting it actually run several laps around the campus or hallways could the results be considered true scientific research.

It seemed that only by gathering a little dust from the physical world could the algorithm be considered grounded in reality.

However, this obsession was soon shattered by reality.

During the real-robot testing phase, the system would always “crash” due to various unexpected situations.

Sometimes it was a sudden change in lighting in the corridor, causing the visual feature extraction to fail instantly; sometimes it was an extremely minor unevenness on the road surface, causing the wheel odometry to produce an imperceptible slip; and it could even be merely a few milliseconds of error in the hardware timestamps between different sensors, ultimately causing the entire motion trajectory to become severely distorted during backend optimization.

What was most frustrating was that debugging algorithms in a real physical environment often felt like groping around in a “black box”. In the real physical world, it is very difficult for us to obtain the absolute and precise six-degree-of-freedom pose ground truth for the robot at every moment.

Thus, when drifting point clouds and distorted trajectories appeared on the screen, it was hard for me to immediately pinpoint the root cause of the problem: Was the code for the Lie algebra pose transformation written incorrectly? Was the threshold setting for PCL point cloud processing unreasonable? Or was the residual weight in Ceres Solver set improperly?

Without ground truth as a reference, algorithm parameter tuning easily degenerated into a game of trial and error. In the cycle of repeatedly pushing the cart, copying data, and modifying code, a great deal of time was consumed in eliminating hardware interference and locating unknown bugs.

Returning to the Essence of Engineering: Building Scaffolding in a Virtual Sandbox

In the process of repeatedly troubleshooting code and hardware wiring, I began to reexamine the value of simulation technology.

In the field of aerospace and other large-scale equipment development, there is a very basic piece of common sense: before engineers build a real aircraft, they never directly start hammering metal. Instead, they first establish a simplified model and test it in a wind tunnel or on a computer to see whether the structure is correct and whether the force logic makes sense.

To put it bluntly, developing real equipment is essentially a process of making the “model” increasingly realistic and increasingly complex.

Developing a complex localization and mapping system is, in essence, also a form of precision engineering research and development.

Under this logic, the robot in a simulation environment is actually a more rigorous and sophisticated “big toy”. It is just like those car and airplane models we repeatedly took apart as children. They all serve the same purpose: to allow us to complete a logical verification within controllable boundaries before we face the real, complex system.

So, I began spending more time building test scenarios in the simulator.

This is a pure, highly idealized digital environment, where all variables are transparent and quantifiable. I can freely control the richness of environmental textures, set different structural features, and even add noise models that conform to specific Gaussian distributions to the virtual sensors.

In this “digital sandbox”, the greatest advantage is having absolutely precise ground truth.

I can know exactly where the robot is in the absolute coordinate system at any given moment.

With this benchmark, verifying the accuracy of front-end feature extraction, identifying subtle errors in Jacobian matrix derivation, and evaluating the effectiveness of back-end nonlinear optimization are no longer matters of intuition or guesswork.

Instead, they become rigorous scientific reasoning and engineering analysis.

Simulation technology is, in essence, a “navigator” in engineering research and development.

It can eliminate countless unreasonable design solutions in a virtual space, helping us quickly converge on the optimal solution.

 My Simulation Validation Workflow

After becoming accustomed to this approach, my research workflow underwent a shift more akin to “agile development”. Typically, I would first derive rigorous mathematical formulas. Then, in a C++ environment, I would painstakingly work through the underlying logic, skillfully calling upon the Eigen and Sophus libraries to handle tedious matrix operations and pose transformations. However, after writing the code, I would not immediately deploy it on the actual vehicle. Instead, I would first integrate the algorithm into the simulation scenarios I had already built. In the simulator, I would artificially set some extreme boundary conditions, such as: having the robot traverse a long, nearly featureless corridor, or undergo a sharp in-place rotation. The simulation environment acts like a very strict filter, capable of quickly exposing logical flaws in the algorithm under extreme operating conditions. After the test run is complete, I would export the standard trajectory file. Then, using Python scripts, I would leverage NumPy and SciPy to batch-parse this TUM-format data. Finally, using Matplotlib, I would plot the error curve between the algorithm’s estimated trajectory and the ground truth trajectory. Watching the curve formed by discrete data points on the screen—from an initial state of divergence, through repeated adjustments to the logic and constraints, until it steadily converges within the expected error range—the sense of solidity at that moment is the most gratifying instant for every science and engineering student who writes code.

 Moving Toward Reality: Simulation Is Not the Destination, but the Foundation of Confidence

Of course, we all understand: all engineering design and optimization must ultimately be implemented in real systems. The purpose of simulation has never been to let engineers stay forever in a perfect virtual world, indulging in self-satisfaction. Its true value lies in enabling successful deployment in the real world. From the traditional, experience-based approach of “tuning parameters in the dark” to simulation verification grounded in physics engines, this process has given me a firsthand appreciation of the importance of engineering validation methods. The experience accumulated, the problems discovered, and the hidden risks identified in the virtual space ultimately become the bedrock of confidence for the smooth implementation of real-world experiments. Now, when I once again push the sensor-laden cart into a complex environment, I feel far less apprehension in my heart. Because I know: before it actually turns its wheels, this algorithm has already undergone hundreds or even thousands of tests in that invisible virtual sandbox.

Conclusion

If I were to summarize my experience in a single sentence, it would come down to three points:

1. For complex robotic systems, always verify the logic in simulation first.

2. Ground truth data is the most important benchmark for debugging algorithms.

3. Simulation is not the destination, but the foundation of confidence for moving toward the real world.

Scientific research is a long-distance race. Faced with the complex physical world, it is difficult for us to achieve success overnight. However, these “digital scaffolds” built in the virtual world are steadily and reliably paving the road toward reality, one step at a time.