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

[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.

[Anthony Kang]

Please send the PX4 .ulg flight log to anthony@ascendengineer.com. Thanks!

[Anthony Kang]

@김진혁 Thank you for the detailed follow-up. We replicated your setup on a Starling 2 Max (system image 1.8.08, suite 1.6.4, vision-hub 1.9.21, mapper 0.2.4, Portal 0.9.4) and tested on a bench with props off. Here are the answers.

1. The 20-segment limit

Your reading is correct. TRAJ_MAX_SEGMENTS is a constant in the hub header trajectory_interface.h. It sets the size of the packed trajectory message. It is not a configuration parameter. A change to it changes the pipe format for mapper and hub.

The check in insert_trajectory() has two defects. It counts the old segments that the insert discards. It also rejects a result of exactly 20. We wrote a patch that compares the real result (split_index + 1 + new segments) with the limit. Your 10 + 10 case now gives 11 and passes. We built mapper 0.2.4 and hub 1.9.21 with this patch. Both run on our unit. Patch and the packages will be posted later.

loco_num_segments 7 is a valid workaround. Do not use 9. The split point is 0.5 s ahead of the current position. With 9 segments, the second insert can reach 21 and fails again.

2. What fills and clears the buffer

Follow Path sends one initial local trajectory with LOAD_AND_START. Each replan trims old segments and inserts a new suffix. A failed Go adds nothing. We confirmed this: two failed Gos, then a good Go, gave the same first count.

3. Clear Paths

In Portal 0.9.4, Clear Paths only removes the drawing. Abort sends stop_following. Clear Paths does not change planner state.

4. Detection without the mapper journal

Portal shows no planner health. We will log a product request for an indicator. Until then, watch the hub journal:

journalctl -fu voxl-vision-hub | grep -E "Received (load and start|insert) command|FINISHED"

One insert line each second means that replanning reaches the drone.

Three more findings

• Mapper success lines are block-buffered under systemd. Your journal shows only the failures. Add this drop-in to see all lines live:

# /etc/systemd/system/voxl-mapper.service.d/linebuf.conf
[Service]
ExecStart=
ExecStart=/usr/bin/stdbuf -oL -eL /usr/bin/voxl-mapper

• voxl-send-command adds a newline. Mapper compares follow_path exactly, so the command never matches. plan_to works because mapper compares only the prefix. Use printf follow_path > /run/mpa/plan_msgs/control instead.
• plan_to with two coordinates makes mapper exit. Always give three coordinates.

The ground test

The error can occur on the ground. The local planner replans at 2 Hz with the vehicle stopped. Disarmed, the hub sends no progress, so the count stays at 10 + 10. Two conditions apply. The heading must be within 30 degrees of the path, or the planner only yaws. The pruned A* path must keep 10 points. On an open bench the path prunes to 3 or 4 points, so the error does not occur. Your environment gave 10 points. This is why the error is layout-dependent.

What we could not explain

Armed in offboard on the bench, the hub sent progress at 30 Hz and the mapper accepted inserts within one second. With correct progress the trim frees space. We do not know why your flight stayed at 20 for 136 s. The full mapper and hub journals and the ULog will show this. Please send them.

[Anthony Kang]

Files promised below
voxl-mapper-packages.zip