@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

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

@brandon You'll need to load SDK v1.6.x to get it.

@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

@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

@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

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

@brandon The latest voxl-mavlink-server is available here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mavlink-server_1.4.12-202511040816_arm64.deb. This has added configuration for the GCS ports and also fixes the above issue so that it now responds to the correct port.

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

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

@tom Thank you @tom

@tom [image: giphy.gif]

Choose Option 1 if you DO NOT have the camera board attached [image: 1758735212722-d9a9defd-3783-452a-a735-7cb2c38d7065-image.png] Choose Option 2 if you are using the camera board [image: 1758735235936-3a551368-4c35-4edd-8f0d-09b2f6cd47da-image.png]

@Eric-Katzfey Thanks for the reply. You’ve correctly identified my problem. Due to time constraints, I need to deploy my system soon. I hope to have a solution that works on your hardware or to wait for the Ubuntu 20 update.

Hello @itzikwds, Sorry for the delay. We can extend pympa to support the ai_detection class. Here is as example of an application that receives the detection data : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/dev/tools/voxl-inspect-detections.c However, since you need this in python, pympa would need to be extended to support the detection data. Can you please confirm that you still need this functionality or did you find another solution? Alex

@tom Thank you so much. It is working now with your suggestion. I think the README file of voxl-tflite-server need to be updated.

@Ege-Yüceel Wow, this is a very ambitious plan! Keep in mind that VIO needs not only camera images but also IMU input. Camera images are normally supplied by the voxl-camera-server on MPA pipes. So, you would need to stop voxl-camera-server and start your own application that takes the images from Gazebo and places them into correctly named MPA pipes. The images would have to be formatted properly, etc. Likewise for IMU samples that normally come from voxl-imu-server. I think this will be quite difficult to get working properly but theoretically possible.

Solved using SDK 1.4