ModalAI Forum

We flew our first mapper-based path flight on a Starling 2 Max and the drone did follow the planned path. However, the local planner was unable to deliver a single trajectory for the entire flight, so the drone was flying on the one path computed before departure, with no replanning.

What happened

Global planning succeeded:

05:13:38  Client requested plan to location
05:13:38  Using start pose of: x: 1.67, y: -0.80, z: -1.46
05:13:38  Using goal pose of:  x: 5.16, y: -1.34, z: -0.89
05:13:38  Starting RRTConnect planner
05:13:38  Immediate collision free path found!

Then, from the instant we pressed Follow Path, this repeated continuously for 2 min 16 s until we took manual control:

05:14:10  Client requested to follow last path
05:14:10  Local Planner failed to send trajectory
05:14:10  ERROR: Cannot insert trajectory. Total segments = 20, Max segments = 20
...       (repeats at roughly 1-2 s intervals through 05:16:26)

Throughout those 2 min 16 s the planner itself was running normally — A* took = 0.07-0.14 ms for 13 iterations and Smoother took = 6-12 ms were interleaved with every failure. So it computes a trajectory and then cannot insert it.

The drone moved 2.68 m straight-line / 8.79 m total path at up to 1.04 m/s, which matches the pre-computed path. It stopped 0.81 m short of the goal only because the pilot intervened.

What we ruled out

1. Not a planning failure — the global path was found and reported collision-free.
2. Not a VIO problem — dt held at 33.3 ms for all 44 samples in flight, features 15-30, cs_ev_pos / cs_ev_yaw / cs_ev_hgt all True.
3. Not a map problem — voxl_mapper_aligned_ptcloud was producing 1,489-2,925 points at ~10 Hz before and during the flight.
4. Not CPU load — load average dropped from 7.75 on the ground to 4.5 in flight; governor was performance.
5. Not thermal throttling — 94-96 C, but scaling_cur_freq equalled cpuinfo_max_freq on all cores and dmesg showed no throttle events.
6. Not a config we changed — voxl-mapper.conf is stock; loco_num_segments is 10.

What we could not find

The limit of 20 does not appear in voxl-mapper.conf. loco_num_segments is 10, which is not the number in the error. We could not locate a setting that exposes Max segments.

One thing we suspect, but have not tested

Before the successful Go, we had two failed ones — both rejected with ERROR: End point is in collision because the goal came in at z: 0.00 (we were clicking in the 2D view, which puts the point at ground level). The Max segments = 20 error appeared immediately on the first Follow Path, which makes us wonder whether failed plans leave segments behind. We have not yet tested whether pressing Clear Paths first avoids it.

Questions

1. Where is the 20-segment limit set, and is it configurable?
2. What normally fills the segment buffer, and what clears it? Does a failed Go leave segments allocated?
3. Is Clear Paths the correct way to reset this state before Follow Path?
4. Is there a way to detect this condition other than reading the mapper journal? From the Portal UI everything looked correct — the path was drawn and Immediate collision free path found! was reported — so an operator has no indication that obstacle avoidance is not active.

Environment

• Hardware: Starling 2 Max, SKU MRB-D0012-4-V4-C29-T8-M36
• voxl-version: system-image 1.8.08-M0054-14.1a-perf, voxl-suite 1.6.4~beta5
• voxl-mapper 0.2.4, voxl-vision-hub with offboard_mode: "trajectory"
• Services active at the time: voxl-vision-hub, voxl-open-vins-server, voxl-mapper, voxl-px4, voxl-portal

We have the full mapper journal and the PX4 .ulg from this flight and can share either.

Zach, as promised, here is the follow-up on the 15 Hz state. It showed up again on 8 Oct and 13 Oct. Two corrections to what we reported in September come first, because both of them change the picture.

Correction 1 — "it only recovers via restart" was wrong.

In September we reported that stopping voxl-mapper never restored 30 Hz and that only systemctl restart voxl-open-vins-server brought it back (3 reproductions). That conclusion was an artifact of our own method: all three times we restarted the service, so we never observed what happens if we just wait. On 8 Oct the unit went from a fully stuck state (dt 66.7 ms x 100 %, zero 33.3 samples) back to 33.3 ms on its own in about 5 minutes, with systemctl show voxl-open-vins-server reporting NRestarts=0 and an unchanged ActiveEnterTimestamp. The service was never restarted.

Correction 2 — the "mapper produces zero rows" symptom was our own sequencing error.

We reported in September that voxl_mapper_aligned_ptcloud output nothing while VIO ran at 15 Hz. The real cause: restarting voxl-open-vins-server leaves voxl-mapper reporting active while its mapping function is dead. systemctl is-active still says active; only the empty point-cloud pipe reveals it. A single systemctl restart voxl-mapper restores it.

On 8 Oct we measured the two states side by side — fully stuck VIO with a healthy map (1,473-1,675 points, ~10 Hz), and healthy 33.3 ms VIO with zero map rows right after a VIO restart. So dt and map output are independent, and our September report conflated them. Sorry for the noise that caused.

New observation — the stuck state clears the moment the drone takes off.

This is the part we think is most useful to you. On 13 Oct the unit sat fully stuck on the ground for 5 minutes (66.7 ms x 100 %, NRestarts=0, no self-recovery this time). It returned to 33.3 ms within one sample of takeoff and stayed there for the entire flight (44 samples, all 33.3). Feature count also rose from 19 on the ground to 30 in the air.

14:07:59   dt 66.7   features 17   quality 57%   on ground
14:08:07   dt 33.3   features 30   quality 75%   takeoff
14:08:16+  dt 33.3   features 15-30             entire flight

Related: on the ground at rest, VIO publishes blank packets that look healthy.

Before takeoff we saw 480 consecutive samples with features 0 and T_imu_wrt_vio frozen to two decimals, while dt read 33.3, quality read 96 % and error_codes was empty. The journal explains it: [HEALTH] Publishing blank VIO packet due to missing sensors. Moving the airframe by hand for ~10 seconds started tracking immediately (features 11-30). So on a stationary unit, dt and quality are not evidence that VIO is estimating anything.

Our working hypothesis, which matches yours.

Across 8 Oct and 13 Oct, all three stuck states began immediately after we picked the drone up and walked with it. Periods where the unit sat still ran at 33.3 ms. That is consistent with the static-jerk-throttle mechanism you described: the throttle is a releasable state, hand motion during initialization keeps re-creating the condition, and sustained flight motion clears it.

Questions, if you have a moment:

1. Does "clears on takeoff, never clears while stationary on the ground" fit the static jerk throttle as you understand it?
2. Is the blank-packet behaviour on a stationary unit expected — i.e. is features 0 with a healthy-looking dt/quality the normal pre-initialization output?

Environment unchanged: voxl-suite 1.6.4~beta5, system-image 1.8.08-M0054-14.1a-perf, SKU MRB-D0012-4-V4-C29-T8-M36, voxl-mapper 0.2.4. We are still holding the unit at factory SDK as the baseline for these comparisons. Journals from both boots are available if useful.

Thanks Zach — that answers what we needed.

We will pick up the newer OpenVINS build separately — we are holding this unit at factory voxl-suite 1.6.4~beta5 for now, since it is the baseline our 22 Sep / 28 Sep comparison rests on. If the 15 Hz state shows up again before then, I will post the journal from that boot here.

Thanks again for digging into it — the static-jerk-throttle explanation was the piece we could not have found on our own.

JinHyeok

Hi Zach, thanks for looking into this.

OpenVINS package version

voxl-open-vins-server 0.6.1 — that is the only OpenVINS-related package installed on this unit (dpkg -l | grep -i vins returns exactly one row; there is no separate open-vins library package). Still factory voxl-suite 1.6.4~beta5, never re-flashed.

Performance mode test

voxl-configure-cpu does not exist on this image, so I used voxl-set-cpu-mode perf (governor went schedutil -> performance, confirmed via /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor). Please tell me if you meant a different tool.

The result is that I could not reproduce the problem at all today — in either CPU mode.

Condition	VIO dt	voxl-mapper output
Fresh boot, schedutil, mapper off	33.3 ms	-
schedutil, mapper off, 2 min	33.3 ms (320 samples)	-
schedutil, mapper on, 2 min	33.3 ms (320 samples)	working
performance, mapper off	33.3 ms	-
performance, mapper on, 90 s	33.3 ms (240 samples)	working
performance, restart voxl-open-vins-server x5	33.3 ms every time (400 samples)	-

23 measurements, ~1,760 samples, all 33.3 ms. Not a single 15 Hz reading.

More importantly: voxl-mapper works now.

voxl-inspect-points voxl_mapper_aligned_ptcloud produces real data — ~1,900 points per cloud, roughly every 500 ms in schedutil. On 22 Sep the same pipe showed the header and zero data rows. There are no pipe_server_write_point_cloud, received NULL data pointer and no requested timestamp was too new, VIO may have stopped messages in the journal at all today. voxl-mapper CPU is now ~100% of one core, versus the 1.9% I reported — it was low then because it was not actually doing any work.

Performance mode does help the mapper, even though it did not change the VIO rate: the aligned point cloud comes out roughly every 95-190 ms instead of ~500 ms.

What this suggests about the causality

I think I had the direction backwards in my first post. The likely chain is:

OpenVINS comes up at 15 Hz -> mapper cannot match pose timestamps ("requested timestamp was too new") -> no map output

rather than "mapper is started -> VIO halves". That matches your static-jerk-throttle explanation: whatever decides the throttle is decided at VIO init, and on 22 Sep the vehicle happened to be in that state for the whole session (my very first reading that day, right after boot and before voxl-mapper had ever been started, was already 15 Hz).

Nothing was changed in between: dpkg status and voxl-open-vins-server.conf / voxl-camera-server.conf are untouched since 21 Sep. So the difference is runtime state, not configuration.

One observation that may not fit the throttle theory

Today the vehicle is completely static and features reads 0, yet VIO runs at 30 Hz. On 22 Sep it was showing features 20 and quality 97% while stuck at 15 Hz. If the throttle is permitted by a static-jerk test, I would have expected today's fully static case to be the one that throttles. Is the test based on IMU motion rather than tracked features, and is there any way to see its decision at runtime?

Remaining questions

1. Is there a log line, pipe field, or debug flag that shows whether the throttle is currently engaged? Right now the only way I can tell is by timing the output, and the state is invisible in state / quality / features.
2. Was the throttle behaviour changed after 0.6.1? If a newer voxl-open-vins-server fixes it, which SDK version should we move to?
3. Given it is intermittent, is it safe to treat "dt == 33.3 ms" as a pre-flight check, or is there a more reliable condition we should test before an autonomous flight?

I will keep the vehicle in performance mode and report back if the 15 Hz state shows up again, with the full journal from that boot.

Thanks,
JinHyeok

Hardware: Starling 2 Max, SKU MRB-D0012-4-V4-C29-T8-M36, hw platform M0054 (C29 config with PMD ToF). Received 14 Sep 2026, factory state.

Software version: (voxl-version)

• system-image 1.8.08-M0054-14.1a-perf, kernel 4.19.125
• voxl-suite 1.6.4~beta5 (factory; SDK not re-flashed)
• voxl-mapper 0.2.4, voxl-voxblox 1.1.5, voxl-nlopt 2.5.0-5 (installed via apt)

Configuration / services: (voxl-inspect-services)

• Running: voxl-camera-server, voxl-imu-server, voxl-open-vins-server, voxl-px4, voxl-vision-hub, voxl-mavlink-server, voxl-rangefinder-server, voxl-portal, voxl-streamer, voxl-mavcam-manager, voxl-cpu-monitor
• voxl-qvio-server: disabled. voxl-mapper: started manually for these tests, otherwise disabled.
• OpenVINS config: use_stereo false, max_cameras 2, track_frequency 30.0, imu_body_frame_mode true
• voxl-mapper.conf: defaults (voxel_size 0.1, esdf_max_distance 2, robot_radius 0.35, tof_0_rate 10, tof pipe /run/mpa/tof enabled, stereo depth pipes disabled)

What I am trying to do:
Build a map with voxl-mapper so we can move on to trajectory/planning based autonomy. VIO and manual autonomy already work on this airframe: on the same day we flew a manual Position-mode flight and an OFFBOARD figure_eight flight, and EKF fused vision at 99-100% (cs_ev_pos / cs_ev_hgt / cs_ev_vel / cs_ev_yaw) with 0.14 m horizontal drift over 20 s of stick-neutral hover.

What actually happens:
voxl-mapper starts and connects, but never produces any map output — and starting it also halves the VIO rate, which then does not recover when voxl-mapper is stopped.

1. With voxl-mapper stopped, voxl-inspect-vio reports dt = 33.3 ms (30 Hz).
2. Starting voxl-mapper drops it to 66.7 ms (15 Hz), with almost no jitter (spread ~0.1 ms). The raw ov pipe reads 15 Hz too, so this is not a voxl-vision-hub stage.
3. Stopping voxl-mapper does not restore 30 Hz. At that moment feature count (20) and quality (97%) are normal, so it is not feature starvation.
4. systemctl restart voxl-open-vins-server restores 30 Hz every time (reproduced 3x).
5. Running voxl-mapper in the foreground, initialisation completes normally:

Loading our own config file
Loading extrinsics config file
Trying to init tsdf server
created tsdf server
Connected to VIO server
Initializing ESDF structs
Connected to depth pipe
ESDF Thread is now locked to the following cores: 4 5 6

and then it repeats, indefinitely:

WARNING the requested timestamp was too new, VIO may have stopped
ERROR in pipe_server_write_point_cloud, received NULL data pointer

6. voxl-inspect-points voxl_mapper_aligned_ptcloud shows the header only, no data rows, while the ToF input pipe tof_pc is healthy at 43,200 points.

Note: "VIO may have stopped" looks like a misdiagnosis — VIO is running the whole time, just at half rate.

What we ruled out (all measured on the vehicle):

• CPU load: voxl-mapper uses 1.9-5.7% CPU, the system is ~72% idle (8 cores), and no other service rises when it starts.
• Config drift: voxl-camera-server.conf and voxl-open-vins-server.conf are byte-identical to a snapshot taken before voxl-mapper was installed.
• Camera input: tracking_front is a steady 30.0 fps (exposure ~7.4 ms); the processed pipes (misp_grey, misp_norm) are also 30 fps. So input is 30 Hz while only the OpenVINS output is halved.
• Clock mismatch: VIO and ToF timestamps share the same monotonic base. Sampled simultaneously they differ by ~137 ms (VIO 2841.870 s, ToF 2841.733 s).
• Extrinsics: body -> tof is defined in extrinsics.conf and voxl-mapper logs no extrinsics error.
• Subscriber count: two simultaneous voxl-inspect-vio clients do not change the rate (still 30 Hz).

Steps to reproduce:

1. systemctl restart voxl-open-vins-server, wait ~30 s, confirm voxl-inspect-vio shows 33.3 ms.
2. systemctl start voxl-mapper.
3. voxl-inspect-vio now shows 66.7 ms.
4. systemctl stop voxl-mapper — still 66.7 ms.
5. systemctl restart voxl-open-vins-server — back to 33.3 ms.

Questions:

1. Is there a known condition under which voxl-open-vins-server latches to half its configured rate and does not return until restarted?
2. Is a rate change expected when another process subscribes to the VIO pipe?
3. Is the "requested timestamp was too new" failure a consequence of the 15 Hz rate, or an independent problem? If we could hold 30 Hz, would voxl-mapper work?
4. Is there a supported way to detect or recover this state without restarting voxl-open-vins-server?

Logs / pictures: Happy to provide the full system snapshot (voxl-version, voxl-inspect-services, full PX4 parameter dump) and the .ulg flight logs on request.

@alex-kushleyev @eric-katzfey Apologies for the direct mention — I hope you don't mind.

I posted this question set about two weeks ago (and a related product question three weeks ago), but haven't heard back yet. We are preparing to purchase a Starling 2 Max (C29, with the PMD ToF) as an evaluation unit for an indoor GPS-denied inspection project, and just three answers would unblock our decision:

1. Can VOXL SLAM / VOA (with the dense PMD ToF on the C29 configuration) reliably handle very narrow corridors — around 300 mm width? Any references to pipe/industrial inspection use cases in similar tight spaces would be very helpful.
2. For repeated missions in the same indoor space, is voxl-mapper + AprilTag re-localization the recommended pattern to bound Open-VINS drift (no loop closure)?
3. What is the practical minimum illumination for reliable VIO with the tracking cameras — and do you recommend onboard IR/LED illumination for dim industrial interiors?

Even brief pointers to relevant docs would be greatly appreciated. Thank you for the great platform and documentation!

Hi ModalAI team,

Reposting here under VOXL Dev Kits (also asked in the VOXL Flight Deck sub-forum). A few technical questions for our indoor GPS-denied inspection PoC — a compact custom quadcopter (X4) airframe built around the VOXL 2 Mini.

[SLAM / autonomy]

• VOA performance in narrow (~300 mm) corridors — any pipe / industrial refs?
• Open-VINS is pure VIO (no loop closure) — for repeated long flights, is Mapper + AprilTag re-localization enough to bound drift?

[Precision landing]

• voxl-vision-hub provides AprilTag relocalization but notes it "does not yet support autonomous takeoff and landing." Is a fully automated AprilTag precision landing onto a charging dock achievable using the VOXL SDK alone (voxl-tag-detector / voxl-vision-hub + PX4 precision-land), without us writing our own landing logic? If so, what is the recommended setup? If some part still needs custom development, which part?

[Cameras / sensors]

• VOXL 2 Mini has 4 MIPI-CSI. Using 2 for VIO + 1 downward for precision landing = 3. Can a 4th camera (gimbal / thermal) be added, and how?
• For the downward precision-landing camera, is MSU-M0166 (AR0144 micro-coax) the right choice? Can that downward AR0144 be shared by both VIO and the voxl-tag-detector (AprilTag) at the same time?
• Recommended ToF module for collision avoidance?

[Airframe / drivetrain]

• Is VOXL ESC Mini (M0129) compatible with our own motor selection (DShot/PWM) in a standard quadcopter (X4) configuration?
• Any thermal / layout guidance for integrating VOXL 2 Mini + ESC Mini into a custom ducted-cage airframe?

[Mission / comms]

• Vision Hub: can an external host (our charging station) send trajectories and trigger auto takeoff / landing?
• WiFi 2.4 GHz stability indoors — recommended radio module?

Note: We don't have hardware yet (pre-purchase), so voxl-version / voxl-inspect-services / PX4 logs are not available at this stage.

Thanks!
JinHyeok Kim, Pablo Air

Gentle bump — it's been 5 days and this thread is still open with no reply. Would really appreciate any input from the ModalAI engineering team on the questions above (VOA/SLAM in narrow ~300 mm corridors, fully automated AprilTag precision landing via the VOXL SDK alone, and sharing the downward AR0144 between VIO and voxl-tag-detector). Even partial pointers would help a lot — we're evaluating the VOXL 2 Mini for a PoC and are ready to buy an evaluation unit. Thanks!

Hi ModalAI team,

We were directed here from the sales channel. A few technical questions for our indoor GPS-denied inspection PoC — a compact custom quadcopter (X4) airframe built around the VOXL 2 Mini.

[SLAM / autonomy]

• VOA performance in narrow (~300 mm) corridors — any pipe / industrial refs?
• Open-VINS is pure VIO (no loop closure) — for repeated long flights, is Mapper + AprilTag re-localization enough to bound drift?

[Precision landing]

• voxl-vision-hub provides AprilTag relocalization but notes it "does not yet support autonomous takeoff and landing." Is a fully automated AprilTag precision landing onto a charging dock achievable using the VOXL SDK alone (voxl-tag-detector / voxl-vision-hub + PX4 precision-land), without us writing our own landing logic? If so, what is the recommended setup? If some part still needs custom development, which part?

[Cameras / sensors]

• VOXL 2 Mini has 4 MIPI-CSI. Using 2 for VIO + 1 downward for precision landing = 3. Can a 4th camera (gimbal / thermal) be added, and how?
• For the downward precision-landing camera, is MSU-M0166 (AR0144 micro-coax) the right choice? Can that downward AR0144 be shared by both VIO and the voxl-tag-detector (AprilTag) at the same time?
• Recommended ToF module for collision avoidance?

[Airframe / drivetrain]

• Is VOXL ESC Mini (M0129) compatible with our own motor selection (DShot/PWM) in a standard quadcopter (X4) configuration?
• Any thermal / layout guidance for integrating VOXL 2 Mini + ESC Mini into a custom ducted-cage airframe?

[Mission / comms]

• Vision Hub: can an external host (our charging station) send trajectories and trigger auto takeoff / landing?
• WiFi 2.4 GHz stability indoors — recommended radio module?

Note: We don't have hardware yet (pre-purchase), so voxl-version / voxl-inspect-services / PX4 logs are not available at this stage.

Thanks!
JinHyeok Kim, Pablo Air

Hi team — just bumping this in case it slipped through. We're ready to buy one evaluation unit and would really appreciate a quick steer: can the Stinger Vision FPV run AUTONOMOUS VIO/SLAM + AprilTag precision landing, or would Starling 2 / Starling 2 Max be the better evaluation platform for the requirements above? I've also emailed sales@modalai.com in parallel, so whichever channel is easier works for us. Thanks!

Hi ModalAI team,

We're building a compact indoor autonomous inspection drone (PoC) and want to
buy ONE evaluation unit before designing our own airframe around the VOXL 2 Mini.
Could you recommend the best-fit product?

Application: GPS-denied indoor flight through ~300 mm corridors, with AprilTag
precision landing onto a self-charging dock.

Key requirements:

• Size <= 200 x 200 mm (300 mm corridors), weight <= 600 g
• Ducted / caged frame (4-motor prop protection)
• VOXL 2 Mini (PX4), VIO / SLAM autonomy
• AprilTag precision landing <= 0.15 m, ToF / VOA collision avoidance
• Flight time >= 10 min, NDAA-compliant

Stinger Vision FPV looks close — is it usable for AUTONOMOUS (non-FPV) flight
with VIO/SLAM + AprilTag landing? Or is Starling 2 / Starling 2 Max a better
evaluation platform?

Also: lead time / pricing for a single unit, and any export (EAR) considerations
for shipping to South Korea.

Thanks!
JinHyeok Kim, Pablo Air