Is it possible to integrate PMD IRS2975C tof sensor used in starling max 2 (C29) to the stinger platform. I can see M0188 breakout for mini and I guess it can do the same as M0173 provided with starling2-max can you confirm it will work ? if the answer it should work I am wondering if I can find a longer flex cable to connect the PMD IRS2975C in the front of the drone.
BR,
Roy
Hi ZBFT,
Q:Do you need VIO estimates to be always continuos or reset jumps are okay?
A: we are exploting a tunnel for the first time.we use the poshold durung junction turns to hold in place during turbolance. my answer would be we can live with resets assuming we can accumulate the positions for mapping between the resets.
Q:If you need VIO during takeoff and your application is not robust to SFM resets (potential jump discontinuity), I recommend never using dynamic init and warm reset
A:We need it mostly because users with no FPV know how have hard time to keep altitude and control the drone position.
Q:Convergence for a initialization would usually refer to a dynamic initialization (nonlinear optimization), as the static initialization does not involve optimization. That being said, some static inits can be bad as soon as the platform is in the air: noisy ZUPT updates, bad IMU calibration and sigma/random-walk values. This is natural under custom frame mods, perhaps a full IMU intrinsics recalibration could help.
A:We are not using custom frame its the starling max 2
Nevertheless, it seems that you're running VIO by passing estimates to PX4, instead of using VFC Position (Local Controller with VIO estimates that send just setpoints to PX4). I am personally curious if the issues you're having are related to the PX4 integration with VIO estimates or if it's truly pure VIO estimates.
how do we make sure what you are saying is right and we are passing estimates to px4 ?
do you want me to enable vfc and see if it works bettter. what should I expect ?
What is your EV_q (quality minimum) in PX4? Also what your HGT ref?
HGT_REF=3 //VIO
EKF2_EV_QMIN=16
EKF2_EV_CTRL=15
Thanks.
Roy
Hi ZBFT,
it seems like your recomendation to OV realy helped improving many things that we could not understand. now the flights are much more robust and we have less vio issue during the run.
We are still struggling to make the vio converege for the first time. We Never know if it going to work on our first takeoff although we wait for "ready to fly" some time it wont hold and after takeoff we will get a message saying VIO_WAIT and during this time although drone is in position mode it will not hold altuitude nor hor,ver.
Now we made a sequence that restart the vins service and wait for good in voxl-inspect-vins. still sometimes it fails to converge. Can you recomend what is the best sequence one should do to get convergence in high precentage after power cycle ?
BR,
Roy
you post a page regarding version upgrade.
somethinig is not clear.
currently we have few starlilng 2 max all were shipped with 1.6.4_alpha2
when we did apt upgrade the version was upgraded to 1.6.6
when we done it on another platform it was upgraded to 1.7.0 alpha.
we noticed that apt source list was not the same.
can you please make it clearer.
are there any release notes we can review ?
what is your recomendation ? we think its better to stay with 1.6.x and get more and more fixes before changing to major 1.7
please supply some more inforamtion this subject is unclear.
BR,
Roy
@zauberflote1 Hi ZBFT,
reagardng your fitst question: yes, we have added few elements:
rerding youe second point:
we did not fly with logs. that is the first thing we are going to do Sunday morning when we will be back in the lab. hope to understand more from logs. if not we will send it to you hopefully you can enlight us.
regarding your third point I dont actualy know the answer:
as I wrote first time I started this thread, we are monitoring the px4 using mavlink status and we see the horizontal position was lost in the middle of flight after starting a manuver to the right which is using position hold. but even when we tried to position hold from code we so vio is lost.
I want to emphasize we had a stable system hw and sw wise and suddelny it degregated and we cannot put our finger what has changed.
BR,
Roy
Hi ZBFT,
We have done the steps you recomended both with 1.6.4 alpha2 version in with 1.6.6 version.
canceling qvio, making sure only one open-vins service regarding vio. recalibrating imu.
The drone is still loosing horizontal pos at the same manuver( sliding to the left when there is a wall in front)
I want to proved you with some facts.
BR,
Roy
Hi,
system-image: 1.8.06-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Wed Oct 22 04:29:38 UTC 2025 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform: M0054
mach.var: 1.2.1
SKU: MRB-D0012-4-V3-C28-T8-M36-X0
────────────────────────────────────────────────────────────────────────────────
voxl-suite: 1.6.4~alpha2
We are flying indoors using lidar and vio.
We monitor MAVLINK_MSG_ID_ESTIMATOR_STATUS during the flight looking at s.flags & ESTIMATOR_POS_HORIZ_REL
it is our way to monitor vio status.
vio was wroking fine for few weeks out of the box.
Now it seems it degragated, in each run it fails when we get to a specific point in our lab. it was not like this before.
We suspect it has to do with hardware but we dont know what exactly. vio loses horizontal position when we get to this specific point when the drone sliding to the side. we do not know what can fire this event.
When we run voxl-check-vibration it seems ok. so we think there is no need to calibrate. The tracking cameras stream looks fine.
voxl-vision-hub.conf
"en_vio": true,
"vio_pipe": "qvio",
"secondary_vio_pipe": "ov",
"vfc_vio_pipe": "ov",
"en_reset_vio_if_initialized_inverted": true,
"vio_warmup_s": 3,
"send_odom_while_failed": true,
"horizon_cal_tolerance": 0.5,
One thing we are not sure about. should both qvio and ov services are working out of the box ? ov is redundency for qvio ? in one of the drones the ov service was disabled without any reason. I guess they should both work after boot.
when you turn off ov service do we need to change the vision-hub.conf file ?
do you have any idea what can be the reason or how to debug it ?
currently we are getting poor vio compared to what we had when we got the drones.
BR,
Roy
@tom hi tom,
Can you recomend a tested and stable version.
The 4 drones were shiped with this version.
any recomendation to what stable version we should move ?
BR,
Roy
Hi,
I was doing already autonomous mission again and again succefully with two drones.
later I also encountered few crashes some of them prety harsh. but I was able to recover. also sufered from px4-param being deleted/corrupted.
Now I test everyting and I cannot get the first drones to work with my code. when I switch to offbaord it immidiatly lands:
VOXL-FC] heartbeat: armed=0 mode=OFFBOARD
[VOXL-SVC] authority revoked (pilot takeover / link loss) — standing down (no re-request).
[VOXL-SVC] WAIT_VIO: VIO velocity unstable (VIO backend converging) (65 s)
[VOXL-SVC] WAIT_VIO: VIO pose stale (70 s)
[VOXL-SVC] WAIT_VIO: VIO pose stale (75 s)
with a new drone out of the box it works great.
I suspect it has something to do with with overwritten params that I am not aware of. tried pulling the params from the good drone by px4-param show -a and compare them. without a good conclusion.
my second guess is that somehow the cameras or other elements are oscilating and make the vio speed estimation not good and that is why these two drone fail to start the mission.
can you help with a step by step procedure to eliminate the prorblem. I have tested the services, the cameras and it all looks fine.
BR,
Roy
Hi,
We have 4 strling2-max drone all with 1.6.4~alpha2 from factory.
One of the drones beacame a brick and I was doing the unbricking procedure.
The only release available in developer site is 1.6.3 so now not all my drones have the same version.
my goal is to make 1.6.3 - > 1.6.4~alpha2 and align all drones
1.6.4~alpha2 is not available in developer site.
what can I do ? it tried apt update && apt upgrade on drone with connction to internet it failed.
MRB-D0012-4-V3-C28-T8-M36-X0
MRB-D0012-4-V2-C28-T8-M36-X0
see sku is v3 in 1.6.4~alpha2 and V2 in 1.6.3
another important question. we intend to assemble the depth camera and change configuration to C29. We noticed the front cameras are moving to a new location with offset regarding the symetric axes. do we need to somehow update vio intrinsix files ? if yes how should it be done ?
Thanks,
Roy
out of the box version:
────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.06-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Wed Oct 22 04:29:38 UTC 2025 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform: M0054
mach.var: 1.2.1
SKU: MRB-D0012-4-V3-C28-T8-M36-X0
────────────────────────────────────────────────────────────────────────────────
voxl-suite: 1.6.4~alpha2
────────────────────────────────────────────────────────────────────────────────
after unbric version:
────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.06-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Wed Oct 22 04:29:38 UTC 2025 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform: M0054
mach.var: 1.2.1
SKU: MRB-D0012-4-V2-C28-T8-M36-X0
────────────────────────────────────────────────────────────────────────────────
voxl-suite: 1.6.3
────────────────────────────────────────────────────────────────────────────────
no current network connection
────────────────────────────────────────────────────────────────────────────────
@RoyAzriel
Hi Alex,
I have done the full procedure of unbricking. everything went well and the system was flashed with image M0054(154)-2.zip downloaded from you developer site.
After switching back SW2 to edl off and restarting the device wont enumerate the usb.
for a minute after booting again I was able to see:
Bus 003 Device 027: ID 18d1:d00d Google Inc. Xiaomi Mi/Redmi 2 (fastboot)
I think this unit is faulty. ABL is not succeding to boot slot A.
how can we do RMA ?
BR,
Roy
Hi,
We have bought 4 units of starling 2 max - C28.
2 units booted fine and we are working with them on daily basis.
3rd unit booted succefully. After connecting adb shell and configuring wifi station 5Ghz everything was working fine.
using voxl-portal I tested all 4 cameras. after a while I notices wifi connection is gone.
later I have made a power cycle by disconnecting and connecting battery. the beep sound and the 3 blue leds are blinking as always.
it seems the system is not loading. the usb adb connection is not discorevable anymore in the host machine.
what can be done in such a state ?
BR,
Roy
@Eric-Katzfey thanks. before I did sdk reflash I found out the px4 params were somehow corrupted. I have tried to reproduce these values without success.
what made it work is taking a similar drawn read the params usign px4-param show -a and writing the to the corrupted one.
@Eric-Katzfey where can I find 1.6.4_alpha2 it is not present in https://modalai.filecloudonline.com/ui/core/index.html#expl-tabl./SHARED/downloads/VOXL 2 Platform Releases
Thanks,
Roy
@Eric-Katzfey what do you mean by "fresh SDK install" ?
run apt install voxl-suite on target ?
@Eric-Katzfey by Dev drone I mean starling2 max. We have 4 units. We have never made changes except aligning the px4 of the sitl with the version of the px4 you are shipping the product with.
Is there a way to diagnose the dsp operation? Some logs to send to you to understand better. Like I said we deploy same software to one drone that behaves well. Second drone was working fine with same deploy was working well until suddenly it started saying battery level is not available. After digging in into it we realized it has something to do with dsp boot.
Waiting for your guidance.
BR.
Roy
@RoyAzriel no.
Hi,
this is my dev drone info.
after working with it quite a bit it started to fail with power issues in prefight. later I noticed battery level is not available. and learned that the dsp is not working good after boot.
I have another drone with same FW there is no problem. can I somehow fix this issue. see below some information.
Thanks,
Roy
────────────────────────────────────────────────────────────────────────────────
system-image: 1.8.06-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Wed Oct 22 04:29:38 UTC 2025 4.19.125
────────────────────────────────────────────────────────────────────────────────
hw platform: M0054
mach.var: 1.2.1
SKU: MRB-D0012-4-V3-C28-T8-M36-X0
────────────────────────────────────────────────────────────────────────────────
voxl-suite: 1.6.4~alpha2
────────────────────────────────────────────────────────────────────────────────
Symptom
After a session of repeated power-cycles/reboots (while troubleshooting unrelated Wi‑Fi/adb and flight-mode params), PX4 stopped functioning. The apps-side voxl-px4 launcher runs stably (NRestarts=0,
stable PID), but no PX4 flight modules run — commander reports not running, battery_status is never published, preflight checks can't run, and voxl-px4 -s hangs.
Root cause observed
The journal shows the apps↔DSP bridge is dead:
ERROR [muorb] Keep alive timeout from DSP: ~1009000 ms
repeating continuously. So the SLPI/DSP-side of PX4 isn't responding — everything that runs on the DSP (commander, sensors, ekf2, battery) is absent.
What we ruled out
- SLPI hardware/firmware is healthy — dmesg shows the subsystem loads fine: slpi: Brought out of reset, Power/Clock ready interrupt received, adsprpc: slpi subsystem is up, opened rpmsg channel for slpi.
FastRPC to the DSP is up.
- Not a version mismatch — /usr/bin/px4 and /usr/lib/rfsa/adsp/libpx4.so are the same build (both Mar 24 2026), and this exact build flew successfully earlier in the same session.
- Not the apps side — apps launcher runs stably, no crash loop.
Recovery attempts that did NOT work
- systemctl restart voxl-px4 (restarts only the apps-side launcher)
- voxl-reset-slpi -t 5000 (DSP "recovered after 800ms" but PX4-on-DSP still didn't come up)
- Manual px4-commander start — "succeeds" on the apps side but nothing actually executes on the DSP
- A warm/adb reboot — fresh boot (uptime ~6 min, new PID) but commander still absent
Question for ModalAI
Why does libpx4.so fail to start/communicate on a healthy SLPI (FastRPC channel open, subsystem up) when the apps-side launcher and the DSP .so are the same build that worked earlier? Is this a known
FastRPC/qurt PD-restart state that survives voxl-reset-slpi and a warm reboot, and is the recommended recovery a full cold power-cycle and/or a voxl-px4 reinstall to restore the signed/known-good
libpx4.so?
@Alex-Kushleyev
Hi Alex,
I did few steps to find our the problem.
after running voxl-configure-cameras 29 I have validate with dmesg camera is probed.
confirmed with voxl-camera-server -l the are 5 cameras.
When running the voxl-camera-server manualy I was able to see a lot of drops and it complains about broken pipes and even had segmentation fault.
When I disabled hires_down and hires_front the voxl-inspect-cam -a it run cleanly.
I guess currently there is a problem to run 5 cameras. for now I disables hires_down in the conf file. I can see the depth camera.
I am not sure how this will effect the vio (is it using it ?). I wonder how it works well when you ship out C29 from the factory ?
Another question it seems the pmd sensor position is that the 105 deg fov is vertically and not horizontal. Am I right ?
BR,
Roy
@Alex-Kushleyev
I have done the procedure after installing depth sensor and backing up.
when running voxl-inspect-cam -a I get the message below. prbobly this procedre left something out.
I have overwritten the conf file and the camera directory with the original backup and everything retruned to work fine.
can you help understand what is missing ?
I can see the pipes that used to work named tracking_front_misp_grey tracking_front_misp_norm are missing after running voxl-configure-cameras 29
thanks
Roy
Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format
| hires_down_large_color |
| hires_down_large_encoded |
| hires_down_large_grey |
| hires_down_small_color |
| hires_down_small_encoded |
| hires_down_small_grey |
| hires_down_snapshot |
| hires_front_large_color |
| hires_front_large_encoded |
| hires_front_large_grey |
| hires_front_small_color |
| hires_front_small_encoded |
| hires_front_small_grey |
| hires_front_snapshot |
| tof_conf |
| tof_depth |
| tof_ir |
| tracking_down |
| tracking_down_bayer |
| tracking_down_misp_encoded |
| tracking_down_misp_grey |
| tracking_down_misp_norm |
| tracking_front |
| tracking_front_bayer |
| tracking_front_misp_encoded |
| tracking_front_misp_grey |ng request pipe: No such device or address
| tracking_front_misp_norm |ng request pipe: No such device or address
ERROR in pipe_client_open opening request pipe: No such device or address
Most likely the server stopped without cleaning up
Client is cleaning up pipes for the server