@김진혁 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.
