Optical flow with PAA3905: From breakout board to flight-ready hovering

Optical flow with PAA3905: From breakout board to flight-ready hovering

Building an optical flow sensor system with PAA3905 on Raspberry Pi for drone position hold

The case for optical flow

For indoor autonomous hovering, GPS is useless and barometers can’t distinguish between actual altitude changes and pressure fluctuations. Optical flow — measuring the apparent motion of the ground plane beneath the drone — provides the missing piece: stable position hold relative to the surface below.

The PAA3905 is a high-performance optical flow sensor from Skyworks (originally Broadcom). It captures 35x35 grayscale frames at up to 120 fps, providing the raw pixel displacement data needed for optical flow calculations. Unlike the PMW3901 it succeeded, the PAA3905 offers better low-light performance and more flexible interface options.

Breakout board design

Finding a PAA3905 breakout design was challenging — the datasheet and recommended schematic are not publicly available. We had to learn from existing implementations:

  • A Tindie design by “onehorse” provided a starting reference
  • A Taiwanese-designed HUB-OMT breakout board offered useful insights into the I2C/SPI interface circuitry
  • The official reference design information was scarce, requiring careful reverse-engineering of the signal paths

The breakout board was designed in KiCAD and sent for fabrication. By December 2025, the boards were ready and the driver development could begin.

Driving the PAA3905 on Raspberry Pi

The Raspberry Pi provided an ideal host for PAA3905 development. Using SPI1 with CS1, we achieved approximately 9 Hz frame capture at 35x35 grayscale (0-255). Even under the dimmest ceiling lighting, the sensor could clearly capture surface texture details — enough for basic displacement detection algorithms.

The data pipeline looked like this:

PAA3905 (SPI) -> 35x35 frames -> Node.js processing -> MAVLink telemetry

A video demo showed the PAA3905’s frame output alongside a webcam pointed at the same surface. As the lighting was dimmed from full brightness to complete darkness, the PAA3905 continued producing usable images — a significant advantage over RGB cameras in controlled indoor environments.

Running PX4-Flow on PAA3905

The PX4-Flow algorithm, originally designed for the PMW3901, was adapted to work with PAA3905 frame data. The implementation compares consecutive 35x35 frames to calculate pixel displacement, which is then converted to velocity estimates.

The test setup placed both a PAA3905 module and a Logitech C920 webcam facing the same cardboard box. Moving the box while keeping the cameras stationary simulated the camera’s motion during flight — a practical approach for algorithm validation without needing an actual flying platform.

Looking toward PiCamera

While the PAA3905 works well for basic optical flow, a Raspberry Pi Camera could provide higher-resolution surface data for more sophisticated computer vision approaches. The plan involves modifying rpicam-hello to continuously capture 640x480x8 bit frame streams and running the PX4-Flow algorithm directly in C++.

The data pipeline would expand to:

PiCamera -> frames -> optical flow (C++) -> MSP protocol -> Betaflight

There’s also interest in exploring ROS2 SensorImage publishers for a more modular architecture, which would allow different vision models to be swapped in without recompiling the camera capture application.

Integration with the flight controller

For the TFC1 flight controller, optical flow integration required careful UART planning. The RP2350B’s limited UART resources meant choosing between:

  1. Using hardware UART0/UART1 for RC receiver and debug
  2. Implementing PIO-UART for the optical flow sensor
  3. Going directly to SPI for higher data rates

The PMW3901 documentation showed that SPI is preferred for serious optical flow applications — UART is simply too slow for the frame rates needed at higher flight speeds. The 35x35 frame buffer over UART creates a bottleneck that limits the useful altitude range.

For our near-term indoor hovering application, UART-based optical flow proved sufficient. The system demonstrated stable position hold on smooth-textured surfaces under adequate lighting conditions.

Questions? Requests? Suggestions?

We are looking forward to hearing from you!

Are you looking for
Consulting Services,
Support Plans or
Training & Workshops?