Lighthouse positioning for ArduPilot

[odraudE31]

Hi everyone,

We are working at LuminousBees on integrating SteamVR Lighthouse V2 tracking into our indoor drone fleet (running ArduPilot). We are closely following the pioneering work Bitcraze has done with the Lighthouse positioning deck, and as we design our own receiver board, we have a few questions about the data flow and architectural choices in your implementation.

Specifically, we are trying to understand the exact boundary between the sensor deck (which we understand uses an FPGA, or an RP2350 in the newer LH-16 prototypes) and the flight controller (STM32F405), as well as the benefits of your EKF approach.

1. Data Handoff (RP2350/FPGA ➔ STM32F405)
   Where exactly is the line drawn for data processing? When data exits the deck's microcontroller/FPGA and enters the Crazyflie's F405, what exactly is being transmitted? Are you sending raw pulse timings, timestamps, and base station IDs, or are you pre-computing the sweep angles (azimuth and elevation) on the deck and passing those?

2. Where is Position Actually Resolved?
   Based on our reading of the architecture, it seems the deck handles signal acquisition, LFSR decoding, and base station identification, but the actual geometric position is resolved entirely inside the F405. Is this correct, or does the deck do any spatial pre-processing before handing off to the flight controller?

3. Benefits of the Sweeping Beam Kalman Measurement Model
   We have been studying your documentation on the Lighthouse Kalman Measurement Model. In our initial tests, we considered calculating a 3D position using geometric triangulation (like the crossing beam method) and simply feeding that (X, Y, Z) position into the EKF.

However, your EKF directly ingests each individual light plane (sweep) as a separate measurement constraint. For those who built and tuned this:

• What are the primary practical benefits of feeding the raw sweep measurements into the EKF rather than a pre-calculated 3D position?

• Does this significantly improve robustness against partial sensor occlusions (e.g., when the drone is pitched and only a few sensors see the sweep)?

• How well does this allow the system to maintain stability if only one base station is temporarily visible?

Any insights into why you chose this specific EKF architecture and how you manage the data pipeline between the two processors would be incredibly helpful as we adapt these concepts for ArduPilot!

Thanks in advance for your time and guidance.