@Moderator Thanks for your response. I think I respond to all forum posts as swiftly as possible. As a matter of fact, I think the reverse is the case, I've had situations where the technical team don't respond to messages on the forum (which I understand because they have to attend to a lot of people). Anyways I have responded to pending messages prior to the break, and will respond to the calibration issue tomorrow when I get access to the drone. I really do hope I can get the drones working perfectly soonest.

Thanks,
Taiwo

@Moderator Thank you for your response. I have gone through the documentation several times. Even with that, I can't tell why I get those preflight check fails. Sometimes it clears, most times, I keep getting several warnings. I will go over the documentation again, maybe I am missing something.

For instance, why do I have a cpu usage when the voxl-modem isnt running? or is that normal
? Screenshot from 2026-01-04 08-23-16.png

Regards,
Taiwo

@Alex-Kushleyev Thank you for the response. After fresh reboot the camera pipes functions for a little while and stops immediately (I can see it in voxl-portal, then they keep disappearing until i am left with tag_overlay and multi-view

@zauberflote1

Support Follow-up: VIO Stability Improved with chi2 Tuning - Kalibr Planned for Tomorrow

Thank you very much for your detailed advice. It was extremely helpful.

Progress Update 1. Successful VIO Stabilization via up_slam_chi2_multipler

Based on your suggestion, we adjusted the up_slam_chi2_multipler in estimator_config.yaml.

Finding: Setting it to 3.0 (default was 1.0) resulted in a dramatic improvement. Result: The drone can now hover in Position mode for over 5 minutes without losing feature points or dropping to Altitude mode. Previously, it would fail within 10-20 seconds. 2. Current Status and Remaining Issues Drift: While the position lock is maintained, there is a slight "swaying" or drift (within approximately 30cm) during hovering. Cause: We suspect this is due to the CAM-IMU extrinsics still relying on physical measurements (CAD values), which don't perfectly match the actual hardware alignment. 3. Extrinsics Fix (imu_apps_body)

We noticed an error in the voxl-vision-hub logs regarding a missing body to imu_apps_body transform. We added this entry to extrinsics.conf, which ensured the system recognizes the coordinate frames correctly while using OpenVINS in imu_body_frame_mode.

Plan for Tomorrow: Kalibr Calibration

We have successfully set up the Kalibr environment on our PC using Docker and prepared a script to convert VOXL MPA logs to ROS bags.

Today, we attempted a preliminary run, but the tag detection rate was low due to monitor reflections and tag size discrepancies. Tomorrow, we will use the official AprilGrid pattern and perform a clean calibration to obtain precise Extrinsics and Timeshift values.

@voxltester And, in general, for all software engineers out there here is a helpful tip. ModalAI is not affiliated with Anthropic in any way but I do want to highlight their Claude Code tool. It can really help you not just write code, but to understand code that is already there. So, for example, in this post there is a question about how the -b option is parsed. It's a bit complicated how all of the pieces fit together but if you were to ask Claude this question: "I'm using the device driver in the file lightware_laser_i2c.cpp. I was told that the LightwareLaser class can take the command line option -b to specify the i2c bus number using the start command. Can you show me where in the code the -b option is parsed?". Claude will then give you this answer:

The -b option is not parsed directly in this file. Looking at the code: At line 450, the custom option parsing only handles -R for rotation: while ((ch = cli.getOpt(argc, argv, "R:")) != EOF) { switch (ch) { case 'R': cli.rotation = (Rotation)atoi(cli.optArg()); break; } } The -b option (for I2C bus number) is handled automatically by the BusCLIArguments class, which is instantiated at line 445: BusCLIArguments cli{true, false}; This class is included from <px4_platform_common/i2c_spi_buses.h> (line 47). The cli.getOpt() method internally processes standard I2C/SPI options like -b (bus), -a (address), etc., before returning custom options like -R to this driver's switch statement. If you want to see where -b is actually parsed, you'd need to look at the BusCLIArguments class implementation in the PX4 platform common library: src/lib/drivers/device/posix/i2c_spi_buses.cpp or platforms/common/i2c_spi_buses.cpp The PRINT_MODULE_USAGE_PARAMS_I2C_SPI_DRIVER(true, false) call at line 435 documents that this driver accepts I2C options (including -b), but the actual parsing is abstracted away in the shared bus infrastructure.

@sansoy Can you please provide some details on your setup? What hardware are you using? Which software are you using (including versions)?

@Denver-Bennett said in How do I connect MAVROS to PX4 with UDP ports?:

voxl-vision-hub.conf

did you ever get this resolved? having same issue.
S

@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

@jakkkkobo

Hello,
We currently do not ship any mask files with our airframes, as they are normally not required. In addition, you should be able to use a mask with minor modifications on the server side, namely VoxlCam directory inside voxl-open-vins-server repo. (The mono camera case should be a good starting point, as we already have the masking logic for occluded cams during takeoff.)

Furthermore, as we use a custom interface/backend for OV, loading the mask as done in the traditional OV-ROS format won’t work as intended, i.e., via Yaml.

All the best,
ZBFT

Thank you Alex. We started with this param file: Seeker_V1_tmotor_f2203_1500kv_Param_Rev_A.xml from the voxl-esc params repo and I made a few tweaks like the vbat_nominal_mv and motor_kv and I verified the num_cycles_per_rev was correct for the new motor.

Also for my improving my knowledge so I don't make a mistake like this again how do you come to the conclusion it is too large? I knew it was on the edge based on the 750g number you provide but when I look at our ecalc numbers for this drone it says 3.75A per motor in a hover and 17A at full throttle per motor which seems well within the current specs listed.

I will do the RMA and get the FPV esc. Are you able to provide the updated param file in the meantime? Let me know if you need more info before you can generate that.

Anthony

@Aaky After that much use it could very well be ESD damage. It seems unlikely we would be able to fix via RMA.

@qubotics-admin Hi, we sell all of those components for companies to integrate into their products.

The Flir Hadron adapter (MDK-M0202-1-00) can be requested by reaching out to sales at https://modalai.com/contact

The rest of the components should be available to purchase at modalai.com

@JoonaR Hi Joona, the DP should work to drive an HDMI projector with the appropriate adapter. This adapter has been tested to work: https://www.amazon.com/Cable-Matters-48Gbps-Adapter-Supporting/dp/B08MSWMXT4?th=1

@Piyush-Singh Have you tried voxl-camera-server -d0 found here https://docs.modalai.com/voxl-camera-server/#troubleshooting ?

You cannot plug in cameras arbitrarily, you'll need to use one of the supported camera configurations: https://docs.modalai.com/voxl2-camera-configs/

@colombe-ai currently 30 business days is quoted on the website: https://www.modalai.com/products/starling-2-max

It typically should ship more quickly than that though, likely 2-3 weeks

There is no overnight shipping option as all of the drones are built to order

@colombe-ai

You can find the batteries here: https://www.modalai.com/products/m10000538
Any 2S LiIon hobby charger will work. Something like this is all you need: https://www.amazon.com/ISDT-608PD-Battery-Charger-Discharger/dp/B0CM9BFQSX

Handheld transmitter depends on the configuration of the drone. You can order the drone with a pre-bound charger ready to fly from the website.

The main debugging cable is a standard USB-C cable