Rusty Flying Robots: Learning a Full Robotics Stack with Real-Time Operation on an STM32 Microcontroller in a 9 ECTS MS Course

This paper presents a novel 9 ECTS master's course where students learn a complete robotics stack by implementing nonlinear control and state estimation algorithms in Rust on both PC simulations and resource-constrained STM32 microcontrollers, emphasizing the avoidance of black-box software to achieve real-time flight.

The Gist

Imagine you want to teach a class of students how to build a flying robot. Usually, professors face a tricky choice:

1. The "Toy" Route: Teach them simple math and let them code in easy languages (like Python), but the robot is too slow to actually fly in the real world. It's like learning to drive in a video game where the physics are fake.
2. The "Black Box" Route: Give them a pre-made, super-complex software kit (like a full car engine) so they can drive immediately, but they never learn how the engine works.
3. The "Hard Mode" Route: Force them to write everything from scratch in difficult, old-school languages (C/C++). This is great for learning, but it takes years to build the software, leaving no time to learn the actual robotics science.

This paper describes a new, clever way to do it. The authors created a course called "Rusty Flying Robots" that forces students to build a real, flying drone from the ground up, but they use a modern programming language called Rust to make it possible.

Here is the breakdown using simple analogies:

1. The Challenge: The "Tiny Brain" Problem

Most advanced robots run on powerful computers (like laptops). But real drones need to be small and light, so they use tiny, weak microchips (called STM32).

• The Analogy: Imagine trying to run a high-definition movie on a 1990s calculator. It's supposed to be impossible.
• The Solution: The students had to write code so efficient that it could run complex math on this tiny chip in "real-time" (meaning the drone reacts instantly, not a second later). If the code is too slow, the drone crashes.

2. The Secret Weapon: Rust

The class didn't use Python (too slow) or C (too dangerous and hard to manage). They used Rust.

• The Analogy: Think of C as a manual transmission car with no seatbelts; if you make one tiny mistake, the car explodes. Python is like an automatic car with a heavy, slow engine; it's easy to drive but can't go fast enough for a race. Rust is like a race car with an automatic seatbelt system. It forces you to drive safely (no crashes due to memory errors) but still lets you go at full speed.
• The Result: Even though most students had never seen Rust before, they learned it quickly because the language "catches" their mistakes before the code even runs.

3. The Four-Step Journey (The Syllabus)

Instead of using pre-made tools, the students built the entire "brain" of the drone in four stages:

• Step 1: Building the Simulator (The Flight Simulator)
  • What they did: Before touching a real drone, they had to write their own video game to simulate physics.
  • The Analogy: Instead of renting a flight simulator, they had to build the physics engine, the wind, and the gravity from scratch. This taught them exactly how the drone moves mathematically.
• Step 2: The Controller (The Pilot)
  • What they did: They wrote the code that tells the motors how fast to spin to keep the drone steady.
  • The Analogy: This is the "pilot's hands." If the wind blows the drone left, the pilot must instantly push the right motor harder. The students had to write this math so it worked on the tiny chip without the drone spinning out of control.
• Step 3: The State Estimator (The Eyes)
  • What they did: The drone has sensors (gyroscopes, cameras) that are noisy and imperfect. The students wrote code to guess the drone's true position.
  • The Analogy: Imagine trying to walk through a foggy room while wearing glasses that distort your vision. You have to use your brain to guess where the wall actually is. The students built a mathematical "brain" that filters out the noise to know exactly where the drone is.
• Step 4: The Planner (The Navigator)
  • What they did: They taught the drone how to fly through narrow gaps and make sharp turns.
  • The Analogy: This is the "GPS." It doesn't just say "go straight"; it calculates a smooth, fancy path to dodge obstacles, like a parkour athlete jumping between walls.

4. The Outcome: Did it Work?

The course was a huge success.

• The Students: They were mostly computer science or engineering students. They had to learn a new language (Rust) and complex math, but they loved it.
• The Feedback: Students called it "one of the best lectures ever." They admitted it was hard and took a lot of time, but they felt a massive sense of accomplishment when their code actually made a real drone fly.
• The Takeaway: You don't need to hide the hard parts of robotics. If you give students the right tools (like Rust) and let them build the whole system, they can handle advanced, real-world engineering challenges much faster than expected.

In short: This paper proves that you can teach students to build a high-tech, real-world flying robot from scratch, using a tiny computer, without needing a super-computer or a pre-made software kit. It turns the classroom into a real engineering lab.

Technical Summary

1. Problem Statement

The paper addresses a fundamental dilemma in robotics education: the trade-off between algorithmic complexity and hardware constraints.

• The Dilemma: Traditional courses often force a choice between:
  1. Implementing simple algorithms in low-level languages (C/C++) to run on hardware.
  2. Implementing advanced algorithms using sophisticated infrastructure (e.g., ROS 2, Drake) that abstracts away hardware details.
  3. Running complex algorithms in simulation (e.g., Python/Gazebo) without real-time deployment.
• The Gap: None of these options fully capture the challenge of deploying state-of-the-art, nonlinear robotics algorithms on resource-constrained embedded hardware, which is critical for real-world STEM engagement.
• The Challenge: Students must implement a full robotics pipeline (dynamics, control, estimation, planning) that runs in real-time on a microcontroller (STM32, 168 MHz, 192 KB RAM) without relying on heavy software frameworks or pre-built black-box libraries.

2. Methodology

The authors designed a 9 ECTS (270 hours) Master's level project course centered on the Bitcraze Crazyflie 2.1 quadrotor. The course is structured around four core modules, utilizing Rust as the single programming language for both simulation and embedded deployment.

Core Pedagogical Concepts

1. No Black-Box Infrastructure: Students must build their own simulation environment and mathematical libraries rather than using pre-packaged tools (like Gazebo or standard math libraries).
2. Unified Language (Rust): Rust is chosen for its ability to provide memory safety (via the borrow checker), high performance (compiled code), and embedded support, bridging the gap between high-level simulation and low-level firmware.

Course Structure (The Robotics Pipeline)

The course follows a standard robotics stack, with each phase requiring implementation in Rust and validation on the STM32:

• Phase 1: Simulation (4 Weeks)

  • Task: Students implement a custom 3D multirotor simulator from scratch.
  • Technical Details: They must derive dynamics in $SE(3)$, implement quaternions for rotation, and create a custom math library (avoiding heap allocations).
  • Validation: The simulator is validated against mathematically derived trajectories (using differential flatness) and real-world sensor data collected from the physical robot.

• Phase 2: Nonlinear Control (4 Weeks)

  • Task: Implementation of a Nonlinear Geometric Controller with exponential stability guarantees (similar to those in PX4).
  • Technical Details: The control law relies on linear algebra and rotation matrices. Students integrate their Rust controller into the existing C-based STM32 firmware using bindgen for interoperability.
  • Challenge: Debugging unit conversions and data type mismatches between C and Rust, where minor errors cause immediate flight crashes.

• Phase 3: State Estimation (3 Weeks)

  • Task: Implementation of a Multiplicative Extended Kalman Filter (MEKF) for $SO(3)$ to estimate position, orientation, and velocity using gyroscope, accelerometer, and optical flow data.
  • Technical Details: This is the most computationally intensive part, requiring the inversion of a $9 \times 9$ matrix in real-time. Students use symbolic differentiation (SymPy) and scalar updates to optimize the code for the microcontroller.
  • Validation: Comparison against ground truth data and the robot's onboard MEKF.

• Phase 4: Motion Planning (3 Weeks)

  • Task: Implementation of agile motion planning through narrow passages.
  • Technical Details: Utilizing Differential Flatness to plan smooth 3D trajectories. Students formulate the problem as a Quadratic Program (QP) and use a solver generator to create a real-time capable solver that runs on the STM32.

3. Key Contributions

• Curriculum Design: A novel, open-source curriculum that successfully teaches a full nonlinear robotics stack on a 9 ECTS timeline without pre-built libraries.
• Rust in Robotics Education: Demonstrates that Rust is a viable and effective language for teaching embedded robotics, offering a unique combination of safety, performance, and ease of use for both simulation and deployment.
• End-to-End Implementation: The course forces students to bridge the gap between theoretical math (differential flatness, $SO(3)$ manifolds) and practical engineering (memory management, real-time constraints, C/Rust interoperability).
• Open Resources: All teaching materials, including code examples and lecture notes, are publicly available, allowing replication at other institutions.

4. Results

The course was piloted twice (Fall 24/25 and Fall 25/26) with 10 students per cohort.

• Student Demographics: Primarily Computer Science, Engineering, and Electrical Engineering students (3rd/4th semester).
• Workload: Most students reported spending 6–9 hours per week, fitting within the expected 9 ECTS effort, despite learning a new language (Rust) with no prior experience.
• Performance:
  • Students successfully implemented all four modules.
  • The transition from simulation to real hardware was generally successful, with issues primarily arising from language interoperability (C/Rust) rather than algorithmic failure.
• Feedback:
  • Rating: Extremely positive (Mean score: 1.1/5.0, where 1 is best).
  • Qualitative: Students described it as "one of the best" and "genuinely fun," despite the high implementation effort.
  • Critique: Some students requested more comprehensive lecture materials (e.g., scripts) and smaller, incremental deliverables for complex assignments.

5. Significance

This work redefines how advanced robotics can be taught by proving that complexity and constraint are not mutually exclusive in education.

• Pedagogical Impact: It moves beyond "toy" simulations or "black-box" frameworks, fostering deep understanding of the underlying physics and mathematics required for real-world deployment.
• Technological Shift: It validates Rust as a superior alternative to the traditional C/Python dichotomy for robotics education, offering memory safety without sacrificing the real-time performance required for embedded control.
• Scalability: The provided blueprint and open materials allow other universities to adopt this "full-stack" approach, potentially inspiring similar curricula for undergraduate education in the future.

In summary, the paper presents a successful model for teaching high-fidelity robotics where students do not just use algorithms, but build the entire software stack required to make a robot fly in real-time on a microcontroller.