Gazebo + ROS 2 Mobile Robot
DEGREE OBJECTIVE 6
Implement artificial intelligence and data systems into robotic platforms.
How it meets the objective: It implements ROS 2's publish-subscribe data system—the data backbone of modern robots—on a robotic platform and then instruments it with LiDAR and contact sensors that feed data into it.
Driving the custom SDF robot in Gazebo with ROS 2: velocity commands are published to /cmd_vel, and live keyboard teleop is enabled via the Key Publisher.
A custom SDF vehicle built, driven, and extended across two assignments in RBT347: differential-drive motion through ROS 2 topics and keyboard teleop, then a sensor-equipped world upgrade — 2D LiDAR, contact bumpers, and a structured driving environment. Built with Gazebo, ROS 2, and hand-written SDF on Ubuntu 24.04.
Part 1 — motion control
Starting from my custom building_robot SDF model, I added a differential-drive plugin — defining wheel joints, separation, and radius so the plugin's kinematics match the model geometry. The robot subscribes to velocity topics; commands published to /cmd_vel drive it through the simulated world, and a Key Publisher teleop setup provides live keyboard control. Getting there required diagnosing a physics-model defect: the wheels initially rotated in place without producing forward motion. The DiffDrive plugin and /cmd_vel topic were verified as working, isolating the fault to the model itself — correcting the wheel joint alignment and contact properties produced stable rolling. The before-and-after SDF files are both on GitHub, so the exact fix is diffable.
Part 2 — sensors and environment
The world and robot were then extended toward a realistic test scenario: an asphalt-style ground plane with lane markings, static box obstacles, a forward-facing 2D LiDAR on a dedicated mounting link, and front and rear collision bumpers implemented as contact sensors — all defined in SDF. The sensors are modeled with correct mounts, joints, and sensor blocks, but their feedback topics weren't publishing readable data by the deadline. Post-deadline analysis found the root cause: the first revision lacked the sensor system plugin entirely, the second added it and completed the LiDAR plumbing, and the remaining gap is the contact system plugin the bumpers require — a documented two-line fix.
The building_robot at its start pose: differential-drive chassis with two driven wheels, before a teleop run.
The sensor-equipped world: asphalt ground with lane markings, box obstacles, and the robot carrying a 2D LiDAR mount and front/rear contact bumpers.
The sensor-equipped robot in the structured world — restyled body, LiDAR mount above the chassis, and box obstacles along the lane.