Holding the horizon still
A CanSat descends spinning, so its camera does too — and the footage is unusable. This study works the problem from both ends: correct the image in software, or cancel the spin in hardware. The arithmetic decided it. At 640×480 and 24 FPS a raw feed is 22 MB every second, which no CanSat-class processor is going to chew through mid-flight.
TALIA AEROSPACE · NASA CANSAT COMPETITION · 2020 · ROLE: MECHANICAL SUBSYSTEM LEAD
640 × 480
RESOLUTION
307,200 pixels per frame
921,600 B
PER FRAME
307,200 × 24 bits ÷ 8
22.1 MB/s
AT 24 FPS
Sustained, in flight, on battery
Rotating every frame back into place means touching all of that data, every second, on a processor that also has to fly the vehicle. Cancelling the rotation mechanically costs a motor and a gyro — and nothing at all at runtime.
SOFTWARE STABILIZATION
- +No additional hardware
- +Can be applied post-processing on the ground
- −High computational load, every frame
- −Needs a processor the mass budget will not allow
- −Large memory requirement
TRACKING BY IMAGE POINT — FAILS WHEN THE POINT LEAVES FRAME
HARDWARE STABILIZATION — CHOSEN
- +Real-time; the camera never sees the spin
- +Zero processing overhead in flight
- +Yaw read straight from the gyro, not inferred from pixels
- −Additional weight
- −Separate power and a more complex mechanism
GYRO → MOTOR → ENCODER, CLOSED LOOP
COMPONENTS
- Gyroscope on the body to measure yaw rate
- Electric motor driving the camera platform
- Motor encoder to close the loop on angle
- A power source independent of the flight computer
WHAT I LEARNED
- The cheapest place to solve a problem is often upstream of the code
- Sensors beat inference — read yaw, do not recover it from pixels
- Sketch the mechanism before optimizing the algorithm
- A back-of-envelope data-rate calculation can end an architecture debate
"MY AWESOME PAINT DRAWING" — ORIGINAL CAPTION, 2020