Understand the system
Inspect nodes, topics, actions, transforms, robot descriptions, hardware interfaces, and lifecycle behavior on a complete mobile robot.
University teaching platform + applied curriculum
Autonomous Mobile Robotics Lab
Give students a functioning ROS 2 robot, then teach them to inspect, measure, modify, and improve every layer of its autonomy stack.
Physical robot experiments
ROS 2 + Nav2 baseline
Open, replaceable subsystems
FORMATOn-campus, hands-on
COURSE MODEL12-week adaptable sequence
LAB RATIO1 robot / 3–5 students
PLATFORMUbuntu · ROS 2 · Nav2
Program overview
Teach autonomy on a robot students can actually change.
Boltu Robotics combines a working autonomous mobile robot with a structured teaching package. Students begin by operating a known baseline, then trace data and decisions through sensing, state estimation, mapping, localization, planning, control, and safety.
The platform arrives with teleoperation, ROS 2 integration, mapping, localization, and Nav2 configured. That removes weeks of unreliable assembly while preserving the freedom to replace sensors, compute, motor control, algorithms, and payloads.
Measure the real world
Calibrate odometry, characterize sensor noise, compare state estimates, quantify map quality, and evaluate navigation performance.
Build dependable autonomy
Configure localization and Nav2, design delivery missions, introduce failures deliberately, and implement safe recovery behavior.
Modify with evidence
Replace a subsystem, recalibrate the platform, and defend the engineering tradeoffs using repeatable physical experiments.
Suggested 12-week sequence
From first motion to an autonomous delivery mission.
Adopt the full sequence or integrate individual modules into an existing robotics course.
Weeks 1–3Robot foundations+
Start with laboratory safety and teleoperation, inspect the ROS 2 graph, validate URDF and transforms, and connect the differential-drive hardware through ros2_control.
- Safe startup, command timeouts, and emergency stopping
- Nodes, topics, services, actions, URDF, Xacro, and tf2
- CAN motor control, feedback, and drive limits
Weeks 4–5Odometry and state estimation+
Turn real measurements into a defensible motion estimate using calibrated wheel parameters, an IMU, covariance modeling, and sensor fusion.
- Straight-line and rotation calibration
- Error characterization and repeatable trials
- Fused odometry with robot_localization
Weeks 6–8Mapping, localization, and Nav2+
Create maps, test localization recovery, and tune global planning, local control, costmaps, and obstacle response in a physical environment.
- SLAM Toolbox and map-quality evaluation
- AMCL confidence and displacement experiments
- Planning and controller acceptance tests
Weeks 9–10Recovery and delivery behavior+
Move beyond successful demos by testing blocked routes, retry limits, waypoint execution, pickup confirmation, arrival signaling, and return-to-home behavior.
- Nav2 behavior trees and recovery actions
- Mission states and operator handoffs
- Diagnostics, logs, and rosbag evidence
Weeks 11–12Open-ended experiments+
Teams replace or extend one subsystem, restore calibrated operation, and present a reproducible autonomous mission with quantitative results.
- Depth perception or alternative sensors
- Modified planning, control, or payload behavior
- Technical demonstration and failure analysis
What your department receives
A laboratory system—not just a mobile base.
Working reference robot
A two-powered-wheel differential-drive platform with passive rear caster support, documented connections, physical emergency stop, and an accessible modular deck.
Supported ROS 2 baseline
Robot description, drive integration, state estimation, SLAM, localization, Nav2, RViz views, diagnostics, and repeatable setup procedures.
Six core lab packages
Instructor setup, student instructions, starter files, reference results, common failures, reset procedures, and grading rubrics.
Instructor onboarding
Bring-up guidance, safety workflow, teaching preparation, and support for adapting the sequence to your course and facilities.
Designed for
Programs that want theory and hardware to meet.
Upper-level undergraduate courses
Connect software, electrical, mechanical, control, and systems concepts through one shared platform.
Graduate robotics programs
Begin research from a documented reference system instead of repeatedly rebuilding infrastructure.
Capstone teams
Focus student effort on a meaningful new capability while retaining a reliable autonomy baseline.
Continuing education
Give working engineers direct experience diagnosing an integrated autonomous system.
Final demonstration
Prove more than “the robot moved.”
Student teams complete a reproducible autonomous mission, quantify performance, document a failure, and explain the choices that produced their result.
- Navigate through multiple physical goals
- Respond safely to a blocked route
- Complete pickup, delivery, and return states
- Present logs, measurements, and limitations
Questions from faculty
Program FAQs
Is this an online course?+
No. The proposed program is centered on supervised physical laboratory work at your institution. Simulation can prepare students for each exercise, but it does not replace robot time.
Can we use our existing course material?+
Yes. The robot and labs are modular. Departments can use the complete suggested sequence or adopt only the hardware, software baseline, and selected exercises.
What background should students have?+
Python or C++, basic Linux use, and introductory linear algebra are recommended. Prior exposure to probability or control is useful but can be reviewed within the course.
Is the robot ready for unsupervised outdoor delivery?+
No. The first platform is intended for indoor and supervised dry-weather experiments. Outdoor autonomy, rain resistance, powered lockers, and fleet operations are later product stages.
How many robots does a class need?+
A practical planning ratio is one robot for every three to five students, plus suitable test space, charging procedures, workstations, tools, and replacement parts.
Can students change the hardware and software?+
That is a central design goal. Sensors, compute, control components, autonomy packages, and payloads have documented interfaces and are meant to support replacement experiments.
Pilot university labs