DEV Community: Nathaniel Handan

Building an Autonomous Robotic Vacuum from Scratch: A ROS 2 Sim-to-Real Engineering Log

Nathaniel Handan — Fri, 07 Aug 2026 15:42:51 +0000

I did not set out to build a better robot vacuum. There are already good ones on the market, and competing with iRobot or Roborock on a hobbyist budget is a losing game. What I actually wanted was a realistic, physically grounded platform to force myself through the full mobile robotics stack: URDF modeling, sensor fusion, SLAM, Nav2, ros2_control, and eventually sim-to-real transfer of learned navigation policies. A vacuum form factor turned out to be a convenient excuse to build that platform.

This post documents where the project currently stands: the mechanical starting point, the ROS 2 architecture, the simulation setup in Gazebo Harmonic, the decisions I made and why, and the failures that shaped those decisions. This is not a tutorial. It is a log of an ongoing system, written the way I'd want to read about someone else's project before starting my own.

Why a Vacuum Form Factor

Designing a mobile robot chassis from a blank sheet is a rabbit hole. Wheel placement, center of mass, caster geometry, motor mounting, all of it consumes weeks before you've written a single line of navigation code. I wanted to spend my time on the software stack, not on reinventing a differential drive chassis that thousands of engineers have already solved well.

So I pulled a CAD model of a robot vacuum (visually similar to the Xiaomi Mi Robot Vacuum, though this is not a Xiaomi product or a clone of their firmware) from GrabCAD and imported it into Onshape. From there I started modifying the internal volume to fit a Raspberry Pi 5, a battery pack sized for my actual power budget, and mounting points for an RPLIDAR and an IMU that the stock design never accounted for.

The reasoning here is purely pragmatic:

The circular chassis with a differential drive base and a single rear caster is a well understood, well documented robot geometry. Every Nav2 tutorial, every robot_localization example, every ros2_control diff drive plugin assumes something close to this.
A commercial design has already solved weight distribution and turning radius problems for indoor navigation. I don't need to relearn those from scratch.
It gives me a hard physical constraint. I can't just theorize about SLAM performance, the chassis has a real height, a real sensor mounting position, and a real minimum turning radius that the planner has to respect.

The trade-off is that I inherited some annoying constraints too. Internal volume is tight, which is already forcing compromises on where the RealSense camera goes relative to the LiDAR, and cable routing inside a vacuum shell is a genuinely fiddly problem that CAD renders don't warn you about.

Current Hardware

The hardware set is intentionally modest. Nothing here is exotic, and that is deliberate: I want the eventual sim-to-real gap to come from software and modeling decisions, not from working around unusual or unreliable components.

Subsystem	Component
Chassis	Circular vacuum-form platform (Onshape, modified from GrabCAD reference)
Drive	Differential drive, two powered wheels, rear caster
Compute	Raspberry Pi 5
Ranging	RPLIDAR (2D planar LiDAR)
Inertial	IMU
Odometry	Wheel encoders on both drive motors
Depth (optional)	Intel RealSense
Actuation	Vacuum motor, brush motor, drive motors
Power	Custom BMS and charging circuit

The RealSense is marked optional because right now the navigation stack is LiDAR-centric. The camera exists for future work: visual odometry as a cross-check against wheel encoders, and eventually as an input to a learned local planner. It is not load-bearing for the current SLAM or Nav2 pipeline.

Software Stack

Ubuntu 24.04
ROS 2 Jazzy
Gazebo Harmonic
Navigation2
SLAM Toolbox
robot_localization
ros2_control
URDF / Xacro
RViz2
Lifecycle nodes
TF2
Behavior Trees (via Nav2's BT navigator)
OpenCV
Python and C++, split by where each language actually earns its place

The language split is worth a sentence. Anything performance sensitive, control loops, message filtering, custom ros2_control hardware interfaces, goes in C++. Anything orchestration or logic heavy, behavior tree conditions, state machines, tooling scripts, goes in Python. I've seen projects standardize on one language across the whole stack and pay for it later, either in runtime overhead in the Python parts or in development speed in the C++ parts.

Architecture: One Set of Nodes, Two Environments

The single design decision that shapes everything else in this project is: the same ROS 2 nodes and topics run in simulation and on the physical robot. Not "similar" nodes. The same navigation, localization, and control stack, unmodified, pointed at a different set of drivers underneath.

                        Gazebo Harmonic
                               │
                Same ROS 2 Nodes & Topics
           (Nav2, SLAM Toolbox, robot_localization,
                  TF2, Behavior Trees)
                               │
        ┌──────────────────────┴──────────────────────┐
        │                                             │
    SIMULATION                                  PHYSICAL ROBOT
    ─────────────                                ─────────────
    LiDAR plugin            ───────────────►     RPLIDAR driver
    Camera plugin            ───────────────►     RealSense driver
    Diff drive plugin        ───────────────►     Motor driver (ros2_control)
    IMU plugin                ───────────────►     Physical IMU driver
    Wheel encoder plugin      ───────────────►     Hardware encoder interface

Everything above the dashed line, the planner, the costmaps, the EKF, the behavior tree, never knows whether it's talking to a Gazebo plugin or a physical driver. It just sees /scan, /imu, /odom, /cmd_vel, and /tf. The abstraction boundary is the hardware interface layer, implemented through ros2_control's SystemInterface on the real robot and through Gazebo's ros2_control plugin in simulation.

This is not a novel idea, it is how Clearpath and most serious ROS 2 platforms structure their stacks, but actually building it disciplined enough to hold up is harder than it sounds. The temptation to sneak a simulation-only shortcut into a launch file, or to hardcode a topic remap that only makes sense on hardware, is constant. Every time I catch myself doing that, it's a sign the abstraction has a hole in it.

URDF and Xacro Structure

The robot description is split into modular Xacro files rather than one monolithic URDF, which matters once you're maintaining both a simulated and a physical variant:

vacuum_bot_description/
├── urdf/
│   ├── vacuum_bot.urdf.xacro        # top level, includes everything below
│   ├── base.xacro                   # chassis, casters, inertial properties
│   ├── wheels.xacro                 # drive wheel joints and links
│   ├── lidar.xacro                  # RPLIDAR mount and frame
│   ├── imu.xacro                    # IMU mount and frame
│   └── ros2_control.xacro           # hardware interface tags, sim vs real toggle
├── meshes/
└── config/
    ├── controller_manager.yaml
    └── nav2_params.yaml

The ros2_control.xacro file is the one place where simulation and hardware genuinely diverge, gated by a Xacro argument:

<xacro:if value="$(arg use_sim)">
  <ros2_control name="GazeboSystem" type="system">
    <hardware>
      <plugin>gz_ros2_control/GazeboSimSystem</plugin>
    </hardware>
    <!-- joint definitions shared with the real robot below -->
  </ros2_control>
</xacro:if>

<xacro:unless value="$(arg use_sim)">
  <ros2_control name="RealRobot" type="system">
    <hardware>
      <plugin>vacuum_bot_hardware/VacuumBotSystemHardware</plugin>
      <param name="serial_port">/dev/ttyUSB0</param>
    </hardware>
    <!-- same joint definitions -->
  </ros2_control>
</xacro:unless>

Everything else in the URDF, link geometry, joint limits, sensor frames, inertial tensors, stays identical between the two. That's the whole point: the divergence is quarantined to a single file and a single tag, not scattered across launch files and node parameters.

SLAM and Localization

SLAM Toolbox runs in online async mode for mapping, and the localization stack is a two-layer setup that I think is underused in hobbyist projects: wheel encoder odometry fused with the IMU through robot_localization's EKF node, producing odom -> base_link, with SLAM Toolbox (or AMCL against a saved map, depending on mode) supplying the map -> odom correction.

map
 └── odom            (published by SLAM Toolbox / AMCL)
      └── base_link   (published by robot_localization EKF, fusing wheel odom + IMU)
           ├── lidar_link
           ├── imu_link
           └── camera_link (when RealSense is mounted)

This two-frame separation matters more than it looks like on paper. Early on I had SLAM Toolbox publishing directly into base_link without an EKF in between, and the localization estimate was visibly jittery on carpet, since raw wheel odometry alone is noisy and the LiDAR match correction was fighting that noise at high frequency. Fusing wheel odometry with the IMU first gives SLAM Toolbox a much smoother prior to correct against, which is a cheap fix that made a disproportionate difference in map quality.

Simulation Environment

Gazebo Harmonic hosts the differential drive plugin, LiDAR sensor plugin, IMU plugin, and (optionally) the RGBD camera plugin, all wired through gz_ros2_control so that the same diff_drive_controller and joint_state_broadcaster used on hardware also drive the simulated joints. Test worlds are simple apartment-style layouts built from primitive geometry: rooms, doorways, furniture obstacles, and a charging dock marker. Nothing photorealistic, since the goal right now is validating the navigation and control stack, not perception under realistic lighting.

Simulation-first was not really a choice so much as the only sane option given the hardware situation. Bench testing a differential drive controller tuning by running it on carpet, watching the robot drift into a wall, powering down, adjusting a PID gain, and repeating, burns hours. In Gazebo, the same iteration loop is seconds, and I can reset the world state exactly, which matters when you're trying to isolate whether a bad turn came from controller tuning or from a bug in your costmap inflation layer.

Navigation Stack

Nav2 runs with the standard lifecycle-managed node set: the controller server (DWB), the planner server (NavFn), behavior server, BT navigator, and costmap layers (static, obstacle, inflation) on both the local and global costmaps. Behavior tree XML is close to the Nav2 default navigate_w_replanning_and_recovery tree for now, with the recovery behaviors tuned down since a circular, low-clearance vacuum chassis has different recovery needs than a taller differential drive robot: spin recovery is cheap, but backing up in a cluttered room is riskier given the low sensor mounting height and limited field of view behind the robot.

# excerpt, nav2_params.yaml
controller_server:
  ros__parameters:
    controller_frequency: 20.0
    FollowPath:
      plugin: "dwb_core::DWBLocalPlanner"
      max_vel_x: 0.26
      max_vel_theta: 1.0
      acc_lim_x: 2.5
      acc_lim_theta: 3.2
      xy_goal_tolerance: 0.15
      trajectory_generator_name: "dwb_plugins::StandardTrajectoryGenerator"

max_vel_x is intentionally conservative at this stage. It is easy to tune a planner for aggressive speed in simulation where friction and wheel slip are idealized, and then watch that same configuration fail on carpet where actual traction is lower. I would rather start slow, get a sim-to-real gap measurement, and open the throttle once I know what the gap actually looks like.

Why ROS 2 Package Architecture Actually Matters

Early on I underweighted package organization, treating it as bookkeeping rather than engineering. That was a mistake worth describing, because the cost of a flat, poorly separated package structure doesn't show up immediately, it shows up three months in when you're trying to swap a component and discover everything is entangled.

The workspace is currently split into distinct packages along clear responsibility boundaries:

vacuum_bot_ws/src/
├── vacuum_bot_description/     # URDF, Xacro, meshes, robot_state_publisher config
├── vacuum_bot_bringup/         # launch files, top-level orchestration
├── vacuum_bot_hardware/        # ros2_control hardware interface (real robot only)
├── vacuum_bot_gazebo/          # world files, sim-specific launch, sensor noise configs
├── vacuum_bot_navigation/      # nav2_params.yaml, BT XML, costmap configs
├── vacuum_bot_localization/    # EKF config, SLAM Toolbox params
└── vacuum_bot_msgs/            # custom messages (battery state, dock status)

The rule I've tried to hold myself to is that vacuum_bot_description and vacuum_bot_navigation should never need to know whether they're running against Gazebo or hardware. Only vacuum_bot_bringup (which selects launch arguments) and vacuum_bot_hardware versus vacuum_bot_gazebo (which are mutually exclusive by design) are allowed to know that. When I catch a navigation-related parameter file with a sim-only assumption baked in, that's a sign the boundary leaked, and I go fix it rather than letting it slide.

This also made testing dramatically easier. Because vacuum_bot_navigation has no simulation dependency, I can write and run behavior tree condition unit tests, costmap layer configuration validation, and launch file argument checks in CI without spinning up Gazebo at all. Gazebo-dependent integration tests are a separate, slower tier that runs less frequently.

Why Sensor Integration Was Harder Than Expected

I underestimated this part going in, and it's worth being specific about where the difficulty actually came from, because "sensor integration is hard" is a vague complaint.

Frame conventions. RPLIDAR's ROS 2 driver publishes in a frame convention that does not automatically agree with where I mounted the physical unit inside the chassis. Getting lidar_link's static transform right, including a 180 degree yaw correction, took longer than it should have because the symptom (a map that looked mirrored and rotated) didn't obviously point at the transform as the cause. It looked, at first glance, like a SLAM Toolbox configuration problem.

Timing and message synchronization. The IMU publishes at a different rate than the wheel encoders, and robot_localization's EKF is sensitive to how you configure the process noise covariance relative to those rates. My first EKF config trusted the IMU too much relative to wheel odometry, which showed up as orientation drift during pure rotation in place, a scenario where wheel odometry is actually quite reliable and the IMU's gyro bias was the weaker signal.

Simulated sensor noise not matching reality. Gazebo's default LiDAR and IMU noise models are close to ideal by default. If you tune a costmap inflation radius or an EKF covariance against noiseless simulated sensors, you are tuning against a fantasy. I've since added Gaussian noise to the simulated LiDAR and IMU that roughly matches the RPLIDAR and IMU datasheet specs, which is a small thing that meaningfully changes what "good tuning" looks like in sim.

None of these are exotic problems. They're exactly the kind of unglamorous debugging that a tutorial skips over and that eats real project time.

Debugging Workflow: TF, rqt, and Rosbag

A few tools ended up carrying most of the debugging load, and it's worth naming them since they're unglamorous compared to whatever the current SLAM or planning algorithm is, but they're where most of the actual time goes.

ros2 run tf2_tools view_frames was the single most useful command during the sensor frame debugging described above. Generating the TF tree as a PDF and actually looking at it, rather than guessing at transforms from launch file arguments, caught the mirrored LiDAR frame issue faster than staring at RViz would have.

rqt_graph earns its place whenever a topic isn't flowing where I expect. Nav2's node graph gets large enough that eyeballing launch files isn't reliable for confirming remaps actually took effect; rqt_graph shows the ground truth.

Rosbag recording of every hardware test run, once hardware testing starts, is a policy I'm committing to before the first bring-up rather than after. It's tempting to skip recording during "just a quick test," and that's exactly when the interesting failure happens and there's no data to look back at. Every sim run already gets this treatment; I want hardware runs held to the same standard from day one.

RViz2 with a saved perspective per debugging context (one for SLAM map-building, one for Nav2 costmap inspection, one for TF/sensor frame checks) sounds trivial but cut a meaningful amount of time spent reconfiguring displays mid-debug session.

Sim-to-Real: The Actual Goal

Everything above exists in service of a specific question: once the stack runs cleanly in Gazebo, what breaks, and by how much, when the same nodes point at real hardware?

The intended workflow, in order:

Build the robot model (CAD, then URDF/Xacro)
Validate the model in Gazebo (physics, joint limits, sensor placement)
Tune controllers in simulation (diff_drive_controller, DWB parameters)
Integrate sensors (RPLIDAR, IMU, encoders, on the real hardware interface)
Validate navigation in simulation (SLAM Toolbox, Nav2 end to end)
Deploy the unchanged ROS 2 stack to the physical robot
Measure the sim-to-real gap directly, rather than guessing at it
Feed that measurement back into simulation fidelity and controller tuning

Steps 1 through 5 are largely done. Step 6 (hardware deployment) and everything after it is the current frontier of the project. The specific gaps I expect to measure, and want to measure rather than assume, are wheel slip on hard floors versus carpet, localization drift over multi-minute runs, control loop timing differences between the RCLCPP executor on a Raspberry Pi 5 versus my development machine, and how much costmap inflation tuning needs to change once real LiDAR noise replaces the noise model I approximated in Gazebo.

Domain randomization is explicitly future work, not something implemented yet. The plan is to randomize friction coefficients, sensor noise parameters, and lighting (once the RealSense is doing anything perception-relevant) across training episodes once the learned navigation component exists, so that a policy trained in simulation isn't brittle to the specific physics parameters of one Gazebo world.

The AI Component: Augmenting, Not Replacing

This is explicitly not an AI-first project, and I want to be direct about scope so it doesn't sound like vague roadmap padding. The traditional stack, Nav2's DWB local planner, NavFn global planner, SLAM Toolbox, robot_localization, remains the backbone. It works, it's debuggable, and it doesn't require training data I don't have yet.

The research question I actually want to explore is narrower: can a learned local planner, trained via imitation learning against DWB's own trajectories or via reinforcement learning in Gazebo, match or improve on classical local planning in cluttered, dynamic indoor scenes, specifically doorway navigation and tight furniture gaps where DWB's trajectory scoring sometimes gets conservative. That's a local planner replacement experiment, not a full navigation stack replacement. Global planning, costmaps, and localization stay classical.

Nothing here is trained yet. This section is future work, clearly labeled as such, not a claim about current capability.

Trade-offs Worth Naming Explicitly

Reusing a commercial chassis versus designing from scratch. I saved months of mechanical design time, at the cost of inheriting a tight internal volume that constrains sensor placement and cable routing. For a software-focused project, that trade was correct. For a project where the mechanical design itself was the research question, it would not have been.

LiDAR-centric navigation versus camera-first. 2D LiDAR plus Nav2's costmap stack is a mature, well-understood combination with predictable failure modes. A camera-first approach (visual SLAM, depth-based obstacle avoidance) would open up richer perception but at meaningfully higher software risk for a first working system. I chose to get LiDAR-based navigation solid first and treat the RealSense as an additive sensor for future work, not a dependency for the current pipeline.

Raspberry Pi 5 versus a more capable embedded compute platform. The Pi 5 is enough to run the current ROS 2 graph, but I am watching CPU headroom closely, particularly once any learned inference component gets added. I'd rather hit that ceiling and make a deliberate compute upgrade decision later than over-provision compute for a stack that doesn't need it yet.

Simulation fidelity versus development speed. Idealized simulated sensors made early development faster but produced tuning that didn't transfer well. Adding realistic noise models slowed simulation development slightly but should narrow the sim-to-real gap. I'd make the same trade again, just earlier next time.

Where AWS Fits (and Where It Doesn't)

I want to be clear that the robot's autonomy does not depend on the cloud in any way. Navigation, SLAM, and control all run on-device. Where cloud tooling actually earns a place in this project is around the development and evaluation loop rather than the robot's runtime behavior:

Storing Gazebo simulation logs and rosbag recordings from both sim runs and hardware test runs, so sim-to-real comparisons are reproducible instead of anecdotal
A container registry for the ROS 2 workspace image, so the exact same environment that ran a given test is easy to rebuild later
A lightweight CI pipeline that builds the ROS 2 packages and runs unit tests on push, catching build breaks before they show up as "why doesn't this launch anymore" during bench time
Eventually, fleet-style telemetry if this project ever grows past a single unit, though that's speculative and not close to current scope

None of this changes how the robot operates. It's infrastructure around the project, not infrastructure the robot leans on to function.

Current Status and Immediate Next Steps

As of this writing: the URDF/Xacro model is built and validated in Gazebo Harmonic, ros2_control is wired for both the simulated and real hardware interface (with the real hardware interface implemented but not yet bench-tested end to end), SLAM Toolbox produces usable maps in simulated apartment-style worlds, and Nav2 completes point-to-point navigation goals in simulation with the DWB local planner and NavFn global planner.

The immediate next milestone is step 6 in the sim-to-real workflow: flashing the same ROS 2 stack onto the Raspberry Pi 5, bringing up the real RPLIDAR and IMU drivers, and running the first physical SLAM mapping pass. That's where the real measurements start, and where I expect this write-up to get a follow-up post with actual numbers instead of projected ones.

Future Work

Physical hardware bring-up and first real-world SLAM/Nav2 runs
Quantified sim-to-real gap measurements (localization drift, wheel slip, control timing)
Domain randomization in simulation once measured gaps identify what to randomize
Imitation learning baseline for a learned local planner, benchmarked against DWB
RealSense integration as a secondary localization and obstacle avoidance signal
Charging dock detection and autonomous docking behavior
Fleet-style telemetry and logging infrastructure, if the project scope grows

This is a long-horizon project, and I'd rather document it honestly in stages than wait for a finished product that may never arrive in the form I'm currently imagining. If you're working on something similar, particularly the sim-to-real side, I'd genuinely like to compare notes.

94 Million Hausa Speakers, and AI Still Barely Understands Them. What Three Years of Grassroots Work Taught Me.

Nathaniel Handan — Sat, 25 Jul 2026 07:05:27 +0000

Hausa is spoken by close to 94 million people in Nigeria alone, with tens of millions more across Niger and the wider Sahel. Nature has reported that ChatGPT and LLMs correctly understands only 10 to 20 percent of sentences written in Hausa.

I've spent the last three years trying to close that gap. First alone, then with a community I founded in Bauchi State that's since grown past 500 people. This isn't really a project retrospective. It's an honest account of what it actually takes to build language technology for a language the industry has quietly decided isn't worth the training data, and what leading the people doing that work with me has taught me.

Why the gap exists, and why scraping the web won't fix it

The easy explanation for Hausa's AI gap is "not enough data." That's true, but it undersells the problem. Hausa has technical properties that make naive data collection actively misleading, not just insufficient.

Start with orthography. Standard written Hausa uses three hooked consonants, ɓ, ɗ, and ƙ, that don't exist on a standard keyboard. In formal, edited text they're there. In the informal Hausa that actually dominates the web (social media, SMS, WhatsApp, the actual keyboards people type on) they're routinely flattened to plain b, d, and k. Scrape the open web for Hausa and you get a corpus quietly missing phonemic information in a large share of its examples, and that gap propagates into anything trained on it, from tokenizers to text to speech models.

Then there's script. Hausa has been written in two systems for over a century: Boko, the Latin based script that's now standard, and Ajami, an Arabic based script still used in religious and literary contexts. A dataset built only from Boko sources is already excluding a real slice of the written language.

Then code-switching. Everyday Hausa, especially online, mixes in English freely and carries a long history of Arabic loanwords from Islamic scholarly tradition. A model that treats Hausa as a clean, isolated language misses how the language is actually used in practice.

Put those together and "low-resource language" starts to look less like "not enough Hausa exists" and more like "the Hausa that's easy to scrape is a degraded sample of the Hausa people actually speak." Standard multilingual tokenizers, trained on that same degraded sample, fragment Hausa words into far more subword pieces than an equivalent English sentence needs. That makes inference more expensive and generation noticeably worse, since the model has fewer clean examples to learn from per token.

That's the actual problem. Not "AI doesn't know Hausa." AI has been fed a thin, flattened version of Hausa, and it shows.

Where I actually started, and why not with an LLM

I founded AI Bauchi in October 2022 out of Abubakar Tafawa Balewa University, with a mission that hasn't changed since day one: make AI indigenous and accessible in Bauchi State, not just consumed from outside it. The language work grew out of that mission, not the other way around.

The tempting move, and the one I've watched well-funded initiatives make, is to announce a "Hausa LLM" on day one. I didn't do that, and I don't think a volunteer community should. A full generative language model needs enormous clean data and compute to be worth the name. What a community of volunteers with day jobs and a group chat actually has is time, native speaker knowledge, and the ability to ship something narrow and useful while the harder foundation gets built underneath it.

So the sequence was deliberate. A Hausa text to speech model first, because it forces you to solve the orthography and pronunciation problem directly. A Hausa to Sayawa translator alongside it, because it forces the team to think about Hausa in relation to another indigenous language instead of only English. A media processing library, HausaMediaLab, that turns both into something a developer outside the project can actually pull in and use. Each of those was scoped to ship, not to impress. Each also produces cleaner labeled data as a byproduct, which is exactly the fuel a more ambitious language model eventually needs.

The part that's actually hard: building a team that isn't just engineers

Here's the decision I'd defend hardest to another technical lead: the TTS project's contributors aren't only machine learning engineers. They're ML engineers, data scientists, linguists, and software developers, working together on purpose.

That's not a diversity nicety, it's an engineering requirement. An ML engineer can build a text to speech pipeline. An ML engineer without a linguist on the team will get tone marking and hooked consonants subtly wrong in ways that are invisible to anyone who doesn't speak the language natively, and obvious to everyone who does.

There's a second representation question underneath that one: which Hausa. The language spans real dialectal variation. The Kano variety often treated as a reference standard is not the only lived version of the language, and a single synthetic voice trained on one region's speech quietly tells everyone else their Hausa is the deviation. A linguist in the room is what catches that before it ships, not after.

So the structure is: weekly progress meetings, native speakers reviewing linguistic decisions, engineers reviewing the model, and a public repo with issues explicitly tagged for newcomers so the contributor pipeline doesn't dry up when the founding few get busy. Alongside the language projects we run bootcamps, an eleven week AI bootcamp and a six week computer vision bootcamp, that exist specifically to grow that pipeline. Most contributors to the harder projects came up through one of those cohorts first.

What this looks like outside the repository

If I only talked about the model, I'd be underselling what actually moved. A few things I'd point to as the real impact:

I spent six months in 2023 as an instructor for NITDA's AI Developer Training, which meant the ideas driving AI Bauchi's work weren't staying inside one community, they were reaching a national training cohort. At DevFest Bauchi 2023 I gave a talk called "Democratizing Indigenous AI," making the case to a room of general developers, most of whom had never thought about Hausa specifically, that inclusive AI development has to start by respecting the linguistic and cultural nuance of the communities it claims to serve. In 2025 we ran EmpowerHer AI Bauchi, built to get more young women into this pipeline early, because a community that only recruits people who already see themselves as engineers keeps producing the same blind spots. And we've taken this outside the university entirely, hosting secondary school students from I-Scholars International Academy for a STEM excursion at NCAIR, Nigeria's National Centre for Artificial Intelligence and Robotics, because the earliest point to fix "who gets to build this" is before someone's chosen a degree.

None of that shows up in a commit history. All of it is why the commit history exists.

Where this sits next to the bigger picture

In 2025, Nigeria's federal government unveiled its own multilingual model effort through NITDA and NCAIR, covering Hausa alongside Yoruba and Igbo. That's a good thing, and it's an enormous, well-funded validation of a problem AI Bauchi had already been working on, in public, since 2023.

I don't think grassroots work like ours competes with that kind of national effort. I think it's what keeps it honest. A federally funded model can move fast and cover a lot of ground. A community-built one, with linguists in the room and native speakers reviewing every tone mark, is what makes sure the fast version doesn't flatten the same nuance the open web already flattened. Both are needed. I'd rather our work be the thing that keeps the bigger effort accountable than the thing racing it for a headline.

Note to self before publishing: I want this section grounded in exactly what I used, not a general gesture at the program. Naming the actual services, credits, or mentorship conversations that fed into this work is also the part AWS reviewers will check most closely.

What being an AWS Community Builder actually gave this

The program's value to this work was never the swag. It was mentorship conversations with AWS specialists who'd already thought hard about deploying models into low connectivity, resource constrained environments, which is the exact condition Bauchi operates under, and credits that let a volunteer community run experiments it couldn't otherwise afford. S3, GPU training instances of Sagemaker

What I'd tell another builder trying this in their own community

Start narrower than feels ambitious. A translator or a TTS model that ships is worth more than a language model that stays a roadmap item. Recruit people who aren't engineers before you think you need them, because by the time you obviously need a linguist, you've already shipped something linguistically wrong. Treat your constraints, low connectivity, volunteer time, no enterprise compute budget, as a design spec, not an excuse. Some of the most careful data hygiene decisions in this project exist specifically because we couldn't afford to throw compute at a sloppy dataset the way a better funded team might.

Where this goes next

The text to speech model and the translator were never the destination. They were how a volunteer community earns the right to attempt something bigger, and that bigger thing is still the goal. If you're building language technology for a community that big tech has decided isn't worth the training data, or you're an AWS Community Builder working in a similarly underserved region or language, I'd genuinely like to compare notes. Drop a comment, or find AI Bauchi and say hello.

Cloud Robotics Development on AWS: Migrating from RoboMaker to Batch

Nathaniel Handan — Thu, 18 Sep 2025 10:46:55 +0000

Introduction

Traditional local robotics simulation (e.g. running Gazebo on a laptop or on-prem server) can be limited by hardware resources and parallelism. AWS RoboMaker was launched to simplify cloud-based robotics development: it provided a fully managed service for ROS/Gazebo simulations, with built-in container images, random world generation (WorldForge), and integration with cloud services (e.g. Kinesis, CloudWatch) via ROS packages[1]. RoboMaker enabled automated scaling of compute for simulation workloads (“fully managed…scales underlying infrastructure”[2]) and offered both headless and GUI (NICE DCV) simulation modes. However, AWS has announced that RoboMaker will be discontinued on September 10, 2025[3]. After that date, the RoboMaker console and APIs will no longer be available, and all simulation workloads must be migrated to alternatives – principally AWS Batch, AWS’s general-purpose batch compute service.

Figure: Example RoboMaker simulation architecture – two containers (a simulation app with NVIDIA Isaac Sim and a robot app with ROS2 Navigation) orchestrated by AWS RoboMaker, pulling images from Amazon ECR and outputting logs to CloudWatch.

AWS Batch provides a container-based, highly scalable batch job scheduler. In contrast to RoboMaker’s robotics-specific interface, Batch requires users to define their own Docker images and compute environments, but offers flexibility and massive scale (including multi-container and multi-node parallel jobs). As AWS notes, “AWS Batch is best used for running headless batch simulations at scale”, whereas interactive GUI simulations were a RoboMaker feature[5]. In practice, migrating to Batch means converting RoboMaker simulation workflows into a containerized CI/CD pipeline on Batch: containerize ROS/Gazebo apps, push images to ECR, define Batch compute environments and jobs, and orchestrate execution. This guide lays out the detailed migration path, compares features of RoboMaker vs Batch, and provides examples and best practices for setting up cloud robotics simulation on AWS Batch.

TL;DR

RoboMaker sunset: AWS RoboMaker ends Sep 2025[3]. All existing simulation apps, worlds, and jobs must be migrated.
Strategy: Move to AWS Batch: export any RoboMaker-generated assets (worlds, models), containerize your robot and simulation code (ROS2 Humble + Gazebo + TurtleBot3) into Docker images, push to ECR, then create AWS Batch compute environments, job queues, and job definitions to run those containers.
Architectural shift: RoboMaker managed infrastructure and had built-in simulation tools; Batch is generic compute. You lose integrated features (e.g. worldforge GUI, on-demand development IDE) but gain control of instance types, unlimited scaling, and cost optimization (no Batch service fee[6], Spot instances, multi-node jobs).
Step-by-step: (1) Export worlds/models from RoboMaker (via WorldForge ZIP to S3)[7]. (2) Build Docker images for your robot app and sim app (use osrf/ros:humble-desktop or Ubuntu base, install TurtleBot3 packages and Gazebo). (3) Push images to ECR. (4) Set up AWS Batch: create a Compute Environment (choose EC2/Spot instances for CPU/GPU), a Job Queue linked to it, and a Job Definition specifying the Docker image, vCPU/memory, commands, and environment variables. (5) Submit and run Batch jobs (single-node or multi-node as needed) to execute your simulations.
Cost & scaling: Unlike RoboMaker’s per-job pricing model, AWS Batch has no extra charge – you pay only for EC2 (or Fargate) resources[6]. Use Spot for cheaper compute. Batch easily scales to hundreds or thousands of concurrent jobs (RoboMaker was limited to 10 concurrent sims by default[8]). Headless (non-GUI) simulations run on plain CPU/GPU instances; GUI/CDV sessions (rare in Batch) require custom setup.
Monitoring & automation: Continue using CloudWatch for logs and metrics (e.g. ROS position/sensor data stream)[9]. Store inputs/outputs and world files in S3. You can orchestrate workflows with AWS Step Functions or CodePipeline, similarly to RoboMaker pipelines[10].

Feature & Architecture Comparison: RoboMaker vs AWS Batch

Service model: RoboMaker is a specialized managed robotics service. It abstracts away servers and networks, providing a GUI for launching simulation jobs[2]. Batch is a generic container batch scheduler (built on ECS/EKS and EC2). You must provision Compute Environments and define job resources yourself. RoboMaker auto-creates instances behind the scenes; Batch lets you control instance types (CPU vs GPU, on-demand vs Spot) and autoscaling.
Workload support: RoboMaker is built for ROS/Gazebo robot simulation. It used to offer prebuilt Docker images for ROS1/2 and Gazebo (though now customers must supply container images)[3][11]. It introduced concepts of Robot applications (the code running on a robot) and Simulation applications (the Gazebo world and scenario). AWS Batch can run any Linux container. You can build ROS2/Gazebo containers and run them on Batch, but there is no built-in “robot vs simulation app” distinction unless you implement it (e.g. separate containers or processes). Notably, AWS Batch now supports multi-container jobs (started Apr 2024)[12]: you can run multiple cooperating containers (e.g. one for Gazebo sim, others for different robot sensor pipelines) within a single Batch job. This enables modular simulation setups similar to RoboMaker’s multi-robot examples (see figure below)[13].
Scalability: RoboMaker allowed batching many simulation jobs via the BatchSimulation API, but had limits (default max 10 concurrent jobs)[8]. It scaled each job’s infrastructure automatically, but overall batch size was constrained by quotas. AWS Batch scales to as many parallel jobs as you request (limited only by account quotas and budget). It also supports multi-node parallel jobs for distributed simulations (for example, spread 4 robots across 4 EC2 nodes). In practice, Batch can run hundreds or thousands of simulations in parallel easily. RoboMaker’s underlying hardware limits were lower and fixed per job (e.g. one c5.2xlarge per simulation, 4 vCPU/32GB by default). On Batch you choose any instance sizes you need (e.g. high-CPU c6i, GPU g4dn, or even the new inf series), and use Spot capacity for cost efficiency.
Headless vs GUI: RoboMaker supported both headless (no X-windows) and interactive GUI simulations via NICE DCV, which allowed streaming the Gazebo/ROS GUI remotely. AWS Batch is designed for headless batch processing[5]. It can run GUI apps in containers (you can even run NICE DCV servers on GPU instances under Batch), but it doesn’t provide the interactive console integration that RoboMaker did. In migration you will likely run Gazebo in headless mode (gzserver only) and collect data/metrics, rather than interact with a live 3D view. Batch is optimized for “thousands of scenarios” at once[14], not manual GUI sessions.
Cloud services integration: RoboMaker included ROS cloud extensions out of the box: packages for streaming video (Kinesis Video Streams), vision inference (Rekognition), voice (Lex/Polly), and metrics/logging (CloudWatch)[1]. These let robot code easily call AWS services. In AWS Batch, you lose that built-in convenience layer, but you can still use the same AWS services by invoking SDKs or passing through Step Functions. For example, you can publish ROS data to CloudWatch logs or metrics exactly as before[9], just handled by your container code. Batch itself does not impose an additional fee – you pay only for the EC2/Fargate resources you use[6], whereas RoboMaker charged by simulation time. Batch supports IAM roles for tasks, VPC networking, and can integrate with S3, EFS, CloudWatch, Step Functions, etc., just like any other AWS compute environment.

Migration Checklist

Export simulation assets: Use RoboMaker’s WorldForge export or manual methods to extract any custom world files, models, or assets you used. RoboMaker can package generated worlds into a ZIP and drop it in S3[7]. Download these files or point to their S3 locations for use in your Docker images or batch jobs. Likewise, retrieve any logs or output data from past RoboMaker runs for reference.
Containerize applications: Build Docker images for your robot and simulation code. For example, start from an official ROS2 Humble base (e.g. osrf/ros:humble-desktop), install Gazebo (Fortress) and TurtleBot3 packages (ros-humble-turtlebot3*), and copy your ROS workspace in. A sample Dockerfile snippet might look like:

FROM ros:humble-ros-base

# Set environment variables
ENV ROS_DISTRO=humble
ENV TURTLEBOT3_MODEL=burger

# Install dependencies
RUN apt-get update && apt-get install -y \
    ros-humble-desktop \
    ros-humble-turtlebot3-gazebo \
    ros-humble-turtlebot3-description \
    ros-humble-gazebo-ros-pkgs \
    gazebo11 \
    && rm -rf /var/lib/apt/lists/*

# Copy your workspace
COPY ./simulation_ws /home/ros_ws
WORKDIR /home/ros_ws

# Build the workspace
RUN /bin/bash -c "source /opt/ros/$ROS_DISTRO/setup.bash && colcon build"

# Source both ROS and workspace overlays
ENTRYPOINT ["/bin/bash", "-c", \
    "source /opt/ros/$ROS_DISTRO/setup.bash && \
     source /home/ros_ws/install/setup.bash && \
     ros2 launch my_sim_pkg simulate.launch.py"]

Modify the ENTRYPOINT or CMD to start your simulation (headless). You can create separate images for the robot-app and sim-app if needed, but with Batch’s multi-container support you can also launch multiple containers from one job. Push these images to Amazon ECR (or any container registry)[15].

Prepare Batch environment: In the AWS Console (or via CloudFormation/CLI), create a Compute Environment for AWS Batch. Choose EC2 (or Fargate) and select instance types needed (e.g., c6i.large for CPU sims, g4dn.xlarge for GPU-enabled Gazebo). Consider using Spot instances for cost savings, since simulation workloads are interruptible. Attach an IAM instance role that allows pulling from ECR and writing to S3/CloudWatch. Create a Job Queue and associate it with this compute environment.
Define Batch jobs: Create an AWS Batch Job Definition. Specify "type": "container" and in containerProperties include: your Docker image URI (from ECR), vCPU count and memory, and the command to run (e.g. ["ros2", "launch", "my_sim_pkg", "simulate.launch.py"]). Add any environment variables (e.g. TURTLEBOT3_MODEL=burger). For example:

{
  "jobDefinitionName": "turtlebot3-sim-job",
  "type": "container",
  "containerProperties": {
    "image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/turtlebot3-sim:latest",
    "vcpus": 4,
    "memory": 8192,
    "command": [
      "bash",
      "-c",
      "ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py"
    ],
    "environment": [
      {
        "name": "TURTLEBOT3_MODEL",
        "value": "burger"
      }
    ],
    "jobRoleArn": "arn:aws:iam::123456789012:role/BatchJobRole"
  }
}

Use the AWS Batch console or RegisterJobDefinition API. Ensure the jobRoleArn has permissions for any AWS calls (CloudWatch, S3). If your simulation needs shared storage (e.g. large maps or logging folders), you can configure EFS volumes in the job or let the container fetch from S3 at startup.

Multi-node or multi-container (optional): For advanced scenarios (e.g. multi-robot swarms or separate sensor modules), use Batch’s Multi-Node Parallel (MNP) jobs or multi-container job feature. MNP allows you to run a single job across multiple EC2 instances. Multi-container jobs (containers sharing a local network on the same node) enable separate processes for e.g. Gazebo, lidar processing, control, etc. This was not possible in RoboMaker (which ran all code in one container), but Batch now supports it[12].
Monitoring & logs: Configure your containers to send output to STDOUT/STDERR so AWS Batch will push logs to CloudWatch Logs by default. For more detailed robot metrics, use ROS CloudWatch packages – e.g. send robot positions or sensor stats to CloudWatch Metrics as in the AWS sample[9]. Set up a CloudWatch log group for your batch jobs. (RoboMaker automatically aggregated logs, but in Batch you manage the logging setup.)
Run and iterate: Submit a Batch job (via Console, AWS CLI submit-job, or through Step Functions). Watch CloudWatch for logs to debug. Tweak your Docker image or job definition if needed. Once a single robot sim works, you can scale up: run many Batch jobs in parallel (AWS Batch will queue them and launch on available EC2 instances).
Automate workflows: To orchestrate batch simulations (for example, sweeping over parameters or training RL policies), use AWS Step Functions or CodePipeline. AWS even published a RoboMaker Sample showing a pipeline for launching simulation batches[10] – you can adapt this by having Step Functions call SubmitJob on AWS Batch instead. For CI/CD, put your Docker build and Batch job submission into a CodePipeline or GitHub Actions workflow.

Cost and Performance Considerations

Pricing model: AWS Batch itself is free – you only pay for the EC2/Fargate resources you use[6]. RoboMaker charged per simulation-second at fixed hardware size, which could be expensive for large batches. With Batch, you can use Spot Instances for dramatic savings (up to 90% off) on fault-tolerant sims. You also control instance size: e.g. use 4 vCPU machines for a light TurtleBot sim, or 32 vCPU/8 GPU instances for a heavy physics simulation.
Scaling: RoboMaker allowed parallel simulation but was capped by quotas (default 10 concurrent jobs[8]) and by its internal resource limits. AWS Batch can scale to hundreds of parallel jobs as long as you request it; there’s no per-job vCPU cap. Batch’s multi-node jobs also let you simulate many robots or heavy compute tasks in one coordinated job. For example, you could run a 4-robot warehouse sim on a 4-node MNP job (one robot per EC2) – something RoboMaker could not natively do.
Headless vs GUI: AWS Batch is designed for headless processing. If you need a real-time GUI (NICE DCV) you must provision GPU instances with desktop streaming yourself. In most robotics dev, you run Gazebo headless and record data for later analysis. RoboMaker’s ease of GUI was convenient for debugging, but came at higher cost (always requiring at least one GPU server). On Batch, you would typically run the same Gazebo world without gzclient.
Throughput & latency: On similar instance types, raw simulation performance is comparable between RoboMaker and Batch (both run on AWS EC2 under the hood). However, Batch can batch-launch many instances quickly, whereas RoboMaker needed to spin up each sim job separately. This means large experiments (e.g. 1000 Monte Carlo sim runs) will complete faster on Batch. RoboMaker also introduced a concept of “simulation unit” (1 unit = 1 vCPU & 2GB RAM) to rate-limit usage, which Batch does not.
Cost example: If you run a 4 vCPU/16GB sim for 1 hour, RoboMaker billed a fixed rate for that instance-hour. On AWS Batch you’d pay the on-demand (or Spot) EC2 rate for 4 vCPU for 1 hour. Using Spot can cut cost greatly for non-time-critical batches. Also, Batch allows scheduling interruptions or spot bids, whereas RoboMaker simply ran until the job finished or hit a limit.

Example AWS Batch Job Definition and Dockerfiles

Example Dockerfile (ROS2 Humble + Gazebo + TurtleBot3):

FROM osrf/ros:humble-desktop

# Set environment variables
ENV ROS_DISTRO=humble
ENV TURTLEBOT3_MODEL=burger

# Install Gazebo and TurtleBot3 packages
RUN apt-get update && apt-get install -y \
    ros-humble-turtlebot3-bringup \
    ros-humble-turtlebot3-gazebo \
    ros-humble-gazebo-ros-pkgs \
    gazebo11 \
    && rm -rf /var/lib/apt/lists/*

# Copy simulation workspace
COPY ./simulation_ws /home/ros_ws
WORKDIR /home/ros_ws

# Build the workspace
RUN /bin/bash -c "source /opt/ros/$ROS_DISTRO/setup.bash && colcon build --symlink-install"

# Create entrypoint script
RUN echo '#!/bin/bash\n\
set -e\n\
source /opt/ros/$ROS_DISTRO/setup.bash\n\
source /home/ros_ws/install/setup.bash\n\
exec "$@"' > /ros_entrypoint.sh && chmod +x /ros_entrypoint.sh

ENTRYPOINT ["/ros_entrypoint.sh"]

# Default command: launch TurtleBot3 world
CMD ["ros2", "launch", "turtlebot3_gazebo", "turtlebot3_world.launch.py"]

This image will launch a Gazebo world (turtlebot3_world.launch.py) with TurtleBot3. Customize the workspace and launch files as needed. Build and push this image to ECR with a command like: docker build -t turtlebot3-sim:latest . then docker tag and aws ecr create-repository & aws ecr get-login-password to push.

Example AWS Batch Job Definition (JSON):

{
  "jobDefinitionName": "TurtleBot3SimulationJob",
  "type": "container",
  "containerProperties": {
    "image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/turtlebot3-sim:latest",
    "vcpus": 4,
    "memory": 16384,
    "command": [
      "bash",
      "-c",
      "ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py"
    ],
    "environment": [
      {
        "name": "TURTLEBOT3_MODEL",
        "value": "burger"
      }
    ],
    "jobRoleArn": "arn:aws:iam::123456789012:role/BatchJobRole"
  }
}

Here we allocate 4 vCPUs and 16 GB RAM for the sim, and pass the model type via env. Adjust vcpus/memory based on your workload. The jobRoleArn should grant permissions to read/write any needed AWS resources (e.g. an S3 bucket for world files or log output, and CloudWatch access).

Monitoring, Storage, and Automation

CloudWatch Monitoring: Instrument your ROS nodes to publish metrics or log to CloudWatch as needed. AWS provides ROS CloudWatch packages (as in the sample) so you can push robot state (position, velocity) and key events to CloudWatch Metrics or Logs[9]. Since Batch runs on ECS underneath, each container’s STDOUT goes to CloudWatch Logs automatically, which you can view in real time for debugging.
Storage (S3/EFS): Use Amazon S3 for storing large assets: keep your exported world ZIPs and static models in an S3 bucket and download them at container startup (or bake them into the Docker image). Simulation outputs (e.g. rosbag files, CSV data) can be written back to S3 at job completion. For shared file-system needs (e.g. sharing a map or checkpoints across multiple Batch job runs), you can mount an Amazon EFS volume in your job definition.
Orchestration (Step Functions/CodePipeline): For complex workflows (e.g. run simulation sweep, then train ML model on results, then run more sims), use AWS Step Functions to coordinate AWS Batch jobs. Step Functions has native support to start Batch jobs and wait for completion. AWS also provides sample pipelines (e.g. RoboMaker “Simulation launcher” using CodePipeline + Step Functions)[10] – you can adapt these so that Step Functions calls Batch instead of RoboMaker APIs. For example, a Step Function state machine could have a “Submit Simulation Job” task (using Action=Batch:SubmitJob) followed by a “Wait for Job” and condition based on job success. Similarly, CodePipeline can trigger a new Docker build and then invoke a Batch job via a Lambda step.
Logging & Alerts: Tag your Batch jobs with meaningful tags and set up CloudWatch alarms on metrics (e.g. if jobs are failing or if S3 buckets grow). You can also export Batch job metrics (queued/running counts) to CloudWatch for dashboards.

By following these steps
– exporting your assets, containerizing your apps, setting up AWS Batch compute and jobs, and integrating logging/automation
– you can replicate and extend your RoboMaker simulations on AWS Batch.

Although the transition requires more setup, Batch gives you much greater flexibility and cost control for large-scale robotics workloads. Leveraging Batch’s multi-node and multi-container capabilities (see figure below) lets you simulate multi-robot systems at scale, and the AWS ecosystem (CloudWatch, S3, Step Functions) provides all the building blocks for a robust CI/CD pipeline for robotics.

Figure: Example AWS Batch multi-robot simulation. A single AWS Batch multi-node job runs one test-scenario container and one Gazebo simulator container on the main node (Node 1), and four robot stacks (Nodes 2–5), each with separate Lidar, control, and vision containers[13]. AWS Batch’s multi-container and multi-node features enable complex simulations at scale.

Sources: AWS documentation and blogs on RoboMaker deprecation and AWS Batch (including AWS Robotics and HPC blogs)[3][14][12][1][7][6][8]. These sources provided official information on service features, pricing, and migration guidance. All code examples and figures are illustrative.

[1] [10] AWS RoboMaker Resources – Amazon Web Services

https://aws.amazon.com/robomaker/resources/

[2] [8] Introducing Batch Simulation API for AWS RoboMaker | AWS Robotics Blog

https://aws.amazon.com/blogs/robotics/introducing-batch-simulation-api-for-aws-robomaker/

[3] Support policy - AWS RoboMaker

https://docs.aws.amazon.com/robomaker/latest/dg/chapter-support-policy.html

[4] Orchestrate NVIDIA Isaac Sim and ROS 2 Navigation on AWS RoboMaker with a public container image | The Internet of Things on AWS – Official Blog

https://aws.amazon.com/blogs/iot/orchestrate-nvidia-isaac-sim-ros-2-navigation-aws-robomaker-public-container-image/

[5] [9] [14] [15] Build headless robotic simulations with AWS Batch | AWS Robotics Blog

https://aws.amazon.com/blogs/robotics/build-headless-robotic-simulations-with-aws-batch/

[6] AWS Batch Pricing

https://aws.amazon.com/batch/pricing/

[7] Using exported worlds in simulation - AWS RoboMaker

https://docs.aws.amazon.com/robomaker/latest/dg/worlds-using-export-simulation.html

[11] AWS RoboMaker - Developer Guide

https://docs.aws.amazon.com/pdfs/robomaker/latest/dg/aws-robomaker-dg.pdf

[12] [13] Run simulations using multiple containers in a single AWS Batch job | AWS HPC Blog

https://aws.amazon.com/blogs/hpc/run-simulations-using-multiple-containers-in-a-single-aws-batch-job/