Zach, as promised, here is the follow-up on the 15 Hz state. It showed up again on 8 Oct and 13 Oct. Two corrections to what we reported in September come first, because both of them change the picture.
Correction 1 — "it only recovers via restart" was wrong.
In September we reported that stopping voxl-mapper never restored 30 Hz and that only systemctl restart voxl-open-vins-server brought it back (3 reproductions). That conclusion was an artifact of our own method: all three times we restarted the service, so we never observed what happens if we just wait. On 8 Oct the unit went from a fully stuck state (dt 66.7 ms x 100 %, zero 33.3 samples) back to 33.3 ms on its own in about 5 minutes, with systemctl show voxl-open-vins-server reporting NRestarts=0 and an unchanged ActiveEnterTimestamp. The service was never restarted.
Correction 2 — the "mapper produces zero rows" symptom was our own sequencing error.
We reported in September that voxl_mapper_aligned_ptcloud output nothing while VIO ran at 15 Hz. The real cause: restarting voxl-open-vins-server leaves voxl-mapper reporting active while its mapping function is dead. systemctl is-active still says active; only the empty point-cloud pipe reveals it. A single systemctl restart voxl-mapper restores it.
On 8 Oct we measured the two states side by side — fully stuck VIO with a healthy map (1,473-1,675 points, ~10 Hz), and healthy 33.3 ms VIO with zero map rows right after a VIO restart. So dt and map output are independent, and our September report conflated them. Sorry for the noise that caused.
New observation — the stuck state clears the moment the drone takes off.
This is the part we think is most useful to you. On 13 Oct the unit sat fully stuck on the ground for 5 minutes (66.7 ms x 100 %, NRestarts=0, no self-recovery this time). It returned to 33.3 ms within one sample of takeoff and stayed there for the entire flight (44 samples, all 33.3). Feature count also rose from 19 on the ground to 30 in the air.
14:07:59 dt 66.7 features 17 quality 57% on ground
14:08:07 dt 33.3 features 30 quality 75% takeoff
14:08:16+ dt 33.3 features 15-30 entire flight
Related: on the ground at rest, VIO publishes blank packets that look healthy.
Before takeoff we saw 480 consecutive samples with features 0 and T_imu_wrt_vio frozen to two decimals, while dt read 33.3, quality read 96 % and error_codes was empty. The journal explains it: [HEALTH] Publishing blank VIO packet due to missing sensors. Moving the airframe by hand for ~10 seconds started tracking immediately (features 11-30). So on a stationary unit, dt and quality are not evidence that VIO is estimating anything.
Our working hypothesis, which matches yours.
Across 8 Oct and 13 Oct, all three stuck states began immediately after we picked the drone up and walked with it. Periods where the unit sat still ran at 33.3 ms. That is consistent with the static-jerk-throttle mechanism you described: the throttle is a releasable state, hand motion during initialization keeps re-creating the condition, and sustained flight motion clears it.
Questions, if you have a moment:
Does "clears on takeoff, never clears while stationary on the ground" fit the static jerk throttle as you understand it?
Is the blank-packet behaviour on a stationary unit expected — i.e. is features 0 with a healthy-looking dt/quality the normal pre-initialization output?
Environment unchanged: voxl-suite 1.6.4~beta5, system-image 1.8.08-M0054-14.1a-perf, SKU MRB-D0012-4-V4-C29-T8-M36, voxl-mapper 0.2.4. We are still holding the unit at factory SDK as the baseline for these comparisons. Journals from both boots are available if useful.
