voxl-mapper local planner: "Cannot insert trajectory. Total segments = 20, Max segments = 20" — replanning never reaches the drone during Follow Path

[김진혁]

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.

[Anthony Kang]

안영하세요 진혁씨,

Apologies for the late response. We are currently configuring a Starling Max 2 to replicate your setup and will get back to you with more information by the end of this week. Thanks!

[juancho248]

Title: Starling 2 Max – GPS-Denied Autonomous Navigation Inside Rose Greenhouses

Hello ModalAI Engineering Team,

We are developing FloraVision AI, an agricultural computer vision platform for commercial rose production in Ecuador.

We are evaluating the Starling 2 Max for autonomous indoor flights inside commercial rose greenhouses.

Operating environment:

• Location: Tabacundo, Ecuador.
• Altitude: approximately 2,800–3,000 meters above sea level.
• GNSS-denied greenhouse environment.
• Metal structures, support wires, plastic roofing, and dense vegetation.
• Visually repetitive rows of rose plants.
• Requirement for repeatable image-acquisition missions above crops.

We would appreciate technical guidance on the following questions:

1. Which onboard localization and navigation capabilities are available for autonomous flight without GNSS?
2. How reliable is visual-inertial localization in repetitive greenhouse rows with limited visual features?
3. Can the platform execute predefined and repeatable trajectories without GPS?
4. What software components, SDKs, or additional development are required to implement those trajectories?
5. Which onboard sensors are used for obstacle detection and avoidance, and what limitations should we consider around thin wires, foliage, and greenhouse structures?
6. Does ModalAI have documentation or examples for autonomous indoor waypoint navigation using Starling 2 Max?
7. What safety measures and fallback behaviors are recommended if localization becomes unreliable?

We understand that application-specific development is our responsibility. We are seeking confirmation of the platform's existing capabilities, technical limitations, and recommended development resources.

Thank you for your guidance.

FloraVision AI Engineering Team
Ecuador

[juancho248]

Title: Starling 2 Max – GPS-Denied Autonomous Navigation Inside Rose Greenhouses

Hello ModalAI Engineering Team,

We are developing FloraVision AI, an agricultural computer vision platform for commercial rose production in Ecuador.

We are evaluating the Starling 2 Max for autonomous indoor flights inside commercial rose greenhouses.

Operating environment:

• Location: Tabacundo, Ecuador.
• Altitude: approximately 2,800–3,000 meters above sea level.
• GNSS-denied greenhouse environment.
• Metal structures, support wires, plastic roofing, and dense vegetation.
• Visually repetitive rows of rose plants.
• Requirement for repeatable image-acquisition missions above crops.

We would appreciate technical guidance on the following questions:

1. Which onboard localization and navigation capabilities are available for autonomous flight without GNSS?
2. How reliable is visual-inertial localization in repetitive greenhouse rows with limited visual features?
3. Can the platform execute predefined and repeatable trajectories without GPS?
4. What software components, SDKs, or additional development are required to implement those trajectories?
5. Which onboard sensors are used for obstacle detection and avoidance, and what limitations should we consider around thin wires, foliage, and greenhouse structures?
6. Does ModalAI have documentation or examples for autonomous indoor waypoint navigation using Starling 2 Max?
7. What safety measures and fallback behaviors are recommended if localization becomes unreliable?

We understand that application-specific development is our responsibility. We are seeking confirmation of the platform's existing capabilities, technical limitations, and recommended development resources.

Thank you for your guidance.

FloraVision AI Engineering Team
Ecuador

[juancho248]

Title: Starling 2 Max – GPS-Denied Autonomous Navigation Inside Rose Greenhouses

Hello ModalAI Engineering Team,

We are developing FloraVision AI, an agricultural computer vision platform for commercial rose production in Ecuador.

We are evaluating the Starling 2 Max for autonomous indoor flights inside commercial rose greenhouses.

Operating environment:

• Location: Tabacundo, Ecuador.
• Altitude: approximately 2,800–3,000 meters above sea level.
• GNSS-denied greenhouse environment.
• Metal structures, support wires, plastic roofing, and dense vegetation.
• Visually repetitive rows of rose plants.
• Requirement for repeatable image-acquisition missions above crops.

We would appreciate technical guidance on the following questions:

1. Which onboard localization and navigation capabilities are available for autonomous flight without GNSS?
2. How reliable is visual-inertial localization in repetitive greenhouse rows with limited visual features?
3. Can the platform execute predefined and repeatable trajectories without GPS?
4. What software components, SDKs, or additional development are required to implement those trajectories?
5. Which onboard sensors are used for obstacle detection and avoidance, and what limitations should we consider around thin wires, foliage, and greenhouse structures?
6. Does ModalAI have documentation or examples for autonomous indoor waypoint navigation using Starling 2 Max?
7. What safety measures and fallback behaviors are recommended if localization becomes unreliable?

We understand that application-specific development is our responsibility. We are seeking confirmation of the platform's existing capabilities, technical limitations, and recommended development resources.

Thank you for your guidance.

FloraVision AI Engineering Team
Ecuador

[Anthony Kang]

Could you send the output of voxl-version? The .ulg from the PX4 flight and the full mapper journal would also be helpful.

[wilkinsaf]

@juancho248

Hello,

1. Which onboard localization and navigation capabilities are available for autonomous flight without GNSS? -> The starling 2 max uses openvins for localization, and we would encourage you to use april tag relocalization in order to navigate around indoor environments as openvins can drift over time.
2. How reliable is visual-inertial localization in repetitive greenhouse rows with limited visual features? -> This is tough to be deterministic BUT, cant expect 2% error over distance. Greenhouse rows reminds us of the SAVLoc from Micheal Baldwin (presented at the PX4 dev summit): https://www.youtube.com/watch?v=9wk9_TNN1DA. This is not something that is present natively on the VOXL but presents an interesting localization technique indoors that you can utilize.
3. Can the platform execute predefined and repeatable trajectories without GPS? -> yes, but again we would recommend utilizing the april tags for relocalization as there is some error over distance. you can also utilize mavsdk in order to put the drone in offboard mode and control trajectories. You can find that documentation here: https://docs.modalai.com/mavsdk/
4. What software components, SDKs, or additional development are required to implement those trajectories? -> refer to answer in last question
5. Which onboard sensors are used for obstacle detection and avoidance, and what limitations should we consider around thin wires, foliage, and greenhouse structures? -> TOF module as well as tflite and opencv for computer vision. There is a collision prevention module inside PX4 that will prevent the drone from flying into something in position flight mode. You obviously have already used voxl-mapper. Anything higher level you can program in yourself in our ROS 2 plugin
6. Does ModalAI have documentation or examples for autonomous indoor waypoint navigation using Starling 2 Max? -> currently mainly the voxl-mapper. There are some custom projects that Ascend Engineering has worked on to do this
7. What safety measures and fallback behaviors are recommended if localization becomes unreliable? -> Would recommend flying in a netted & controlled area that is separate from humans. Also, have a remote control that you can switch back into manual control in order to take manual control of the drone if you feel localization is becoming unstable

[김진혁]

@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

1. 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?
2. What normally fills and clears the segment buffer? We now believe a failed Go leaves nothing behind — can you confirm?
3. Is Clear Paths related to this state at all, or is it only for the drawn paths?
4. 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.