iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🦾

Introduction to Sim-To-Real: Fail 10,000 Times in Sim Before Breaking the Real Robot (Concepts)

に公開

1. Breaking through the "Despair" of Robot Development with AI

Robot development, especially learning for "autonomous driving" or "balance control," has traditionally been a very "gritty" process.
Every time you try a new program, the robot crashes spectacularly, plastic parts break, and motors burn out. Engineers spent more time holding a soldering iron for repairs than writing code... This era lasted for a long time.

However, in modern AI development, a powerful paradigm shift called "Sim-To-Real (Simulation to Reality)" is occurring.

What is Sim-To-Real?

In short, it is a method of "training AI in a virtual space equipped with a physics engine and then porting only the completed 'brain' to a real robot."

From NASA's Mars rovers to Tesla's self-driving cars and competitive robots like the "ET Robocon," which is the subject of this article, this method has become the standard in cutting-edge fields.


2. Why It Must Be "Simulation"

You might think, "Isn't it more reliable to adjust on the actual machine from the start?" However, simulation has three overwhelming advantages that an actual machine simply cannot match.

① "Repair Costs" and "Time" are Zero

In virtual space, even if a robot hits a wall at 100 km/h, you just stop the program with Ctrl+C. The next moment, an undamaged robot starts running again. A total wreck that would require weeks of repair in reality can be reset in 0.1 seconds in a simulation.

② "Time Acceleration" and "Parallelization"

One hour in reality is one hour. However, inside a PC, by simplifying physical calculations or utilizing high-spec CPUs, you can finish "one hour of reality in 10 minutes of simulation."
Furthermore, if you launch 100 virtual spaces simultaneously, it's even possible to gain 1,000 hours worth of driving data in just one hour.

③ Debugging with a "God's Eye View"

To accurately know the tilt or speed of a real robot, expensive sensors are required. However, within a simulation, information such as "how many millimeters the center of gravity shifted" or "how many Newtons the tire friction force is" can be obtained as "true values" with zero error.


3. The "Vessel" of the Virtual World: The Role of PyBullet and Physics Engines

To nurture AI, the environment must follow "physics laws identical to reality." The engine we are using this time is PyBullet.

What the Physics Engine Calculates

A physics engine continuously solves calculations like the following formulas hundreds of times per second (e.g., 240Hz):

F = ma
τ = I\alpha

(Force is mass × acceleration, and torque is moment of inertia × angular acceleration.)

This reproduces gravity, friction, air resistance, and bouncing upon collision.

The "DNA" of a Robot: URDF Files

A robot in a simulation is not just an image. Its "physical characteristics" are defined in an XML format file called URDF (Unified Robot Description Format).

  • Link (Component): Mass, Origin (center of gravity position), Inertia (moment of inertia)
  • Joint: Maximum motor torque, rotation axis, range of motion
  • Collision: Which parts count as a "hit" when they touch the ground

In the ET Robocon model used this time, by setting the car's center of gravity slightly high, we intentionally summon an "easy to fall, challenging to control" inverted pendulum into the digital world.


4. The Biggest Barrier: Reality Gap (Divergence from Reality)

In Sim-To-Real, there is an inevitable and fatal problem. That is the Reality Gap.

"An AI that ran perfectly in simulation fell over without moving a single step when moved to a real machine."
This is a daily occurrence in the Sim-To-Real community.

Why does the Gap occur?

  1. Friction Uncertainty: The floor in a simulation is uniform, but real courses have dust, and grip changes depending on the location.
  2. Latency: There is a slight "lag" in reality between when a program issues a command and when the motor moves.
  3. Individual Differences: Even for the same product, there are errors of a few percent in motor output.

How do we overcome this wall? One of the answers is the selection of robust individuals through "Genetic Algorithms", which will be explained in Part 2.


Coming Up Next: Evolving the AI's "Brain"

Once the simulator as a "vessel" is ready, the next step is to breathe a "soul (control logic)" into it.
We will explain the thrilling evolutionary process of letting the AI think for itself on "how to avoid falling," rather than being strictly bound by formulas, along with the implementation code.

Would you like me to...
Would it be okay to output Part 2: "Implementation and Evolution Edition"? There, I will delve deeper into the logic of the code provided (NN and GA).

GitHubで編集を提案

Discussion