Hello,
Which indoor positioning systems would you recommend for PX4-based flight-control development? I’m interested in reliable position control with straightforward setup and calibration.
What has worked well in practice? Please share the hardware, PX4 integration method, achieved accuracy, and any significant setup or calibration requirements. Comparisons between different approaches would be helpful.
Thank you.
For PX4 development I would choose the positioning system based on whether the priority is minimum setup, ground-truth quality, or self-contained flight.
For a fixed indoor development/test area, MoCap is still a strong option if infrastructure and budget are available. Vicon/OptiTrack-class systems can provide an external pose directly to the PX4 estimation pipeline and are particularly useful when you also want an independent reference for evaluating the onboard estimator.
For a vehicle that eventually needs to operate independently of external infrastructure, I would look at VIO instead. PX4 supports external-vision position/velocity fusion through EKF2, but integration quality matters as much as nominal sensor accuracy. Timestamping, coordinate frames, covariance, update rate and transport delay can all affect the resulting estimate.
For simpler low-cost indoor position hold, optical flow + a range sensor is worth considering. It has fewer integration layers than a full VIO pipeline, although it has obvious environmental/altitude limitations.
One thing I would add to the comparison criteria is temporal behaviour, not just static position accuracy.
For each system I would measure:
position error against a reference
update rate and measurement latency
timestamp jitter
dropouts / stale measurements
EKF innovation behaviour
recovery after measurement loss
estimator resets or fusion-state changes
A system reporting centimetre-level measurements is not necessarily the better PX4 positioning source if its latency or timing becomes inconsistent during motion.
If the purpose is primarily PX4 flight-control development and repeatable testing, my preference would therefore be:
MoCap for external ground truth and repeatability; VIO when autonomy without external infrastructure is part of the experiment; optical flow + rangefinder when simplicity and cost are the main constraints.
Whichever approach you choose, I would first validate it with a repeatable hover/dynamic-motion test and inspect the PX4 ULog before relying on it for more complex indoor flight.
Thanks for the explanation, especially the point about timing.
The cost of a Vicon/OptiTrack setup is a concern for us, so we’re also considering Nooploop LinkTrack (UWB) and Marvelmind (ultrasound).
Do you see any particular limitations with either approach for PX4 flight-control testing?
Both can be reasonable lower-cost options, but I would evaluate them differently from MoCap for PX4 flight-control testing.
With LinkTrack/UWB, my main concern would not be the nominal update rate but anchor geometry and position quality across the entire flight volume. UWB can work well inside a good anchor geometry, but errors can become strongly position-dependent near or outside the anchor volume, and multipath/NLOS conditions can introduce jumps or bias. I would therefore test the complete 3D workspace rather than validating accuracy at a few static points.
Marvelmind is interesting because ultrasound can provide quite good local accuracy without a camera-based MoCap installation. The trade-off is that the measurement environment is different: beacon geometry, obstruction, reflections and the dynamics of the moving vehicle still need to be tested rather than relying on the nominal accuracy figure.
For PX4 specifically, I would also decide early how you want the measurements to enter the estimator.
If either system is presented simply as GPS/NMEA, integration may be convenient, but for flight-control experiments I would want to understand what information is lost in that abstraction particularly measurement timestamp, uncertainty/covariance and validity/quality information.
If you have access to the native position output through ROS/ROS 2, feeding it as an external-position/odometry source can give you more control over timing and uncertainty, although it adds integration work.
For either system I would run the same validation before trusting it:
I would also deliberately obstruct or degrade one measurement path and see how the system and EKF recover.
So I would not choose between LinkTrack and Marvelmind from the advertised centimetre accuracy alone. For PX4 testing, consistent timing, observable measurement quality, predictable degradation and clean recovery can matter more than the best-case static accuracy.
If you already know the approximate room dimensions and whether you plan to feed the result to PX4 as NMEA/GPS or through ROS 2, we could narrow this down considerably.
Thanks for the suggestions. Our planned indoor test spaces are 20 × 10 × 2.5 m and 30 × 20 × 10 m (length × width × height).
We’re developing PX4 airship controllers and need an indoor environment for dynamics and controller testing, since outdoor testing for every development iteration is impractical. Our priority is basic, usable indoor positioning—not maximum accuracy or developing the positioning system itself.
We intend to use LinkTrack P-AS → NMEA over UART → PX4, with official firmware and configuration tools, without custom code for positioning integration.
We are still deciding what hardware to purchase, so a tested anchor layout and supported configuration for these spaces would be particularly helpful.
Thanks — that makes the use case much clearer.
Given that your goal is controller/dynamics development rather than positioning research, I think your preference for:
LinkTrack P-AS → NMEA/UART → PX4
is reasonable to evaluate first. I would keep the integration simple unless the measurements show that it is insufficient.
The two spaces are quite different, though.
For the 20 × 10 × 2.5 m space, if the airship operates over a relatively limited vertical range, a mostly planar anchor arrangement may be sufficient for horizontal positioning. However, I would be cautious about relying on that configuration for Z.
Nooploop’s own LinkTrack documentation distinguishes planar positioning from true 3D positioning. Their 3D example uses two anchor planes at different heights, which is important for vertical observability.
For the 30 × 20 × 10 m space, I would definitely treat this as a 3D geometry problem rather than simply putting four anchors at the corners.
If I were setting up the experiment, I would start with something like:
lower anchor plane
A0 — A1 — A2 — A3
upper anchor plane
A4 — A5 — A6 — A7
with the upper anchors vertically separated from the lower set and distributed around the usable flight volume.
I would not purchase the exact number/placement solely from that sketch, though. Before ordering, I would ask Nooploop to confirm a supported P-AS 3D configuration for your exact 30 × 20 × 10 m volume and expected tag location, because anchor geometry and line-of-sight will directly affect the result.
For your application, I would define success fairly pragmatically.
You probably don’t need centimetre-level ground truth. You need positioning that is:
stable enough for controller development,
continuous throughout the intended flight volume,
free from large position jumps,
predictable near the boundaries,
and able to recover cleanly after temporary measurement degradation.
Once installed, I would validate the system before autonomous flight with a simple grid test: known static locations at several X/Y positions and several heights, followed by slow trajectories through the centre, edges and corners of the volume.
Then inspect the corresponding PX4 ULog.
That will tell you much more about suitability for airship controller development than the advertised best-case accuracy alone.
One additional point: since you explicitly want NMEA/UART with official PX4 firmware, I would verify the exact NMEA sentences, update rate and serial settings produced by the P-AS configuration before purchasing. PX4 supports NMEA through its GPS driver, but confirming the complete P-AS → NMEA → PX4 path with Nooploop would remove an important integration risk.
If Nooploop can provide their recommended anchor layout for those two room dimensions, post it here before purchasing. I’d be happy to look at the geometry with you.