ModalAI Forum

Files promised below
voxl-mapper-packages.zip

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

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

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

안영하세요 진혁씨,

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!

Hello ModalAI team,

I am currently working on optimizing my video pipeline for a low-latency, bandwidth-constrained radio link. To eliminate the massive bandwidth spikes caused by periodic IDR frames, I am implementing Gradual Decoder Refresh (Periodic Intra Refresh) by modifying voxl-camera-server.

Here is my current hardware setup:

• Compute: VOXL2 (QRB5165)

• Image Sensor: IMX412

• Target Stream: Small video stream (H.265 / CBR) while adjusting bitrate dynamically via int OMXVideoEncoder::SetTargetBitrate(uint32_t bps)

I am planning editing src/venc/OMX.cpp and setting the following parameter: OMX_IndexParamVideoIntraRefresh. Before starting implementation, I had questions about the approach and tuning parameters.

def struct OMX_VIDEO_PARAM_INTRAREFRESHTYPE {
 OMX_U32 nSize;
 OMX_VERSIONTYPE nVersion;
 OMX_U32 nPortIndex;
 OMX_VIDEO_INTRAREFRESHTYPE eRefreshMode;
 OMX_U32 nAirMBs;
 OMX_U32 nAirRef;
 OMX_U32 nCirMBs;
} OMX_VIDEO_PARAM_INTRAREFRESHTYPE; 

• Cyclical vs. Adaptive vs. Hybrid: According to "The OpenMAX Integration Layer Specification", the QRB5165 supports three different modes for periodic intra refresh. Cyclical keeps a steady bitrate, adaptive can handle rapid motion, and hybrid combines these two approaches. Ideally, the hybrid seems like the best use case for drone FPV but adds a layer of implementation complexity. Which mode would you recommend?

• Param Tuning: What is the suggested approach to tuning nAirMBs, nAirRef, and nCirMBs experimentally? Do you already have a set of recommended values?

• Should nCirMBs scale linearly with the target bitrate when the dynamic bitrate path adjusts mbps at runtime? And for H.265, is the MB count interpreted at 16×16 MB granularity or translated internally to 32×32/64×64 CTUs?

• Configuration Conflicts: Are there any known conflicts between setting OMX_IndexParamVideoIntraRefresh and the other default QMMF parameters (like the dynamic bitrate updates) currently set in OMX.cpp?

• Firmware/HAL quirks: Are there any specific "gotchas" or undocumented requirements for the QCOM Media HAL on the VOXL2 when using periodic intra refresh?

Any advice on tuning these parameters for the QRB5165 would be highly appreciated.

Thank you!