ROS 2 Indoor SLAM Drones: What to Buy for Teaching

A $6,000 “teaching drone” sounds straightforward until you add one non-negotiable requirement: it has to localize and map indoors on its own. No motion-capture room. No AprilTag grid taped to every wall. No Lighthouse base stations. Just a drone, onboard sensors, onboard compute, and a ROS 2 stack students can actually ship.

That’s the core tension behind a recent ROS community question: a postgraduate program wants ROS 2-compatible drones with onboard SLAM (LiDAR, RGB‑D, or stereo), built for indoor autonomy and coursework. It’s a perfect microcosm of the bigger theme in our AI in Robotics & Automation series: modern autonomy isn’t “AI in the cloud.” It’s AI on the robot, running perception, state estimation, mapping, planning, and control as a tight loop.

Here’s how I’d approach the purchase decision—and how to set up a curriculum that avoids the usual traps.

Start with the hard truth: “onboard SLAM” is a system, not a sensor

If a vendor says “SLAM-ready,” translate that to: camera(s) + IMU + time sync + lighting tolerance + compute + software maturity + tuning docs. Miss one piece and your students will spend the semester debugging drift instead of learning autonomy.

For indoor drones, there are two common autonomy routes:

• VIO / Visual-Inertial Odometry (stereo or RGB cameras + IMU): Light, power-efficient, and common on small drones. Weakness: shiny floors, blank walls, low light, motion blur.
• LiDAR-inertial odometry (3D LiDAR + IMU): More robust to lighting and texture issues. Weakness: payload/price/power, plus integration effort.

Most educational programs succeed faster with stereo VIO first, then add LiDAR as an advanced track. That sequencing matches how real products are built: stable estimation first, then richer mapping.

The non-obvious requirement: time synchronization

Indoor SLAM fails in boring ways when the camera/IMU clocks drift or the middleware introduces latency spikes. If you want students to learn algorithms rather than fight plumbing, prioritize platforms that provide:

• Hardware timestamping (or at least stable synchronized clocks)
• IMU + camera calibration files and tooling
• A reference state-estimation pipeline that actually flies

That’s why ROS 2 “integration quality” matters more than whether a drone simply “supports ROS 2.”

What “ROS 2-native” should mean for an educational drone

If your program is teaching autonomous navigation, you’re not just buying a quadcopter—you’re buying an API contract students can build against.

At minimum, look for:

1. Well-maintained ROS 2 packages (not a single GitHub repo last touched two years ago)
2. ROS 2 message/interface consistency (standard sensor_msgs, nav_msgs, transforms, frame conventions)
3. A supported flight stack (PX4 is the most common choice for research/education)
4. A realistic simulation story (PX4 SITL + Gazebo, or an equivalent pipeline)
5. A “reset-to-known-good” recovery path for lab time (imaging scripts, containerized builds, known versions)

The goal is repeatability. In a class setting, you need students to reproduce results across machines and teams, especially at the end of the semester when demos are stacked back-to-back.

Evaluating indoor SLAM performance: what to test before you buy

If you can borrow or demo a platform—even for a day—run these tests. They predict 80% of your semester pain.

1) The “blank hallway” test

Fly down a corridor with white walls and a shiny floor.

• VIO drift shows up quickly here.
• Look for stable pose and no sudden yaw snaps.

2) The “lighting sabotage” test

Turn off half the lights, then introduce a bright window.

• If exposure changes cause tracking loss, students will see random failures that look like “bugs.”

3) The “vibration and motion blur” test

Do a few quick accelerations.

• Poor mounting or camera settings will degrade feature tracking.

4) The “mapping is not navigation” test

Generate a map and then re-localize in it on a different day.

• Many stacks can build a map once; fewer can reliably close the loop and relocalize.

5) CPU/GPU headroom test

Turn on what students will actually run:

• VIO/SLAM
• Depth or point cloud pipeline
• Obstacle avoidance
• Logging/rosbag

If the platform runs at 90–100% utilization during a calm hover, it will fall apart during real flight.

Practical platform options under ~$6,000 (and what to watch)

The original discussion mentioned platforms like Crazyflie and Tello—excellent for basics and swarms, but typically dependent on external localization infrastructure for “real” indoor autonomy. So what else fits?

Below are categories that match the requirement: indoor flight without external positioning and ROS 2 compatibility, with realistic expectations about integration effort.

Option A: Purpose-built ROS 2 + PX4 indoor autonomy platforms (fastest to teach)

The standout class here is a drone that ships with:

• PX4 autopilot integration
• Onboard stereo cameras + IMU
• A flight computer intended for onboard perception
• Vendor-supported ROS 2 interfaces

ModalAI Starling-class platforms are often considered because they’re designed around onboard autonomy rather than “camera drone” workflows. If you’re evaluating something in this family, focus your due diligence on:

• ROS 2 support quality: Are the nodes actively maintained for current ROS 2 distros? Are message types stable? Are there example stacks for offboard control?
• VIO reliability indoors: Does it handle texture-poor scenes? What happens in low light?
• Student friction: Is there a “golden image” you can flash? Are builds containerized? Can you recover from a broken environment quickly?
• Docs/community: Is there a forum/Discord where questions get answered in days (not months)?

My bias: for coursework, documentation and reproducibility are worth more than raw performance. A slightly less capable platform that boots into a known-good stack will teach more than a powerful platform that requires constant babysitting.

Option B: Build-your-own PX4 + companion computer (most flexible, most labor)

You can assemble an indoor SLAM drone with:

• A PX4-capable autopilot
• A companion computer (often an NVIDIA Jetson-class device)
• Stereo or RGB‑D camera
• Optional 3D LiDAR

This route wins on flexibility and long-term research value. It also loses on class-time reliability unless you standardize heavily.

If you go DIY, plan for:

• A standardized software image (one per cohort)
• A strict parts list (down to cables and mounts)
• A calibration day early in the term

DIY is best when you have a dedicated TA or lab engineer who treats the platform like a product.

Option C: “Research drones” with strong autonomy stacks (great, often over budget)

Many research-targeted drones do indoor autonomy well, but the total cost climbs once you include sensors, compute, batteries, spares, and safety equipment. If your true budget is $6,000 all-in, be careful: a “$5,999 drone” can become a $9,000 program once you add:

• 2–3 spare battery sets per drone
• Spare props/arms
• Chargers and fire-safe storage
• Replacement camera cables (they fail)
• Safety gear and netting

In education, spares aren’t optional—they’re what keeps labs running.

How to structure a ROS 2 + SLAM drone course that actually ships demos

A big reason these purchases go sideways is curriculum mismatch. People buy a drone assuming students will “do SLAM,” but the course asks them to implement everything from scratch.

A better structure is layered autonomy, where each layer is demo-able.

Module 1: ROS 2 foundations on the drone (Week 1–3)

Students should be able to:

• Subscribe to IMU/camera topics
• Understand frames (map, odom, base_link)
• Log and replay datasets

Deliverable: a bagged flight dataset + offline visualization.

Module 2: State estimation you can trust (Week 4–6)

Pick one supported pipeline (vendor VIO, VINS-style approach, or a LiDAR-inertial pipeline). Don’t allow ten different stacks in the same class.

Deliverable: stable odometry in a test arena with quantifiable drift.

Module 3: Mapping and relocalization (Week 7–9)

This is where SLAM becomes “real.” Teach loop closure, map consistency, and relocalization.

Deliverable: build a map, land, re-launch, and relocalize.

Module 4: Planning + safety (Week 10–12)

Planning indoors isn’t hard because of A*; it’s hard because your sensor model is messy.

Deliverable: collision-free waypoint missions with an explicit safety state machine.

Module 5: “AI on the edge” extensions (Week 13+)

This is where the AI in Robotics & Automation theme shines:

• Learned perception (semantic obstacles, people detection)
• Learned policies for exploration (with guardrails)
• Domain randomization from sim to real

Deliverable: a capability that improves autonomy, measured by a metric (e.g., fewer tracking losses, faster exploration, fewer stops).

Simulation-to-real: the workflow that reduces student pain

Teams often lose weeks because their sim and real stacks diverge.

Here’s what works in practice:

• Use the same ROS 2 interfaces in sim and on hardware (same topic names, frames, message types).
• Make SITL mandatory early. Students should prove logic in simulation before they get prop time.
• Record “golden bags.” Provide curated datasets that reproduce common failure cases (low light, blur, texture-less rooms).
• Treat parameters like code. Version control the exact parameter set used for demos.

A class that can replay a bag and reproduce a bug will move faster than a class that can only test by flying.

Buyer’s checklist: what to demand from vendors (or your lab engineer)

Use this checklist before purchasing multiple units.

• ROS 2 distro support: Which distros are supported right now? What’s the upgrade path?
• Example autonomy stack: Not just “teleop works”—show VIO + basic navigation.
• Calibration tooling: Camera/IMU calibration instructions and artifacts.
• Spares availability: Props, arms, batteries, camera cables in stock.
• Fleet management: Can you image/restore devices quickly for lab sessions?
• Safety story: Kill switch, geofencing options, indoor test recommendations.

A drone that’s easy to re-image and recover is the difference between a smooth lab and a semester of “it worked yesterday.”

Where this is headed in 2026: autonomy stacks are becoming “courseware”

By late 2025, ROS 2 has solidified as the integration layer where perception, planning, and control meet. The next shift is educational: autonomy stacks will be packaged like courseware, with consistent APIs, reproducible builds, and simulation parity.

If you’re selecting a ROS 2 indoor SLAM drone now, choose the platform that behaves like a product, not a weekend project. Your students will still face real autonomy problems—drift, lighting, dynamic obstacles—but they won’t waste weeks on avoidable integration debt.

If you’re building an indoor autonomy lab for 2026 intake, what’s your bigger goal: teaching SLAM internals, or teaching students how to ship a reliable ROS 2 autonomy pipeline under real constraints? The right drone choice depends on that answer.