@FIREBIRD Sure, reach out at https://modalai.com/contact

Yes, it's supported in production volumes

@Andrew-Jue Have you made sure that no other service is running that can send odometry messages that conflict with to MAVROS ones? But, yes, you have a good point about the timestamps. PX4 on VOXL 2 runs on "DSP time", not apps proc time so there is a big delta (that moves over time) between standard Linux time and what PX4 uses. That's why we use the timesync protocol to align times between our applications (like VIO) on Linux with PX4 running on DSP.

@Andrew-Jue How is EKF2_EV_CTRL set in PX4?

@Rowan-Dempster No problem! Kind of primitive but effective

@Rowan-Dempster First of all, the CPU report for DSP is only an estimate. It's really tough to get a good CPU estimate due to the way it "sleeps" and it's parallel architecture. But I have seen that before where there is a difference of 10% between builds and I don't know what causes that yet. So I wouldn't be too worried about it. v1.20 only adds that debug print during startup so shouldn't be any extra risk above moving to v1.19.

@Rowan-Dempster The new package is here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/modalai-slpi_1.1.20-202504131441_arm64.deb

@Rowan-Dempster There is a way to figure out where in the code the crash happened. I can update the modalai-slpi package to add a debug print in mini-dm to show the address where libpx4.so was loaded into memory. I just ran that and it showed that libpx4.so was loaded at address 0xe6120000. Once you know that you can disassemble libpx4.so to get the address map (For example: /local/mnt/workspace/Qualcomm/Hexagon_SDK/4.1.0.4/tools/HEXAGON_Tools/8.4.05/Tools/bin/hexagon-llvm-objdump -d build/modalai_voxl2-slpi_default/platforms/qurt/libpx4.so > dsp-image.dis). Take the address you get for the PC in dmesg (in this case 0xe61fc160), subtract off the base address (0xe61fc160 - 0xe6120000 = 0xdc160), then look up that address in the disassembled file. That will show you where it crashed. You also get the LR in the fatal error message so that can help show where it was called from.

@Jetson-Nano Are you able to ping from VOXL2 to the onboard Microhard board or the other Microhard board with the modules specified IPs? Usually 192.168.168.1 for master and 192.168.168.2 for slave

@QSL Hi, thank you for reaching out. There are many ways to achieve what you are trying. Starling 2 is the best starting point. You can then learn about what will work and what will not work and build out your system design from there.

@Rowan-Dempster That program counter (PC=0xe61fc160) indicates that the crash happened in the loaded px4 library.