Hi @serviceberry I happened to stumble on your post here, sorry it looks like no one ever responded to you. Is your HW still in error? Can you confirm how you are powering the VOXL 2 mini, and if anything changed before this issue? The two ICs you show that are smoking hot are interesting. The one at 156C is the level translator for our I2C bus on the power connector. Are you sure you have pins 1 and 2 as power, and not pins 3 & 4? If pins 3 & 4 were accidentally used to power the VOXL 2 Mini, this chip would indeed see the brunt of that issue. The other chip heating up may just be secondary due to the other failure since that chip is downstream of this one for powering the board from the voltage impacted. Looking forward to your response and sorry again no one responded (or did you submit a second case??) Thanks!

@astro_phil with some further investigation over the weekend, i found a small fix in the px4 codebase that seems to reduce the velocity estimation error. I low pass filtered the delta time (dt) value that is used to integrate the linear acceleration to obtain the velocity estimate. [image: 1746443064707-vibration_fix-resized.png] Left is without the "fix" and right is with the "fix". Flying in position hold. [image: 1746443272985-whatsapp-image-2025-05-03-at-15.50.57.jpeg] I tried to induce more vibration on purpose to test the impact on position tracking. Both flights shown in the plot where done with the system shown in the picture.

@Eric-Katzfey From other discussion, I add qshell gps start -d 7 -b 115200 and get the GPS now. Here is my setting and please let me know if any questions. Thank you for your precious time on this matter. AIRFRAME=MULTICOPTER GPS=AUTODETECT RC=CRSF_RAW ESC=VOXL_ESC POWER_MANAGER=VOXLPM AIRSPEED_SENSOR=NONE DISTANCE_SENSOR=NONE OSD=DISABLE DAEMON_MODE=ENABLE SENSOR_CAL=ACTUAL ARTIFACT_MODE=DISABLE EXTRA_STEPS=( qshell gps start -d 7 -b 115200 )

@brandon Do you have a plastic spudger tool? Something like this. A plastic tool will significantly reduce the possibility of damaging any components (compared to using anything hard like metal). Press only on the metal part of the connector to prevent warping that plastic nub end. Typically we use a fingernail to press those connectors in place but for that connector in particular it would be hard to reach with a fingernail. [image: 1746037900033-6d21bb38-e0a6-4d12-b21a-d201dd4fc446-image.png]

@ssansoy , you cannot access the data from these pipes directly, you have to use the MPA mechanisms to do that. There is an example of doing that for tflite detections right here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-detections.c and the compiled app should also be present in the SDK, so you can run it on your VOXL2 (voxl-inspect-detections). Alex

@Yoshimaru-Tanaka , you are right, the information in the documentation is not sufficient to diagnose this issue. There is a page already for camera debugging information, but it is very brief. We will add more details (from this thread and more) to this page. https://docs.modalai.com/debugging-camera-issues/ Thank you Alex

@Jetson-Nano We have never used Microhard on windows but it's possible your firewall is blocking UDP data on that port

Also this is what I was getting when inspecting the mavlink server. 00:19:39.969721 IP 192.168.1.1. domain > 192.168.1.134. 40850: 5282 Refused 0/0/0 (42) 00:19:39.970315 IP 192.168.1.134.48451 > 192.168.1.1. domain: 5282+ PTR? 1.1.168.192. in-addr • arpa. (42) 00: 19:39.973637 IP 192.168.1.1. domain > 192.168.1.134.48451: 5282 Refused 0/0/0 (42) 00:19:40. 106351 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21 00:19:41. 068099 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21 00:19:41.553204 ARP, Request who-has 192.168.1.1 tell 192.168.1.134, length 28 00:19:41.553488 ARP, Request who-has 192.168.1.138 tell 192.168.1.134, length 28 00:19:41.558414 ARP, Reply 192.168.1.1 is-at 80:69:1a:06:84:4e (oui Unknown), length 28 00:19:41.561634 ARP, Reply 192.168.1.138 is-at 34:c9:3d:07:16:8d (oui Unknown), length 28 00:19:42. 065376 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21 00:19:43.070712 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, Length 21 00:19:44.075718 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21 00:19:45. 064630 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21 00:19:46.062935 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, Length 21 00: 19:47. 107960 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21

@Alex-Kushleyev, I using voxl2 with M0173 board with camera config 29. The errors are now solved, I made the necessary changes and reconfigured every server and pipeline and calibrated the cameras.

@KnightHawk06 , DFS on VOXL2 uses the Qualcomm's proprietary implementation of the DFS algorithm, which runs on the specialized DSP (CVP - Computer Vision Processor). Unfortunately we do not have any details about the actual algorithm. Alex

@Zachary-Lowell-0 Yes I installed voxl-ros2-foxy. This time I just tried "source /opt/ros/foxy/mpa_to_ros2/install/setup.bash" and that was accepted. However, looking now px4_msgs is still not recognized within my program. [image: 1745358768903-73d768a7-bab0-42d9-b73e-b4e84749294a-image.png]

@Alex-Kushleyev Hi @yardy Are you using the jumper blocks J14.15/J14.17 to JP1.10/JP1.12 respectively for QUP_19? It was connected to JP1.9/JP1.11 (because of the jumpers... I was wrong) It's working! Many thanks

@inteous yes, there are a number of considerations Please see: https://docs.modalai.com/configure-extrinsics/ https://docs.modalai.com/calibrate-cameras/

@FIREBIRD Sure, reach out at https://modalai.com/contact Yes, it's supported in production volumes