VOXL SDK

Platform-Specific PX4 Bug - Incorrect Evaluation of NaN

Eric Katzfey — Wed, 15 Jul 2026 16:08:33 GMT

And the latest build of our fork with this fix is here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.146-202607161052_arm64.deb

[VOXL-SVC] WAIT_VIO: VIO velocity unstable (VIO backend converging) (30 s)

Alex Kushleyev — Thu, 02 Jul 2026 15:50:33 GMT

Hello @royazriel , please take a look at our documentation, which has some testing tips : https://docs.modalai.com/voxl-open-vins-server/

voxl-suite upgrade

tom — Wed, 01 Jul 2026 11:54:07 GMT

@RoyAzriel 1.6.4 release is tested on Starling 2 now, go ahead and use that from the link I emailed you.

dsp is not running

RoyAzriel — Thu, 18 Jun 2026 13:23:50 GMT

@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.

Latest SDK versions - How to access?

nl_vdi — Fri, 05 Jun 2026 21:24:15 GMT

@tom said in Latest SDK versions - How to access?: https://storage.googleapis.com/platform-beta-releases/voxl2/voxl2_SDK_1.6.4-beta8.tar.gz Thanks @tom !!!

voxl portal qvio

Fri, 29 May 2026 10:33:26 GMT

Request for How to use SPI (J10 port) in SDK 1.45-VOXL2-mini

Hector Nevarez — Fri, 08 May 2026 02:16:41 GMT

Hi Kim, There are a couple changes required here that will make this work: 1. Rebuilding Kernel with SPI14 enabled You're going to have to rebuild and flash the kernel with QUP14 enabled as SPI. There is also a directional level shifter on GPIO67 that needs to be set to high in order for SPI on QUP 14 to work. I created this branch for you that should have the kernel changes that you need: feature/voxl2-mini-spi-qup14 (link) In order to actually build and flash the kernel please follow the instructions from our public docs on how to build the kernel https://docs.modalai.com/voxl2-kernel-build-guide/ When building the kernel, after syncing but before building, make sure to go to the cloned meta-voxl2-bsp directory and checkout the branch that I created (feature/voxl2-mini-spi-qup14). Also there is a chance you may need to build a kernel variant depending on your device so also make sure to check this document to see if you have a -2 device which would require building the kernel with the -v var02 flag https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2 2. Configuring Trustzone with Correct QUP I would recommend using the devcfg binary that comes from the `voxl2-mini_SDK_1.0.0.tar.gz. In order to flash devcfg you'll want to run the following command fastboot flash devcfg /devcfg.mbn You should flash the kernel and devcfg (Trustzone) during the same fastboot session to avoid running into any issues with the device booting. Let me know if you have any additional questions or run into any issues!

QRB5165 emulator image 1.6

huy — Thu, 23 Apr 2026 12:06:03 GMT

@Alex-Kushleyev Thank you so much for your response. It helped a lot.

voxl-vtx and voxl-vrx source not on gitlab?

tom — Tue, 14 Apr 2026 17:59:53 GMT

@Alan_S The voxl-vtx repository is currently private, the source code for both voxl-vtx and voxl-vrx are contained within.

Latest voxl-cross images missing?

Alan_S — Mon, 13 Apr 2026 17:30:05 GMT

@ZuraNeb Perfect! Thank you!

Multiple Critical Bugs in voxl-imu-server: Incorrect FIFO Latching and HiRes Indexing (ICM-42688)

Igor — Wed, 01 Apr 2026 19:45:08 GMT

@Alex-Kushleyev Hi Alex, Thank you for the clarification. That makes sense regarding the accel parsing—agreed that a 4 LSB discrepancy on a 20-bit value is negligible compared to in-flight noise, but it’s good to see it will be corrected. Appreciate you taking the time to investigate and confirm. Igor

Starling 2 / VOXL2 M0129 ESC not detected during voxl-esc scan or firmware upgrade

Mon, 23 Mar 2026 16:37:19 GMT

Ubuntu 20.04

Alex Kushleyev — Wed, 18 Mar 2026 16:45:32 GMT

@fhaltmayer , unfortunately, we do not have any updates at this time. It looks like we may never release Ubuntu 20.04 for VOXL2 because it is a LOT of work to switch to a new major Ubuntu release and test + maintain everything. Additionally, even Ubuntu 20.04 is already relatively old, so we are trying to focus our efforts on more forward-looking software development with larger impact. Alex

Connect qrb5165-emulator to voxl-gazebo-docker

Thu, 05 Mar 2026 17:13:13 GMT

Starling-2 Max

Wed, 04 Mar 2026 10:10:29 GMT

voxl-cross error when building voxl-open-vins-server

zauberflote1 — Thu, 26 Feb 2026 20:31:35 GMT

@bendraper Hello, I hope this quick clarification helps for warnings: CMake Policy warnings: OV internally (external dir in the repo) still uses boost and references an older cmake version -- it's a harmless warning for devs (as you are building from scratch) Yaml-cpp lib warnings: This is a third party dependency that gets compiled from scratch during the make/build process. We use C++ 17 but the library is based on an older C++ version; nevertheless, it compiles fine on C++ 17 with minor warnings. -- it's a harmless warning TrackOCL warning: ModalFlow is a core library written in C++ 17 that allows function call usage as done in TrackOCL, i.e., the narrowing conversion is harmless in this case. That being said, we are actively working on the dev branch, so all flight--impacting warnings are hopefully caught early. We currently have no flight-impacting warnings/bugs identified, but if you found one warning/bug that caught your attention, please feel free to share. All the best, ZBFT

Can't start PX4 PCA9685 Driver

cbay — Fri, 06 Feb 2026 16:17:10 GMT

@Alex-Kushleyev Found the reason why it was skipping. In /px4-firmware/src/lib/parameters/CMakeLists.txt there is a line that skips all modules that match 'pwm_out'. I was able to disable that for PCA9685. Once I disabled the module.yaml file being skipped it worked. No need for the .c file (which makes sense, that is just the old way to do the .yaml)

EGL example for voxl2

Alex Kushleyev — Wed, 28 Jan 2026 21:56:59 GMT

@Andrew-Jong , we are able to reproduce the error that you are seeing. I believe that you may need to set up a virtual display in order to get this to work. You could try doing so using Weston compositor, which would normally run if the display was available. Please try it and let us know if you are able to get it to work (or not). You would need to create a config file /etc/xdg/weston/weston.ini and try running it manually like this : weston --idle-time=0 --config=/etc/xdg/weston/weston.ini a sample config file might look something like this: # configuration file for Weston [core] idle-time=0 repaint-window=15 [output] name=virtual-1 mode=on We have not tested this yet, but hopefully it's a good start. Alex

Trouble configuring Boson+ on Voxl2

Alex Kushleyev — Tue, 20 Jan 2026 22:53:48 GMT

@Samuel-Lehman If you have the original adapter for Boson+ which allows you to connect it to a USB port, then you can use the FLIR SDK (we use Boson Plus SDK 4.0). Unfortunately, M0153 board does not have J3 connector populated, which would allow you to connect a serial-to-usb adapter to it. We have several python scripts, which use the Boson SDK to help set up the Boson sensor without the GUI. query basic sensor info: https://storage.googleapis.com/modalai_public/temp/boson/boson_read.py set up sensor for 8bit MIPI mode, 60fps (option to set 30fps): https://storage.googleapis.com/modalai_public/temp/boson/boson_set_8bit.py You can put both of these scripts next to the BosonSDK directory and run them. Please check the USB port name inside the scripts. Once you get that configured, you can put M0153 back on boson. Regarding where to plug it in on Voxl2, please tell me what other cameras you plan to use with your Boson. Alex

Toolchain for m0054-data-fs.ext4

Rowan Dempster — Wed, 17 Dec 2025 17:25:13 GMT

@Moderator Hi Modal, Does this mean you can create a custom data file partition that you can flash using fastboot? Yes that is correct. We have not explored this before but it has been asked a few times. This could be very helpful for other developers. I'm certainly hopeful that it will be helpful here at Cleo Robotics! So far with my prototyping it works as expected and cuts flashing time of some large docker images we have here at Cleo down by a noticeable fraction (no file overhead via fastboot like with ADB). I think the snippet I posted covers the baseline functionality of getting a custom "payload" into the data partition. However if there is more I can elaborate on in terms of the toolchain / what's in the payload, and if that elaboration will be helpful to other VOXL2 developers, I would be happy to elaborate Just let me know! Other similar discussion points I tackled recently that I'm happy to talk about lessons of: Flashing the system image and VOXL/CLEO SDK through a Windows Machine (journeys in USB device drivers) Building Flutter applications for uniform flashing process across all operating systems Building release bundles (i.e. a collection of partition binaries) in CI

voxl-px4 vs mainline px4 SITL questions

jmltt — Tue, 16 Dec 2025 17:28:20 GMT

@jmltt Looks the same bug as here: https://github.com/PX4/PX4-Autopilot/issues/22148 Added the change from this commit and it looks like it works now: https://github.com/PX4/PX4-Autopilot/pull/22194/commits/38f3c711084b349cb9ed82cf44ff181c6a40738a

Remote ID over Wifi

Thu, 04 Dec 2025 20:09:18 GMT

voxl-mavlink-server incorrectly sets UTC clock from GPS time

Tjark — Tue, 28 Oct 2025 15:34:24 GMT

@Eric-Katzfey Thanks for your update. We tried it on one of our drones but we had some strange issues regarding invalid setpoints afterwards and we think it may be caused by a voxl-px4 version mismatch. We were running version 1.14.0-2.0.98 of voxl-px4 and the version you provided is 1.14.0-2.0.116. Would it be difficult to provide a patch for version 1.14.0-2.0.98? We also had our first log of that it occurred again with our forked voxl-mavlink-server. The drone continued its flight now which is good. This is the changed function: void mavlink_services_handle_system_time(mavlink_message_t* msg) { // collect and consolidate information int64_t time_now_ns = my_time_realtime_ns(); int64_t time_now_s = time_now_ns / 1e9; int64_t gps_time_us = mavlink_msg_system_time_get_time_unix_usec(msg); int64_t gps_time_s = gps_time_us / 1e6; // check gps time is valid if(gps_time_s == 0) return; bool within_10_seconds_original = abs(time_now_s - gps_time_s)<10; bool within_10_seconds_correct = llabs(time_now_s - gps_time_s)<10; if (within_10_seconds_original != within_10_seconds_correct) { printf( "WARNING! The check if we are within 10 seconds gives an incorrect result due to wrong usage of abs.\n" "Original: %s, Correct: %s (time_now_s=%lld, gps_time_s=%lld, diff_original=%d, diff_correct=%lld)\n", within_10_seconds_original ? "true" : "false", within_10_seconds_correct ? "true" : "false", (long long)time_now_s, (long long)gps_time_s, abs(time_now_s - gps_time_s), // truncated 32-bit diff llabs(time_now_s - gps_time_s) // correct 64-bit diff ); } // if we are within 10 seconds, good enough if(within_10_seconds_correct){ if(time_needs_setting){ printf("detected system time has already been set\n"); } time_needs_setting = 0; return; } else time_needs_setting = 1; if(!time_needs_setting) return; struct timespec ts_now; ts_now.tv_sec = time_now_s; ts_now.tv_nsec = 0; struct timespec ts_gps; ts_gps.tv_sec = gps_time_s; ts_gps.tv_nsec = 0; printf("WARNING! System wants to use GPS system time message to set UTC clock from %s to: %s", asctime(gmtime(&ts_now.tv_sec)), asctime(gmtime(&ts_gps.tv_sec))); printf("We will ignore this system time message and we won't update the clock"); // if (clock_settime(CLOCK_REALTIME, &ts) < 0) { // perror("Failed to set system time to GPS time"); // return; // } time_needs_setting = 0; return; } And we got log lines like this: Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:29 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:29 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:30 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:30 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:31 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:31 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:32 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:32 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: We will ignore this system time message and we won't update the clockWARNING! System wants to use GPS system time message to set UTC clock from Fri Nov 7 09:07:33 2025 Nov 07 09:07:28 JOHN voxl-mavlink-server[2237]: to: Fri Nov 7 09:07:33 2025 but I don't yet understand why it is triggering this log because both timestamps seem to be identical. Maybe you have an idea?

Camera calibration fails

akirahrkw — Fri, 17 Oct 2025 07:33:35 GMT

@Alex-Kushleyev Thank you for the information and support! the calibration worked well after stopping other services. Akira

ADB stops working followed by failed unbricking

Vinny — Fri, 03 Oct 2025 20:34:28 GMT

Hi @SKA Apologies no one responded promptly. From what I gather, these are best to be sent back as an RMA and we can try to recover them. D1 (green) is an indication of the local 3.3V power being Good. So, that implies you have 3.8V input, and the 3.3V reg is OK. DS2 (RGB) is controlled by Qty-3 GPIOs from the SoC. This can briefly blink on boot until the GPIOs are configured by apps software. D2 (green) is the 5V USB VBUS USB1 (10-pin) port power indicator, which only comes ON after the QRB5165 boots and Apps controls the GPIO to turn the VBUS ON. On failed SW loads, it is common to diagnose that by seeing DS2 or D2 blink, which indicates boot loops. D1 should NEVER go off, if so, something is wrong in HW or cabling. We do caution any customer that sets up their own CI or internal validation automation to include a nice pause before repeated power cycles. A common 5 second rule is good to let the large caps discharge, or certain ICs will never fully reset. This is the most common cause of "bricking" devices. The RMA is your best bet here and we can try to recover them for you, or diagnose for any other issues: https://www.modalai.com/pages/rma