@anthony-kang Thank you for configuring a unit to replicate this. Before you spend more time on it, here is what we found in the public source after our first post, plus the materials you asked for. Two things in our original post turned out to be wrong, and I am correcting them here so the reproduction is not built on them.
(Note: this topic now also carries an unrelated question from another user, so our four questions are restated at the end.)
1. Root cause — found in the public source (2026-10-15)
The limit does not live in voxl-mapper. It is in voxl-vision-hub (confirmed with dpkg -S on our airframe, 1.9.21):
// /usr/include/voxl_trajectory/trajectory_interface.h:48
#define TRAJ_MAX_SEGMENTS 20
// /usr/include/voxl_trajectory/trajectory_utils.h:34 <-- the rejection
if (dst->n_segments + src->n_segments >= TRAJ_MAX_SEGMENTS)
The number 20 is twice the configured value. loco_num_segments (default 10) is used identically by the global planner (planner_utils.cc:26) and the local planner (local_a_star.cc:138, as min(setting, number of A* path points)). When the path is long enough for both to reach the configured count, insertion is rejected at 10 + 10 = 20. With a short path there are fewer segments, which is why this does not fail on every flight.
Two details that make it stricter than it looks:
The actual length after insertion is segment_idx + 1 + src->n_segments (everything after the split point is discarded), but the check uses dst + src. With dst at 10 and a split point at index 3, 13 slots would be enough, yet it is rejected at 20.
The comparison is >=, which costs one more slot.
The same code is present in vision-hub v1.10.3 and on master, so upgrading the package does not change this (as of 2026-10-15).
Our mitigation: loco_num_segments 10 -> 7 in /etc/modalai/voxl-mapper.conf (7 + 7 = 14, below the limit). This needs no rebuild. It is not yet flight-verified — our next flight will tell. If there is a reason not to lower this value (shorter planning horizon, replan frequency, anything we are not seeing), please say so.
2. Corrections to our first post
Retracted: "a failed Go leaves segments allocated". We suspected the two failed Go commands before the successful one had filled the buffer. The arithmetic above explains the failure without any leftover state, so we no longer believe the buffer was pre-filled.
Retracted: "we will test whether pressing Clear Paths first avoids it". That test does not address this condition. Please do not build the reproduction around it.
3. Why we cannot verify this on the ground (it is structural)
We tried on 2026-10-15 and got as far as Immediate collision free path found!, then stopped. Two reasons:
insert_trajectory is only reached on replanning. The first trajectory goes out as TRAJ_CMD_LOAD_AND_START, which does not pass the check, and replanning requires the vehicle to advance so that the split point moves. Stationary, it never happens.
Even the initial trajectory stops at the rotation branch (local_a_star.cc:327 if the heading differs from the path direction by more than 30 degrees, the planner only yaws in place and sends no trajectory. Disarmed, the vehicle never rotates, so the angle never closes.
So Max segments = 20 is a condition that only appears in flight, and the absence of the error on the ground means nothing.
Two things that cost us time and may help your setup:
voxl-send-command plan_msgs follow_path prints success but mapper does not act on it. We used it when the Portal click was blocked, and got Successfully sent command to /run/mpa/plan_msgs/control — but the handler's first line (Client requested to follow last path) never appeared. Portal does not use that pipe; it sends over a WebSocket (/data/web_root/js/mapper.js:980, plan_ws.send("follow_path")).
Failure logs are fprintf(stderr, ...) and appear immediately; the success path (Sending trajectory to plan channel) is printf and is block-buffered, so it stays invisible during flight. We flush it after landing with systemctl restart voxl-mapper. Anyone judging from the journal in flight sees only failures, never successes.
4. The materials you asked for
voxl-version — full output below. Please note it was captured on 2026-09-15, as shipped, before voxl-mapper was installed, so the package list does not contain it. Versions in use on the 2026-10-13 flight were: system-image 1.8.08-M0054-14.1a-perf, voxl-suite 1.6.4~beta5, voxl-vision-hub 1.9.21, voxl-mapper 0.2.4. We will post a fresh voxl-version from the airframe at our next session.
voxl2:/$ voxl-version
────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.08-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Thu May 14 22:41:15 UTC 2026 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform: M0054
mach.var: 1.0.1
SKU: MRB-D0012-4-V4-C29-T8-M36
────────────────────────────────────────────────────────────────────────────────
voxl-suite: 1.6.4~beta5
────────────────────────────────────────────────────────────────────────────────
Packages:
Repo: http://voxl-packages.modalai.com/ ./dists/qrb5165/sdk-1.6/binary-arm64/
Last Updated: 2023-03-02 12:58:41
WARNING: repo file has changed since last update,
packages may have originated from a different repo
List:
libfc-sensor 1.0.12
libmodal-cv 0.6.1
libmodal-exposure 0.1.5
libmodal-flow 1.0.4
libmodal-journal 0.2.7
libmodal-json 0.4.8
libmodal-pipe 2.14.12
libqrb5165-io 0.6.3
libvoxl-cci-direct 0.4.0
libvoxl-codec 0.0.5
libvoxl-cutils 0.1.6
modalai-slpi 1.2.3
mv-voxl 0.1-r0
qrb5165-bind 0.1-r0
qrb5165-dfs-server 0.2.0
qrb5165-mini-tof-server 0.2.2
qrb5165-rangefinder-server 0.1.6
qrb5165-slpi-test-sig 01-r0
qrb5165-tflite 2.17.2
voxl-camera-calibration 0.6.2
voxl-camera-server 2.2.23
voxl-ceres-solver 2:2.0.0-2
voxl-configurator 1.1.21
voxl-cpu-monitor 0.7.7
voxl-docker-support 1.3.1
voxl-elrs 1.1.6
voxl-esc 1.6.3
voxl-esptool 0.2.1
voxl-feature-tracker 0.5.2
voxl-flow-server 0.3.6
voxl-focus-camera 0.6.1
voxl-gphoto2-server 0.0.10
voxl-imu-server 2.0.2
voxl-io-server 0.1.1
voxl-jpeg-turbo 2.1.3-7
voxl-lepton-server 1.4.0
voxl-lepton-tracker 0.0.4
voxl-libgeographic 1.0.0
voxl-libgphoto2 0.0.4
voxl-libuvc 1.0.7
voxl-logger 0.6.3
voxl-mavcam-manager 0.6.1
voxl-mavlink 0.1.6
voxl-mavlink-server 1.4.16
voxl-modem 1.2.4
voxl-mongoose 7.19.0-1
voxl-mpa-to-ros 0.3.9
voxl-mpa-tools 1.5.8
voxl-nano-tracker 0.1.7
voxl-open-vins-server 0.6.1
voxl-opencv 4.5.5-3
voxl-osd 0.4.7
voxl-portal 0.9.4
voxl-px4 1.14.0-2.0.142
voxl-px4-params 0.9.9
voxl-qvio-server 1.2.3
voxl-remote-id 0.0.9
voxl-reset-slpi 0.0.4
voxl-state-estimator 0.0.6
voxl-streamer 0.8.1
voxl-suite 1.6.4~beta5
voxl-tag-detector 0.1.0
voxl-tflite-server 0.5.1
voxl-utils 2.0.4
voxl-uvc-server 0.1.8
voxl-vision-hub 1.9.21
voxl-vtx 2.2.19
voxl-wavemux 0.0.3
voxl2-io 0.0.3
voxl2-security-hardening-utls 1.0-r0
voxl2-system-image 1.8.08-r0
voxl2-wlan 1.0-r0
────────────────────────────────────────────────────────────────────────────────
Full mapper journal — the excerpt in the first post is what we have off-airframe right now; we will collect the full journal at the next session and post it here.
PX4 .ulg — we have it (log100, 69 MB), but it exceeds the forum's 8 MB attachment limit. We would rather not put it on logs.px4.io, since that is a public upload and the log carries our flight environment. Could you give us a private channel for it — an email address, or should we send it through the contact form on modalai.com? If a public upload is fine with you, tell us and we will do that instead.
5. Our four questions, restated
Does our reading match yours — TRAJ_MAX_SEGMENTS 20 is a fixed limit in the trajectory interface, and lowering loco_num_segments is the intended way around it? Is there any plan to compare against the actual post-insert length (segment_idx + 1 + src->n_segments) instead of dst + src?
What normally fills and clears the segment buffer? We now believe a failed Go leaves nothing behind — can you confirm?
Is Clear Paths related to this state at all, or is it only for the drawn paths?
Is there a way for an operator to detect this condition without reading the mapper journal? From the Portal UI everything looked correct — the path was drawn and Immediate collision free path found! was reported — so the pilot has no indication that obstacle avoidance is not active. We would treat a Portal-visible indication as a product request.
Thanks again.
