Glider-AI

One kilobyteor RAM, this is less then a single tweet. Zero floating-point ops. Glider-AI run a genuine neuronal network on the smallest ARM core and it just told my toy glider if did a barrel roll.

Comment

GLIDER: Physical AI on the World's Smallest Arm Microcontroller

A binary neural network (BNN) that understands flight dynamics in real time. It runs bare metal on a 1.38 mm² Cortex M0+ with just 1 KB of RAM. No OS. No floating point. And it still leaves 97 % of the CPU available for the rest of the application.

System & Arm Optimization Specs at a Glance

Parameter Specification
Target Silicon TI MSPM0C1104 (Arm Cortex M0+ @ 24 MHz, 16 KB Flash, 1 KB SRAM, 1.38 mm² package)
Arm Architecture ARMv6 M: Leverages standard 32 bit core registers (R0 to R12) for bitwise logic, bypassing the lack of a hardware FPU or NPU
Model Architecture TC ResNet style 1D CNN with Binary Weights and Activations (2,677 parameters)
Memory Footprint 764 B weights, 3,836 B Flash total (23 %), 870 B SRAM peak (85 %, entire app included)
Compute Execution 14.1 ms per inference (~338k cycles), 2 classifications/s -> 2.8 % total CPU load
Accuracy & Fidelity 1.000 val accuracy; 100 % synthetic to real transfer; 33/33 bit exact match
I/O Interface 16 LED NeoPixel ring driven via raw SPI bit packing in real aircraft lighting protocol

What Inspired Me: The Story of a Toy Glider

If you throw a simple foam glider off a hill, it performs three distinct aerodynamic maneuvers. It glides, it rolls, or it loops. Standing on the ground, you can name each one instantly. But the glider itself has no idea what it is doing.

I wanted to give it an onboard brain.

At first glance, making a glider understand its own motion sounds like a solved problem. You just strap on an IMU sensor, run a small CNN, and you are done. But the moment I looked at what can actually live inside a 30 gram foam wing, every normal edge AI rule breaks down. The system must cost only cents, weigh almost nothing, and draw microamps. In this environment, you have:

  • No Linux or RTOS abstractions
  • No Neural Processing Unit (NPU)
  • No Floating Point Unit (FPU) or DSP extensions
  • Only 1,024 bytes of total RAM

Most edge AI projects ask: "What is the smallest chip that can run my model?"

I decided to invert the question entirely. I built this project solo to prove a point:

"What is the smallest Arm processor in existence, and can I squeeze a neural network inside it alongside a fully functioning end product?"

My search led me to the TI MSPM0C1104. This is an Arm Cortex M0+ running at 24 MHz with 16 KB of Flash and 1 KB of SRAM in a 1.38 mm² package. It is smaller than a single grain of rice.

To put that into perspective, 1 KB of SRAM means 1024 bytes. Just one second of 6 axis IMU sensor data consumes 300 bytes. This takes up nearly 30% of the entire chip memory before executing a single line of application code. GLIDER proves that bare metal Physical AI on the absolute silicon floor is not just possible, but also incredibly efficient.

Physical AI & Digital Twin: Simulation Before Real World Deployment

In industrial Physical AI applications like robotics, autonomous vehicles, and drones, you rarely train directly on live physical hardware. Instead, you build a digital twin simulation. This allows you to safely generate data, refine physical error models, and validate inference loops before going into the field.

I built a Python PyGame simulator to serve as this exact Physical AI testbed:

  • Data Generation: Simulates true aerodynamic flight dynamics at 50 Hz.
  • Sensor Emulation: Runs an explicit MPU 6050 physical error model (thermal drift, g sensitivity, scale factor errors) to train the model on noisy real world physics. -> Datasource from a IMU paper
  • Hardware in the Loop (HIL): Streams telemetry directly to physical silicon and visually validates predicted states side by side with simulator ground truth in real time.

How I Built It & How I Shrank the Model

To ensure absolute timing and memory control, I engineered a complete, closed loop hardware in the loop (HIL) pipeline. It operates in three distinct stages:

Stage 1: PC / Simulator (Ground Truth)

  • PyGame Glider Simulation: Computes full aerodynamic flight physics at 50 Hz.
  • Physical Sensor Error Model: Injects MPU 6050 noise, thermal drift, and saturation into the clean physics data.
  • UART Transmission: Streams these 16 bit raw sensor codes directly to the MCU at 115k baud.

Stage 2: MSPM0C1104 MCU (Arm Cortex M0+)

  • In Place Quantization: As bytes arrive, the Arm core immediately quantizes them into an int8 rolling buffer. This eliminates the need for staging arrays.
  • Bare Metal BNN Inference: Executes XNOR based 1D convolutions using standard 32 bit integer registers, completely OS free.
  • Telemetry Return: Sends predictions back to the PC HUD for pixel exact C code vs Python comparison.

Stage 3: Physical Output

  • SPI Bit Packed Driver: The MCU converts the inference into a 2.4 MHz SPI waveform to drive WS2812 LEDs.
  • Visual Validation: A physical 16 LED ring outputs real aircraft lighting patterns in real time.

How I Shrank the Model to Fit the MCU

Shrinking a PyTorch model into 764 bytes of Flash and under 1 KB RAM required strict structural optimizations. These are specifically tailored for the ARMv6 M architecture:

  1. Topology Compression (Depthwise Separable TC ResNet): Rather than standard 1D Convolutions, I decoupled temporal filtering from spatial aggregation using Depthwise Separable layers. Spatial filters look at isolated time steps across 5 tap windows, while 1x1 Pointwise convolutions handle cross channel fusion. This reduced the parameter count down to just 2,677 parameters.
  2. Full Weight & Activation Binarization: Trained via a Straight Through Estimator (STE), weights and internal feature maps are converted to single bits. Every parameter needs only 1 bit of storage. This allows all 2,677 parameters to fit into 764 bytes of Flash.
  3. Zero Copy In Place Input Quantization: Storing raw int16 windows consumes 600 bytes of RAM. I quantized incoming IMU codes directly into an int8_t[6][50] ring buffer on arrival. Index math handles window offsets without allocating secondary staging buffers or re quantizing samples. This locks the input RAM at exactly 300 bytes.
  4. Intermediate Buffer Ping Ponging: Intermediate layer activations do not allocate individual memory buffers. Instead, they alternate back and forth ("ping pong") across two static 40 byte scratchpad arrays. This caps peak activation SRAM at 80 bytes.

Model Layer Breakdown

Layer N (fan in) Window Meaning Possible sum values
Depthwise 1 5 5 timesteps of one channel Temporal pattern: "does my last 100 ms look like this?" 6
Pointwise 1 16 16 channels at one timestep Feature pattern: "does the current pose match right now?" 17
Depthwise 2 5 5 timesteps, second stage Temporal pattern, second stage 6
Pointwise 2 32 32 channels at one timestep Feature pattern, second stage 33
  • Physical LED Output: Classifications trigger a 16 LED NeoPixel ring via a custom 2.4 MHz SPI driver. It displays authentic aircraft lighting patterns:
Classified Class Flight State Physical LED Output
idle Ground / Stationary Blue "breathing" pulse (4 s period)
fly Gliding (including banked turns) Night flight pattern (Red beacon, dual white strobes)
roll left / right Rapid Roll Left/Right Cyan chase animation moving counter clockwise / clockwise
loop Pitch Loop Amber spinner rotating at 1.5 rev/s

Challenges I Faced

  • Surviving the 1,024 Byte SRAM Limit: The primary constraint was SRAM, not Flash. A naive pipeline allocates separate memory for raw buffers, quantized windows, layer outputs, and peripherals. This easily exceeds 2 KB. Managing the strict memory budget required mapping memory allocations down to the single byte. It leaves peak execution at 870 bytes (85 % capacity) with zero dynamic allocation (malloc).
  • Sim to Real Model Collapse: Training binary neural networks on clean physics proved disastrous. BNNs are hyper sensitive to inputs and easily learn fragile, degenerate shortcut paths. When tested against real world sensor drift, those clean trained networks failed completely. I had to construct a rigorous MPU 6050 physical error model. This simulates Gauss Markov bias instability, exponential thermal warm up drift, g sensitivity, and centripetal accelerations. This forced the network to learn robust, noise resilient representations.
  • Bare Metal Timing & Bit Packing Alignment: Operating without an OS means interrupt delays or long execution blocks risk corrupting real time UART reception or WS2812 LED timing. I engineered a custom 2.4 MHz SPI bit packing driver. It encodes 1 WS2812 data bit into 3 SPI MOSI bits to refresh physical LEDs in real time without stalling MCU processing or missing incoming IMU frames.
  • No Floating Point or Acceleration Hardware: Running a neural network on an ARMv6 M core means every single byte conversion, matrix dot product, and activation function must run entirely on basic 32 bit integer registers without standard floating point operations.

What I Learned

  • Dataset Physics Trumps Network Size: In ultra low bit neural networks, model capacity is scarce. You cannot rely on parameter scale to compensate for poor data. Rigorously modeling real world sensor physics in simulation yields a 100 % synthetic to real transfer accuracy. This proves that dataset fidelity is the key enabler for micro scale edge AI.
  • Binary Neural Networks Excel at Extreme Constraints: Single bit weight and activation binarization reduces the model footprint by 32x over float32 architectures. This unlocks complex temporal pattern recognition on low cost microcontrollers previously thought far too small for machine learning.
  • Extreme Efficiency at the Bottom: You do not need megabytes of RAM, RTOS layers, or dedicated NPUs for real time motion intelligence. On a 1.38 mm² Arm chip, a complete 1D BNN inference executes in 14.1 ms (~338k cycles). It consumes only 2.8 % of the CPU at 2 Hz, which leaves 97.2 % free for user applications.

Built With

Share this project:

Updates