Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 2
intermediate tutorial
Welcome to the Intermediate tutorial! 🎓
If you are here, you likely have your Raspberry Pi set up with Ubuntu and Pixi, and you are ready to understand how RustyRover is actually put together. You aren't just flashing SD cards anymore—you are ready to look under the hood. 🔧
Unlike a standard ROS 2 project where everything might live in one folder, RustyRover is split into three specific workspaces to handle the Rust dependencies and the remote control cleanly.
Here is the high-level map of the repository:
"The Client Library Workspace"
- Purpose: Since
rclrs(the Rust client for ROS 2) is not yet included in standard ROS 2 distributions (like Humble or Jazzy) viaapt install, we must build it from source. - What's inside: The source code for the
rclrslibrary itself. - Why it matters: This workspace provides the core Rust libraries that the robot code needs. You typically build this once and then source it so other workspaces can find
rclrs.
"The Main Robot Workspace"
- Purpose: This is where the actual code for the RustyRover lives.
- Location: Runs on the Raspberry Pi.
- What's inside:
- Drivers for the motors.
- The spinner action server.
- Camera service nodes.
- Launch files.
- Dependency: This workspace depends on
rclrs_install_ws. You cannot build this if the foundation isn't sourced!
"The Control Center"
- Purpose: A standalone Rust application that runs on your Laptop, not the robot.
- Technology: Uses Ratatui for the TUI (Terminal User Interface) and BlueR for Bluetooth communication.
- Dependency: This is largely independent of ROS 2, as it communicates via Bluetooth to the Pi (which then translates commands to ROS 2).
You might have noticed the pixi.toml files. We use Pixi to manage our development environment.
In a traditional ROS setup, you rely on global installations (/opt/ros/...). In RustyRover, Pixi creates a contained environment with all the necessary dependencies (compilers, tools, libraries) installed locally.
The Workflow: Whenever you work on this project, you must ensure you are inside the Pixi environment:
cd RustyRover
pixi shellThis ensures that cargo, colcon, and ros2 commands are available and are the correct versions.
So, you want to add a new feature? Maybe a LIDAR node or a new sensor driver? Here is how to add a new package to the RustyRover ecosystem.
Move to the source folder of the robot's workspace:
cd rusty_rover_ws/srcSince we are doing Rust, we use cargo to initialize the package, but we structure it so colcon can find it.
# Replace 'my_new_feature' with your package name
cargo new my_new_featureThis is the tricky part! To make your new Rust crate a "ROS 2 Node," you need to tell it where to find rclrs.
Open rusty_rover_ws/src/my_new_feature/Cargo.toml and add:
[dependencies]
rclrs = "*"serde = { version = "1.0", features = ["derive"] } # Often needed for messagesNote
We use rclrs = "*" because we rely on the rclrs_install_ws being sourced in the background. The build system will find the library in the underlay workspace.
To test your new package, you need to go back to the workspace root and build using colcon.
- Source the Foundation: You must source the
rclrssetup file first. - Build your Workspace:
# Inside rusty_rover_ws/
colcon build --packages-select my_new_feature- Source your Workspace:
source install/setup.bashWhen extending RustyRover, your loop will look like this:
- Code inside
rusty_rover_ws/src/my_node. - Build using
colcon buildin therusty_rover_wsroot. - Source the
install/setup.bash. - Run using
ros2 run my_new_feature my_executable.
Now that you understand where the folders are and how to add a new package, you probably want to know what code to actually write inside that main.rs file.
👉 Ready to write code? Go to the Pro Tutorial 👑 to learn how to write Publishers, Subscribers, and Services in Rust!
