@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

After some additional investigation I was able to resolve this by replacing the include: #include <c_library_v2/common/mavlink.h> with: #include <c_library_v2/development/mavlink.h> in actuator_test.cpp

@JackHammer no problem. This should be the esc param file for the Starling 2 Max motor : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-params/D0012_Starling_MAX/esc_params_m0129_f2203_5_1500kv_7x3.7x3.xml The param file should also be present in /usr/share/modalai/voxl-esc-params Do you know how to update the esc parameters? systemctl stop voxl-px4 cd /usr/share/modalai/voxl-esc-tools ./voxl-esc-updload-params.py -p <full path to params file> After updating the params, you can run a "power ramp test", as shown here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/doc/low_kv_motor_tuning.md?ref_type=heads#power-ramp-test . Use id=255 to spin all motors (and you can limit power to 80%) ./voxl-esc-spin.py --id 255 --power 80 --ramp-time 3.0 --timeout 3.5 --enable-plot 1 --cmd-rate 250 Since you can't display the plot on voxl2, a plot will be saved as html, which you get download from voxl2 and view in a browser. You can do it without propellers (for safety). If all the motors are working properly, the four rpms will be very close to the same as the power ramps (within 100-200 rpm). Otherwise, you may have a bad motor that was damaged during the crash. https://www.modalai.com/products/starling-2-max-replacement-parts?variant=49704826896688 Alex

@Judoor-0 You can use QGroundControl v5 and later. Then once your drone coots and connected to the QGC, mouse click on the desirable position and select Set Estimator Origin option. This will be your [0,0,0] in local frame and [lat, lon, alt] in global [image: 1752642917216-24ef863e-534d-4894-b99d-d1cacd609954-untitled.jpg]

@taiwohazeez The build flow should be like this: cd voxl-mpa-to-ros2 git checkout dev git submodule update --init --recursive voxl-docker -i qrb5165-emulator ./install_build_deps.sh qrb5165 dev ./build.sh qrb5165 dev ./make_package.sh deb