Hi Zach, thanks for looking into this.
OpenVINS package version
voxl-open-vins-server 0.6.1 — that is the only OpenVINS-related package installed on this unit (dpkg -l | grep -i vins returns exactly one row; there is no separate open-vins library package). Still factory voxl-suite 1.6.4~beta5, never re-flashed.
Performance mode test
voxl-configure-cpu does not exist on this image, so I used voxl-set-cpu-mode perf (governor went schedutil -> performance, confirmed via /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor). Please tell me if you meant a different tool.
The result is that I could not reproduce the problem at all today — in either CPU mode.
Condition
VIO dt
voxl-mapper output
Fresh boot, schedutil, mapper off
33.3 ms
-
schedutil, mapper off, 2 min
33.3 ms (320 samples)
-
schedutil, mapper on, 2 min
33.3 ms (320 samples)
working
performance, mapper off
33.3 ms
-
performance, mapper on, 90 s
33.3 ms (240 samples)
working
performance, restart voxl-open-vins-server x5
33.3 ms every time (400 samples)
-
23 measurements, ~1,760 samples, all 33.3 ms. Not a single 15 Hz reading.
More importantly: voxl-mapper works now.
voxl-inspect-points voxl_mapper_aligned_ptcloud produces real data — ~1,900 points per cloud, roughly every 500 ms in schedutil. On 22 Sep the same pipe showed the header and zero data rows. There are no pipe_server_write_point_cloud, received NULL data pointer and no requested timestamp was too new, VIO may have stopped messages in the journal at all today. voxl-mapper CPU is now ~100% of one core, versus the 1.9% I reported — it was low then because it was not actually doing any work.
Performance mode does help the mapper, even though it did not change the VIO rate: the aligned point cloud comes out roughly every 95-190 ms instead of ~500 ms.
What this suggests about the causality
I think I had the direction backwards in my first post. The likely chain is:
OpenVINS comes up at 15 Hz -> mapper cannot match pose timestamps ("requested timestamp was too new") -> no map output
rather than "mapper is started -> VIO halves". That matches your static-jerk-throttle explanation: whatever decides the throttle is decided at VIO init, and on 22 Sep the vehicle happened to be in that state for the whole session (my very first reading that day, right after boot and before voxl-mapper had ever been started, was already 15 Hz).
Nothing was changed in between: dpkg status and voxl-open-vins-server.conf / voxl-camera-server.conf are untouched since 21 Sep. So the difference is runtime state, not configuration.
One observation that may not fit the throttle theory
Today the vehicle is completely static and features reads 0, yet VIO runs at 30 Hz. On 22 Sep it was showing features 20 and quality 97% while stuck at 15 Hz. If the throttle is permitted by a static-jerk test, I would have expected today's fully static case to be the one that throttles. Is the test based on IMU motion rather than tracked features, and is there any way to see its decision at runtime?
Remaining questions
Is there a log line, pipe field, or debug flag that shows whether the throttle is currently engaged? Right now the only way I can tell is by timing the output, and the state is invisible in state / quality / features.
Was the throttle behaviour changed after 0.6.1? If a newer voxl-open-vins-server fixes it, which SDK version should we move to?
Given it is intermittent, is it safe to treat "dt == 33.3 ms" as a pre-flight check, or is there a more reliable condition we should test before an autonomous flight?
I will keep the vehicle in performance mode and report back if the 15 Hz state shows up again, with the full journal from that boot.
Thanks,
JinHyeok
