Coordinated Autonomy:
Goal-Oriented Navigation with TurtleBot and ESP32

Scope

The system implements a goal-oriented autonomous navigation framework where an ESP32 equipped with an IMU publishes a target location to a ROS 2 topic. The TurtleBot4, after autonomously mapping its environment, listens to this goal and performs real-time path planning and navigation while avoiding obstacles. The architecture emphasizes modularity, real-time processing, and seamless hardware-to-ROS integration.

Data Collection

• Current Position: Estimated through /rpi_07/amcl_pose, based on adaptive Monte Carlo localization
• Goal Position: Received via /esp32_07/goal as a geometry_msgs/Point
• Path and Map: SLAM-based mapping through auto_map.launch.py, with the map saved via auto_save.py
• Wheel Velocity: Entirely computed on a dedicated VM—the RPi simply forwards topic data over Ethernet—minimizing onboard load and reducing latency

Initial Data Collection

At the start, the intent was to directly use raw IMU readings for velocity control—manipulating wheel speeds via /cmd_vel based on tilt. This approach proved inconsistent and lacked precision. Recognizing this, the data strategy was shifted to interpreting the IMU's global position estimate as a goal, which the robot could reach using the more robust Nav2 planner.

• Learning: IMU as a goal provider rather than motion controller was a turning point in shaping a stable, achievable project scope.
• Cmd_Vel Integration: The obstacle_avoid.py node continuously processes LiDAR data from /rpi_07/scan to detect obstacles and dynamically publishes velocity commands to /rpi_07/cmd_vel. By adjusting both linear and angular speeds in real time, it ensures smooth forward motion while safely steering around any detected obstructions.
• Python Code Flow: esp32_goal.py receives the ESP32 goal and sends it to the NavigateToPose action server, ensuring smooth execution within Nav2.

Filtering

Although no ML training was conducted, filtering was essential. The ESP32 data likely underwent low-pass filtering (or smoothing) on-device to avoid goal jitter. On the TurtleBot side, stability was maintained by ignoring rapid goal updates and sending the navigation goal only once per session.

This passive filtering ensured reliability and reduced misbehavior in dynamic environments.

How ROS Was Used

ROS 2 formed the communication and control backbone of our system: sensor data (IMU goals, LiDAR scans, odometry) was published and subscribed on topics like /esp32_07/goal, /rpi_07/scan, and /rpi_07/amcl_pose, while motion commands flowed on /rpi_07/cmd_vel. We leveraged the NavigateToPose action server for asynchronous goal execution and feedback, and organized our nodes into modular launch files (mapping, localization, navigation, obstacle avoidance, map saving). This architecture provided real-time responsiveness, clear separation of concerns, and easy extensibility across all autonomy components.

• Pub/Sub:
  • ESP32 → /esp32_07/goal
  • Odometry → /rpi_07/odom, Localization → /rpi_07/amcl_pose
  • Velocity control → /rpi_07/cmd_vel
• Action Server:
  • Goal execution through /rpi_07/navigate_to_pose using esp32_goal.py
• Launch Architecture:
  • Mapping via auto_map.launch.py (calls SLAM + RViz + obstacle_avoid + auto_save)
  • Navigation via navigation_with_local.launch.py (loads map, localization, Nav2 stack, and goal subscriber)

Validation

• Console Echo: Verifying /esp32_07/goal reception and value range to ensure the ESP32 IMU topic is published and configured correctly.
• Visual Feedback:
  • Goal markers visualized using RViz and /goal_marker
  • Map and pose tracking via /rpi_07/map, /rpi_07/odom, and AMCL particles
• Real-world Evidence:
  • Recorded videos demonstrate successful navigation from initial pose to dynamic goal using Nav2’s global and local planners with AMCL-based localization while seamlessly integrating real-time obstacle avoidance; trajectory visualizations confirm convergence to goal.
  • Trajectory visualization confirms convergence to goal
• Graphing (Optional):
  • Position and path data can be logged via /rpi_07/amcl_pose alongside Nav2 planner metrics to evaluate localization accuracy, path planning efficiency, and trajectory smoothness.

Portfolio of Topics Learned

• ROS 2 concepts including nodes, publishers/subscribers, actions, and launch files
• SLAM (Simultaneous Localization and Mapping) using Nav2 and TurtleBot 4
• Autonomous navigation and localization using YAML map files
• LiDAR-based obstacle avoidance
• Action server communication for goal-based navigation (NavigateToPose)
• Real-time goal communication via ESP32 and IMU integration
• Map saving and loading using map_saver_cli
• Offloading heavy computation to a ROS 2–enabled VM for performance optimization

Assist Future Students to Define Their Project Scope

This project serves as an excellent reference for students interested in:

• Multi-agent communication (e.g., ESP32 and TurtleBot coordination)
• Modular ROS 2 launch and execution design
• Real-world autonomous navigation tasks
• Incorporating embedded sensors like IMUs for higher-level decision making
• Designing hybrid control systems (manual + autonomous)

Shaping the Class: Integrating Potential Creative Solutions

A unique aspect of this project is the seamless interaction between an ESP32 and a robot platform through ROS 2 middleware. Instead of hard-coding goals or relying on GUI inputs, the robot reacts to real-world sensor inputs from a lightweight embedded device. This concept opens up creative applications such as:

• Swarm coordination
• Mobile robot dispatch
• Remote exploration or search-and-rescue simulations

This project showcased a successful transition from raw sensor-based motion attempts to a robust goal-oriented autonomous system powered by ROS 2. Challenges in initial control logic gave way to a more reliable architecture that used filtered IMU data to guide navigation. The integration of mapping, obstacle detection, action-based goal navigation, and real-time ROS messaging serves as a blueprint for future mobile robotic systems with embedded remote input sources.

Topics Learned

• ROS 2 architecture and launch system
• Obstacle avoidance using LiDAR
• Map saving and localization techniques
• Using ActionClient and goal markers in real time
• Bridging sensor data from ESP32 to a ROS 2 navigation stack

Problems Faced

• Slight inaccuracy in the final goal position
• Manual setup required for robot pose initialization
• CPU load bottlenecks on the TurtleBot 4’s onboard RPi
• Initial latency in ESP32 goal communication

Solutions Found

• All computation runs on a dedicated VM— the RPi only forwards topics to the VM over Ethernet, which also lowers system latency.
• Added startup delay and turning logic to obstacle_avoid.py for smoother performance
• Introduced a keypress-triggered map save node for intuitive map storage
• Ensured consistent namespace usage and topic remapping to streamline communication between nodes

Setup: TurtleBot in indoor arena; ESP32 sends target & heading to Pi.

Execution: Pi maps environment, plans path, TurtleBot navigates while GUI displays live data.

Metrics:

• Goal-reaching accuracy
• Map quality
• Obstacle avoidance
• GUI latency

1. Unit Testing

• ESP32 IMU transmission
• ROS 2 topic publishing
• Nav2 local planner

2. Integration Testing

• Live sensor path planning
• Reaction to goal updates

3. Error Handling

• ESP32 dropout recovery
• Navigation collision recovery

4. Performance Metrics

• Distance error
• Completion time
• Obstacle handling success