Simulation to Reality
Week 12 • CMPSC 304 Robotic Agents
Press Space or → to advance
The Full Path
SLAM
Build maps
→
Nav2
Click goals
→
Nodes
Code goals
→
Today
Real robots
Everything you've built works in simulation. Today we address the question: what changes when you move to a physical TurtleBot3?
The Sim-to-Real Gap
Definition: The difference in behavior between a robot operating in simulation vs. the real world. Also known as the reality gap.
Simulation
- Perfect physics (no friction variance)
- Perfect sensors (no noise)
- Instant communication
- Unlimited battery
- No physical damage possible
Reality
- Uneven surfaces, wheel slip
- Sensor noise, reflections, dead zones
- Network latency (Wi-Fi)
- Battery drains, voltage drops
- Collisions cause real damage
TurtleBot3 Burger: The Hardware
| Component | Specification | Relevance |
|---|
| Compute | Raspberry Pi 4 | Runs ROS2, limited CPU compared to your laptop |
| Microcontroller | OpenCR (ARM Cortex-M7) | Motor control, IMU, power — like your Arduino |
| Lidar | LDS-02 (360°, 5Hz) | Same sensor model as in Gazebo |
| Motors | 2× Dynamixel XL430 | Differential drive, encoder feedback |
| IMU | MPU9250 (9-axis) | Helps with odometry on real surfaces |
| Battery | LiPo 11.1V, 1800mAh | ~2.5 hours runtime |
| Max speed | 0.22 m/s | Same limit in Gazebo and reality |
Lidar: Simulation vs. Reality
Gazebo Lidar
- Clean, consistent readings
- No reflective surface issues
- No interference from other robots
- Perfect geometry — walls are flat planes
- Updates at exactly the configured rate
Real LDS-02
- Noise in every scan (± a few cm)
- Glass, mirrors, dark objects may not reflect
- Crosstalk if multiple robots nearby
- Irregular surfaces (chair legs, cables)
- Speed varies with motor RPM
Impact on mapping: Real maps will have more noise. Walls may appear thicker or slightly uneven. This is normal — your navigation should still work.
Odometry: Drift and Slip
Odometry estimates position from wheel rotations. In simulation it's nearly perfect. In reality, it drifts.
- Wheel slip: Smooth floors or fast turns cause wheels to lose traction
- Carpet vs. tile: Different surfaces change wheel dynamics
- Accumulated error: Small errors compound — after driving 10m, position may be off by 20+ cm
- Why AMCL matters: The particle filter localizer corrects odometry drift by matching lidar scans to the map
Key insight: This is exactly why we use SLAM and AMCL. Pure odometry navigation would fail on a real robot within minutes. The map-based approach you learned is the solution.
Networking with Physical Robots
In Docker, everything runs in one container. With a real TurtleBot3, your laptop and the robot communicate over Wi-Fi.
# On the TurtleBot3 (Raspberry Pi):
export ROS_DOMAIN_ID=30
# On your laptop (same network):
export ROS_DOMAIN_ID=30
ROS_DOMAIN_ID — isolates ROS2 traffic. Each team gets a unique ID.- Both devices must be on the same Wi-Fi network
RMW_IMPLEMENTATION — use rmw_cyclonedds_cpp for best Wi-Fi performance
Latency matters: Wi-Fi adds 5-50ms delay. RViz on your laptop may lag slightly behind the real robot.
Mapping: Sim vs. Real
| Aspect | Simulation | Physical |
|---|
| Environment | Gazebo world (fixed walls) | Lab/classroom (furniture, people) |
| Speed | Drive fast, no consequences | Drive slow (0.1-0.15 m/s recommended) |
| Map quality | Clean, sharp edges | Noisy, thicker walls, occasional gaps |
| Loop closure | Works reliably | May need slower driving to succeed |
| Dynamic obstacles | None (unless added) | People walking, doors opening |
| Time to map | 2-3 minutes | 5-10 minutes for a room |
Tip: Map when the space is empty, at a slow consistent speed, and make sure to revisit your starting area for good loop closure.
Navigation: What Changes?
- Initial pose matters more: Set it precisely — AMCL needs a good starting estimate on a real robot
- Costmap inflation: You may need to increase the inflation radius to keep the robot farther from real walls (it can't clip through them!)
- Recovery behaviors activate more often: The robot may need to spin or back up when it encounters unexpected obstacles
- Goal tolerance: On a real robot, reaching within 10-15 cm of the goal is typically acceptable
Your navigation node code does NOT change. The same NavigateToPose action works identically — you just need new coordinates for the real environment.
Safety with Physical Robots
Rules
- Always have a team member ready to pick up the robot
- Never run untested code at full speed
- Test in sim first every time you change waypoints
- Keep the area clear of trip hazards
- Low battery = unpredictable behavior
Emergency Stop
- Pick up the robot (wheels will free-spin)
- Or publish a zero velocity:
ros2 topic pub --once /cmd_vel geometry_msgs/msg/Twist "{}"
- Press the power button on the OpenCR board
Recommended Workflow for P4 Part 4
1. Map the
real space
→
2. Save map
to robot
→
3. Launch Nav2
with real map
→
4. Test goals
in RViz
→
5. Update node
coordinates
→
6. Run node
on real robot
Key principle: Get everything working in simulation first. Transfer to the real robot means only swapping the map file and updating waypoint coordinates.
Textbook Connection
Introduction to Autonomous Mobile Robots (Siegwart, Nourbakhsh, Scaramuzza)
Chapter 5: Perception — sensor models and noise characteristics relevant to understanding the sim-to-real gap in lidar and odometry.
Chapter 3: Mobile Robot Kinematics — differential drive model that explains why wheel slip affects odometry on real surfaces.
Summary
| Topic | Key Takeaway |
|---|
| Sim-to-real gap | Real sensors are noisy, surfaces cause drift, network adds latency |
| Lidar differences | Reflective surfaces, noise, and irregular objects affect scan quality |
| Odometry drift | AMCL corrects accumulated errors using the map |
| Networking | Same ROS_DOMAIN_ID, same Wi-Fi, CycloneDDS |
| Your code | Stays the same — only map and coordinates change |
| Safety | Test in sim first, drive slow, always be ready to stop |