@YUUJI-INOUE
Glad to hear!

All the best,
ZBFT

@Muqing-Cao Here is the latest beta release: https://storage.googleapis.com/platform-beta-releases/voxl2/voxl2_SDK_1.6.3-beta1.tar.gz

@Sarika-Sharma Kindly resolve this issue also https://forum.modalai.com/topic/4952/pmd-tof-not-detected-on-voxl2?_=1766730439331.

@alan123 Are you starting voxl-px4 from the command line (e.g. voxl-px4 -d) or is it starting automatically from a systemd service file on startup. If you have started it from the command line you can enter commands from the px4 shell. So, after the script is done, you can enter gps status to see that the driver is doing. If the driver hasn't been started, try starting it directly from the command line.

@taiwohazeez ,

Once thing i noticed is that you don't have en_misp set to 1 for the tracking_front camera. I don't think this is the reason for the failure, but it should be set to 1.

Meanwhile, please try to identify which camera is causing the issue by disabling cameras and testing camera server ( you can set enabled flag to 0, so that this camera is not started.

Also, when you installed SDK 1.6.2, did you run voxl-configure-cameras and which option did you select for the camera configuration?

Alex

@Alex-Kushleyev
Thank you!

What is the procedure to provide design for review?

@Moderator Thank you for the link. But he says he needs to get on a call with the technical team. It's a year already and I still don't know much about the drones (which may be from my end, I don't know), but he wants to handle this himself this time around and get all necessary information on a single call sometime early in January 2026. Kindly let me know if this is possible, and how to go about it.

Thanks

@taiwohazeez ,

It is possible, as the output suggests that the motion blur is causing the issue.

You can override the auto exposure algorithm and reduce the exposure down to 5ms or so to help with this. There are two ways of doing this:

using voxl-portal : open the regular camera view for your tracking camera, click a small check box in the bottom left corner to enable the advanced control panel. This will allow you to set the exposure and gain, you can try to set the gain to the max (should be 1600 (16x) for AR0144) and then play around with exposure to have the lowest exposure that still makes the checker board clear. After you are done changing the manual exposure, you can run the calibrator and switch the voxl-portal to the calibrator output.

please note that until you touch the sliders for exposure and gain, they will not correspond to the current values that are being used by auto-exposure algorithm.

from command line you can send a command to camera server: voxl-send-command tracking_front set_exp_gain 5.0 1600
(this would set exposure to 5.0ms and gain to 1600 ISO (16x))

Please note that the manual exposure settings / mode will persist until you reboot the camera server.

Alex

Hello @SKA,

Thank you for the details. I can't think of anything right now, but will double check this.

I know that there is one potential issue in voxl-camera-server - the SPS header (which is part of the H264 / H265 stream) is only sent by the video encoder once (at the beginning of the stream). I believe that voxl-streamer will cache the SPS packet (which contains things like resolution, etc) and i think when clients connect to voxl-streamer, then it will send that SPS header to the clients. However, if voxl-streamer does not get that first header, it will not be able to forward it to the clients. This is a guess for now, but could be related to the issue that you are seeing.

I can look into this issue. Can you please let me know how exactly to set up VLC for 0ms cache? I want to make sure that my test is the same. Also, which version of VLC are you using?

Also, i noticed one thing - you are using hires_misp_color stream from camera server, which is not actually encoded, but YUV. Then voxl-streamer will take those YUVs and encode them (using hardware encoder). Is there a reason why you are not using the hires_misp_encoded stream to get H264 directly from camera server and serve it using voxl-streamer without re-encoding? I wonder if in the old SDK you were using _color or _encoded stream?

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

@Sarika-Sharma and I also wanna tell you my goal i.e. stable indoor flight without GPS

Hi @Martin-Lukac ,

Thank you for the update. I am glad to see that your new tests went fine. As I mentioned before, i was quite surprised to see the ESC fail in such a way, which may suggest some kind of anomaly.

I will provide a longer answer soon, but for now some quick notes:

non-zero kp / ki parameters will speed up the ESC's RPM response. I will provide some examples you can test whether the ESC closed-loop controller is stable using voxl-esc tools, using step inputs, etc. if unstable, lower Kp. Then lower Ki to avoid slow overshoots. Ki will definitely not contribute to high frequency oscillations. assuming the ESC closed loop response is stable, if the Flight Controller is commanding noisy RPMs, the ESC with aggressive tuning (high kp) will try to track the noisy rpm commands, resulting in motor and ESC heating up. there are generally two main sources of oscillations: unstable attitude controller or vibrations / noisy gyro unstable attitude controller : characterized by lower frequency oscillations (in the range of 10-30Hz, depending on your frame, motors, etc) vibrations can result from drone frame twisting at the frequency of motor RPM, or loose flight controller board / IMU, if flight board is shock mounted, the connected wires can potentially carry vibrations or cause the board to flex due to the wires vibrating / moving (very quickly). These vibrations will be at the frequency of motor RPM. aggressive (high) values of ESC kp will amplify these vibrations, so you can end up in a situation when the ESC's closed loop RPM controller is feeding back and contributing to higher oscillations. by analyzing the gyro logs (will need to enable high rate logging), using FFT you can determine if your frame is mechanically unstable / noisy or the attitude controller is unstable. if you set kp and ki to 0, you still have the advantage of calibrated (and voltage-compensated) RPM control. However, the control will only have feed-forward term. So behavior will be close to response of a traditional ESC with added calibrated feed-forward rpm control with voltage compensation. regarding whether you need a bigger ESC.. it depends on the maximum total current that you plan to pull. The M0138 ESC has been tested with similar motor / prop combo (3110 motor, 900kV with a 10x4.5 tri-blade) . During bench testing, each motor could pull close to 40A at 6S, however in practice you are never going to have all 4 motors spinning at absolute maximum rpm (then you will not have any control margin for attitude). We have tested full punch-out flights for 100+ Amps for over a minute and the ESC was perfectly fine (airflow required for cooling). The mosfets on M0138 are rated for 100A+ continuous (each), so 40A continuous an issue. It will come down to the total current draw and cooling. For high power applications like this, you should definitely start at lighter loads and try to push the ESC to the limit. You will also need to worry about power connector(s) if you are drawing 100A+ continuously (battery connector may melt). px4 params: the min and max rpm params in px4 should match the min and max in your esc params. the px4 params do not override the limits in the esc params - the ESC will cap the incoming rpm commands if they are outside of the ESC params limits. Also, if you have incorrect px4 rpm limits, the thrust calculation in px4 will be incorrectly scaled from 0 to 100%, so you definitely want to get those rpm limits to be in sync between the ESC and px4.

Also, you can use our custom version of flight-review to display additional data specific to our ESC (rpm commands, actual rpms, esc temps, etc) : https://github.com/modalai/px4-flight-review (you can run it locally in docker).

Alex

Hello @MattB69 ,

Sorry I made a mistake regarding the current rating of the step-up regulator. the 80mA number was for a very low input voltage (to the step-up regulator). with 3.3V intput to the step-up regulator, M0065 can support up to 350mA of output current at 5V, but we still do not recommend using it for powering servos.

So this means that our documentation for D0015 flight configuration is in conflict with documentation for M0065 board (which says use 5.0V for reference only).

Even though we have tested it in the D0015 configuration with "some" servos (i am not sure which ones were used), we still do not recommend powering servos using 5V from M0065. We will update the D0015 documentation.. Thanks for pointing it out!

Alex

Hello @HsinSWT ,

When i see results like this, i would say there is probably 90% chance that the motor is bad. Unfortunately, there is a chance that the ESC is bad as well, and there is no good way to check the ESC without a known good motor (however the ESC failure is unlikely).

As I mentioned in the previous post, if you had a milli-ohm meter, you could test the motor winding resistance to confirm whether the motor is good or bad. A tool like that measures resistance with high precision (similar to a regular Ohm meter). However, if you don't have one, it may not be worth buying it..

You will not be able to measure the winding resistance of these motors correctly with a regular Ohm meter. However, you will be able to detect a complete open circuit (which could be the case, maybe worth trying). If testing resistance using a regular Ohm meter, any two connections between the 3 motor phases will read 0 ohm (or close to that). If a wire is broken, then you can detect it.

The Starling 2 motor (3000kV) has around 0.360 - 0.370 Ohm phase-to-phase winding resistance.

In order to confirm that the ESC is working properly, you could temporarily connect one of the working motors to the ESC Channel 0 and do the same spin test (using voxl-esc tools), just to confirm that the ESC Channel 0 is working fine.

In order to fix the issue, you could order a new motor and replace it yourself (will be a lot cheaper): https://www.modalai.com/products/starling-2-replacement-parts?variant=49707605393712

You could also send the whole drone back for repair (https://www.modalai.com/rma)

Alex

@awagner ,

I think the main issue that started the failure mode was the spin-up type was set to 0 in params, which I do see that you got from the seeker_v1 xml file you mentioned. It is not your fault. The non-sinusoidal spinup is not as reliable and it is mostly not used any more. I will look at removing the old param files that use that option.

Let me explain the reasoning behind using a larger ESC, especially during initial testing:

the larger (FPV) ESC can handle much larger currents and dissipate a lot more heat, so it can handle much larger glitches, which could arise from mis-configuration during initial testing the ESC firmware does have some timeouts for protection, which generally do prevent fatal issues like this, but if the glitch results in enough current to quickly burn out a mosfet, the ESC cannot recover. The larger ESC (with larger mosfets and larger thermal mass will take longer to burn out, so the ESC's timeout / glitch detector should save it) larger motors in general have larger stall current, which would result in large current if there is some glitch during start-up. based on the numbers that you provided for the motor spec calculator (3.75A hover / 17A max), it should be possible to tune the mini ESC to work, however there are still some things to consider: may need to add more bypass capacitance to handle larger current transients if the motor is stalled (due to impact, etc), there is still a bit higher risk of ESC burning out due to stall detection being a bit too late.

As for the xml to use as a starting point.. You can start with this one:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/D0020/m0138_3110_900kv_gemfan_10x4.5_tri.xml

This is tuned for a 6S application 3110-size 900kV motor with a 10x4.5 tri-blade motor (pretty powerful configuration). You will need to update:

voltage (6s to 4s) motor params (kv, rpm curve, etc) you can set the timing advance and sense advance from 20 to 0 (your application is likely not aggressive enough to require tweaking that), although you can do some bench testing to determine if you encounter de-syncs during large rpm transitions : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/doc/low_kv_motor_tuning.md you may need to adjust the spinup power / latch power -- generally keep it between 70-100 (7-10%) but when i tune this, i also usually find the minimum spin-up power that is able to reliably spin up the motor and then add a 10% extra (so 70->80). You can set spin-up power to a higher value in sinusoidal spin-up mode and it will produce a lot more torque, but will also consume more current. I usually try to limit a per motor spin-up current to 1-2 amps as a rule of thumb. for a fixed prop (not folding), your spin-up time can be anywhere between 500-1000ms, you can experiment. If you see the motor skipping during spinup and re-starting, you can increase either spin-up time or spinup power. may want to re-enable start-up beeps (disabled in this config) you can set kp (proportional gain) to 50 first (softer), then bump up to 100 or so, as you build confidence. higher kp will result in snappier response (faster than traditional ESCs without rpm control) but will also draw more current during transitions.

(with M0138, you should not need to add more bulk capacitance to ESC power).

With correctly tuned sinusoidal spin-up procedure, it should work pretty much 100% of the time (spin up on the first try every time). If you are seeing some inconsistent spin-up behavior, then it is possible there is some parameter issue and it needs to be investigated.

When you get your M0138, i suggest updating the params per my notes above and doing some bench testing using voxl-esc tools where you just spin up and stop motors many times in a row and make sure the spin-up is reliable.

Please let me know if you have any other questions!

Alex

@YUUJI-INOUE
This is the setup I did for stable operation, please let me know if there are any mistakes.

Stinger (VOXL 2 Mini) VIO Setup Guide

This document provides instructions for setting up a stable VIO (Visual Inertial Odometry) environment on the ModalAI Stinger (equipped with VOXL 2 Mini).
It focuses on SDK version selection and correct configuration commands for the D0013 build to ensure reliable autonomous flight.

1. Prerequisites Drone: ModalAI Stinger (VOXL 2 Mini) Configuration ID: D0013 (Stinger V2) PC Environment: Linux/Ubuntu with ADB (Android Debug Bridge) installed Network: Internet connection required for the drone (via Wi-Fi) for apt-get operations 2. SDK Version Check and Installation

IMPORTANT: Development versions (Alpha/Beta) of the SDK may cause unstable VIO behavior. It is strongly recommended to use the Stable SDK 1.6.2.

2.1 Check Current Version

Connect to VOXL via ADB and check the version:

adb shell voxl-version # OR adb shell apt-cache policy voxl-suite

If you see versions like 1.6.3~alpha, you must downgrade.

2.2 Install SDK 1.6.2

Force install the stable version:

# Run inside VOXL shell or via adb shell adb shell "DEBIAN_FRONTEND=noninteractive apt-get install -y voxl-suite=1.6.2" 2.3 Install Required Libraries

To fix dependency issues with OpenVINS in SDK 1.6.2, install the voxl-ceres-solver library (libceres.so.2😞

adb shell "apt-get install -y voxl-ceres-solver"

Note: Without this, voxl-open-vins-server will fail to start.

3. Factory Reset and Configuration

Apply the correct presets for Stinger (D0013). Using these commands is more reliable than manual configuration.

3.1 Configure Extrinsics

Load the camera and IMU geometry for Stinger V2 (D0013).

adb shell "voxl-configure-extrinsics D0013_Stinger_V2" 3.2 Configure Vision Hub

Configure how VIO data is sent to PX4 using the Stinger-specific preset.

adb shell "voxl-configure-vision-hub factory_enable_vfc_pos_back_flow_d0013" 3.3 Configure OpenVINS

Reset the VIO server configuration.

adb shell "voxl-configure-open-vins factory_enable" 3.4 Configure PX4 Parameters

Load optimized PID gains and flight parameters for Stinger (D0013).

adb shell "voxl-configure-px4-params -n -p MRB-D0013" 3.5 Enable VIO (Official Helper)

Load the official parameter helper file for indoor VIO flight without GPS.

adb shell "voxl-configure-px4-params -n -f /usr/share/modalai/px4_params/v1.14/EKF2_helpers/indoor_vio_missing_gps.params" 3.6 Configure ESCs

Upload Stinger-specific ESC parameters.

adb shell "/usr/bin/voxl-esc setup_d0013"

If you encounter invalid option errors, use the manual python script method:

adb shell "systemctl stop voxl-px4 && cd /usr/share/modalai/voxl-esc-tools/ && python3 voxl-esc-upload-params.py --params-file ../voxl-esc-params/D0013/lumenier_2305_2400kv_GF_D90_4S.xml && systemctl start voxl-px4" 3.7 Change ESC Mode (Critical)

Change ESC control from RPM mode (default) to Power mode to ensure reliable motor startup.

adb shell "px4-param set VOXL_ESC_MODE 0" 3.8 Motor Test

WARNING: REMOVE PROPELLERS BEFORE TESTING

Spin Motor 0 (Front Right) for 2 seconds to verify ESC communication.

adb shell "systemctl stop voxl-px4" adb shell "cd /usr/share/modalai/voxl-esc-tools/ && python3 voxl-esc-spin.py --id 0 --power 15 --timeout 2 --skip-prompt True" adb shell "systemctl start voxl-px4" 4. Advanced Optimization (Critical for Stability) 4.1 OpenVINS Optimization (Stinger Specific)

To prevent data corruption and initialization errors on Stinger (D0013):

Disable imu_body_frame_mode. Change configuration folder to fpv. adb shell "sed -i 's/\"imu_body_frame_mode\":\ttrue/\"imu_body_frame_mode\":\tfalse/' /etc/modalai/voxl-open-vins-server.conf" adb shell "sed -i 's/starling2/fpv/g' /etc/modalai/voxl-open-vins-server.conf" 4.2 Stabilize Connection After Reboot

Prevent voxl-vision-hub from starting before voxl-open-vins-server is ready by adding a 10-second delay.

Edit /etc/systemd/system/voxl-vision-hub.service:

adb shell "sed -i 's/After=voxl-wait-for-fs.service/After=voxl-wait-for-fs.service voxl-open-vins-server.service/' /etc/systemd/system/voxl-vision-hub.service" adb shell "sed -i '/ExecStart=\/usr\/bin\/voxl-vision-hub/i ExecStartPre=\/bin\/sleep 10' /etc/systemd/system/voxl-vision-hub.service" 4.3 IMU Calibration

If VIO is unstable or the Web Portal Health Check shows "IMU Calibration Missing", perform calibration:

adb shell "voxl-calibrate-imu"

Follow the on-screen instructions to place the drone in 6 orientations.

5. Apply Changes and Reboot

After applying all settings, reboot the drone. A hard power cycle (unplug battery) is recommended to ensure all sensors reset correctly.

adb shell reboot 6. Verification 6.1 Check Services adb shell voxl-inspect-services

Ensure voxl-open-vins-server, voxl-vision-hub, and voxl-px4 are Running.

6.2 Check VIO in VOXL Portal

Access the VOXL Portal (via IP address) and check the VIO (3D View):

Orientation: Does the drone in the view verify Pitch/Roll/Yaw movements correctly? Position: Does the drone stay still in the view when the physical drone is stationary? (No drifting/divergence) 6.3 Check QGroundControl (QGC) Local Position: Is the drone icon visible on the map? Position Mode: Switch flight mode to Position. It should say "Ready to fly" or "Position mode enabled" (not "Rejected"). If you can enter Position mode without GPS, VIO is working. 7. Operational Best Practices Power On: After plugging in the battery, leave the drone static on a level surface for ~30 seconds. This allows the gyro to calibrate biases and services to start. Initialize VIO: Pick up the drone and move it in a large figure-8 motion to excite the IMU and cameras. Pre-flight Check: Do not take off until you can successfully switch to Position mode in QGC. Note: If initialization fails (rarely), perform a reboot. 8. Troubleshooting

Q. Cannot enter Position Mode on the ground ("Not Ready")
A. Check the following:

Run voxl-inspect-pose vvhub_body_wrt_local to see if VIO data is streaming. If no data, perform a hard reboot (battery pull) to fix timestamp sync issues. Set en_voa to false in voxl-vision-hub.conf to disable obstacle avoidance (can cause extrinsics errors). Ensure vio_pipe is set to ov.

@Alex-Kushleyev how do I go about buying replacement parts for the Stinger and the additional boards and cables to add the Hadron 640r?

@bendraper Edit /etc/modalai/voxl-vision-hub.conf and set "offboard_mode": "off"

@Peter-Lingås-0 ,

We did have a sample batch of color AR0144 global shutter cameras, but i think we probably run out of those. I can double check. Due to low demand, we are not actively supporting them.

For general object detection applications, i would recommend IMX412 camera (M0161 part number, for example). This camera is 4056x3040 resolution, but it also supports 2x2 binned mode. The advantage of using binned mode (for this context), is reducing the rolling shutter effect.

The amount of rolling shutter distortion / skew is a function of the readout time (time between the start of exposure of first line and last line). This time depends on the camera and specific operating mode.

However, the IMX412 camera in combination with VOXL2 supports a 2x2 binned mode where you get a 1920x1080 image with only about 4.2ms of rolling shutter skew, meaning there is only 4.2ms between the first and last line. You can see more details on the readout time for different modes here : https://docs.modalai.com/camera-video/low-latency-video-streaming/#camera-pipeline-latency-in-different-operating-modes

Additionally, the IMX412 camera module has M12 lens mount, which allows for more flexibility in lens choice as well as supporting generally large lenses, which will improve image quality as well.

Would this be an option for you or is having a global shutter camera a requirement?

Alex

@Moderator

Thank you for your reply.