Hi @john-keller , Glad to hear that it works As for the other issue, its possible that this is just a transient bus error somewhere that is causing the problem. If you encounter it again it would definitely be worth taking a closer look. Feel to open another post and tag me in it and I will take a look. Thanks!

Resolving this over email. Thanks!

There's some documentation here: https://docs.px4.io/main/en/flight_modes/offboard#ros-2-offboard-control. I would review that to make sure you are following the correct procedures.

@qqa , we have document how to achieve folder-level encryption on VOXL2 here : https://docs.modalai.com/enabling-file-encryption/ . Please let us know if you have any other questions.

Sorry @senja for the delays, this post did not get flagged for me. Yes, they install on different sides of the VOXL 2 board as shown here: https://docs.modalai.com/voxl2-connectors/#connector-callouts [image: 1792693889198-9a619597-c0ad-460a-b43a-c0689c8a0aab-image.jpeg] https://docs.modalai.com/M0226/#overview [image: 1792693659205-3064b401-56ca-4e7d-973c-0fe9c3ebe5cc-image.jpeg] https://docs.modalai.com/m0062-datasheet/#connector-callouts [image: 1792693766032-bc42a15b-8021-47f4-a9b6-534603ed8399-image.jpeg]

@simiken1234 Thanks for the detailed report and logs. The images are correct. Your saved mach.var of 1.0.1 means M0054-1 hardware running the var00.1 (M0173) kernel, so the SDK 1.8.0 installer picked the right kernel and M0054(154)-1.zip is the right flat build. See VOXL 2 HW Versions. The firehose reset timeout is expected and not a problem. See the note in Flash Flat Build. A full factory flat build that still shows no USB device on a bare, cold-booted board, plus USB 3 resetting on two different hosts, points to a hardware problem on this board rather than SDK 1.8.0 or the -1 revision. Please do one more clean QDL flash of M0054(154)-1.zip over the USB 2 connection that worked. If it still does not come up as 05c6:901d, follow this section and request an RMA with the board serial (3f621d35), a link to this thread, and your support zip. Please hold off on further flash-system-image.sh or fastboot boot attempts in the meantime.

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

Hello. Can a Starling 2 drone autonomously fly while flying over the pipe inside a sewer? The drone must fly autonomously in a dark place to inspect cracks or internal conditions while flying along the water pipe. I'm not sure if this feature can run on Starling, so I'm asking for help!

Hello everyone, I am looking for some expert advice on a VOXL 2 companion computer setup for a long-range platform. I have two main integration challenges: Challenge A: VIO at Higher Altitudes To solve the motion blur and pixel density issues at higher altitudes, I am planning a 6-camera configuration. I want to use 4 downward-facing sensors (2 daylight + 2 IR) equipped with narrow-angle lenses, alongside 2 standard wide-angle sensors (front and rear). Could you advise on the best supported sensors (e.g., IMX series) for this? Has anyone successfully tuned the voxl-qvio-server for narrow-angle lenses, and what were the altitude limits you achieved? Challenge B: LAN Integration & WireGuard The payload data flow will be: External RTSP Camera -> Ethernet -> VOXL 2 (WireGuard encryption) -> Ethernet -> Digital RX. Because VOXL 2 lacks multiple LAN ports, I will need a miniature industrial Ethernet switch. Does ModalAI have any tested hardware recommendations for this? Furthermore, what is the best practice for routing this VPN traffic through the VOXL 2 Ubuntu environment without bottlenecking the CPU? We are currently evaluating the VOXL 2 for a broader fleet deployment and want to ensure the ecosystem can support this custom optics requirement. Any feedback on off-the-shelf solutions or standard configurations for this use case would be greatly appreciated. Thank you!

Hi @christopher-rajcsok We updated the VRX User Guide page with mechanical information for you. Hope it helps!! https://docs.modalai.com/vrx-ground-unit-datasheet/#enclosuremount [image: 1792436471248-dce4b444-0777-40ac-9a2a-2b58c922961f-image.jpeg]