ModalAI Forum

Hello,

Hope you are doing well and having a great week!

Hardware: Starling 2

What I am trying to do:
We are developing autonomous flight missions using the Starling 2. During testing, one original motor (1504 3000KV, PN: M10000633) suffered physical wear on the upper bell (stripped screw hole causing vibration). Additionally, our original battery was damaged.

Since we lack micro-soldering capabilities in our lab, we strictly prefer a solution without desoldering/soldering motor phase cables. Due to international HAZMAT shipping restrictions for LiPo batteries to Europe, we also aim to source battery replacements locally.

Questions:

1. Bell Replacement Compatibility: If we purchase the 1503 2900KV (M10001231) replacement motor, can we swap just its upper bell onto our existing 1504 3000KV stator/base without shaft/magnet alignment issues?
2. Mixing Motors: Can the PX4/autonomy stack handle mixing one 1503 2900KV motor with three remaining 1504 3000KV motors without causing flight instability?
3. European / Third-Party Alternatives: Do you officially support any commercial alternatives (e.g., iFlight, T-Motor, BetaFPV)? How significantly would transitioning to 4 identical third-party motors impact factory PID tunes on the VOXL board?
4. Battery Specs for EU Sourcing: What are the exact discharge specs (continuous/burst C-rating, chemistry/LiHV vs standard LiPo) for the M10000538 battery so we can source an equivalent locally in Europe?

Thank you in advance for your help and support!

Hi @alex-kushleyev ,

Thank you for the clear guidance and the two options.

We have already applied Option 1 for the Apps Proc IMU:

Rebuilt and installed voxl-imu-server with #define EN_RTC disabled
voxl-inspect-imu imu_apps now reports healthy accel/gyro data (~9.8 m/s² at rest)
No more “clock line / PCB damage” warnings on that path
However, PX4 flight IMU is still down:

px4-listener sensor_accel / sensor_gyro publish no samples
pre_flight_checks_pass: false
Platform: Starling 2 / VOXL2 M0054, system-image 1.8.06, voxl-px4 1.14.0-2.0.133
We are blocked on rebuilding voxl-px4 / SLPI because we do not have access to the Hexagon SDK (asset 184) on our side, and we cannot redistribute it.

Could you please help with one of the following?

Provide a prebuilt voxl-px4 .deb (compatible with our 1.8.06 / 2.0.133 line, or current recommended) with EN_RTC disabled in the SLPI ICM42688P driver, or
Confirm the exact Hexagon SDK package / process we should use if we must build it ourselves, or
If software is not feasible, please advise on the fastest path for VOXL2 board replacement / RMA for this commercial pilot.
Happy to share logs, voxl-version, and package list if useful.

Thanks again for your support,
Luis

Hi @Alex-Kushleyev,

I wanted to follow up on this as we are currently in a critical phase of our commercial pilot deployment, and having the Starling 2 grounded is severely impacting our timeline.

Given the voxl-imu-server logs and the pictures provided, is there any specific software workaround, service configuration, or hardware adjustment we can try to restore the IMU functionality?

If you determine that the board requires factory repair or replacement, please let us know how we can expedite the RMA process to get operational again as soon as possible.

Thank you for your support,
Luis

Hi @Alex-Kushleyev ,

My apologies for the confusion. To be precise: we didn't add any third-party or custom heatsink. However, to replace the damaged 4K and ToF camera flex cables, we did have to unscrew the VOXL 2 board from the frame to access the connectors safely.

Once the new cables were plugged in and the board was screwed back into place, the ICM42688 PCB damage / clock line disconnected error appeared.

I have attached the pictures of the current assembly inside our Starling 2 so you can verify that the M0054 board, the integrated cooling plate, and all camera flex cables are correctly in place and undamaged from the outside.

Given the log and the pictures, what do you propose we do to get the drone operational again?

Regards,
Luis

Hello everyone,
We are running a Starling 2 (SDK 1.8.06) for a commercial pilot deployment. After performing a careful sensor maintenance and mounting the official heatsink back on the VOXL2 (M0054), PX4 is completely blocked and unable to pass pre-flight checks.

The voxl-health-check reports sensor_accel and sensor_gyro as 0, 0, 0 (result: False). Checking journalctl -u voxl-imu-server, we are getting the exact hardware fault described in your official forums:

trying ICM42688 on bus 3 ERROR in test_basic_read, read the same values twice WARNING initializing 42688, clock line may be disconnected, trying to turn it off 42688 IMU works without clock line, this indicates PCB damage

We have already tried loosening the heatsink screws carefully to release any potential mechanical PCB stress, performing cold boots, and restarting the services, but the error persists. The clock line buffer seems permanently damaged, rendering the autopilot blind.

What can we do?

Thank you for your swift support,

@Eric-Katzfey I’m looking for the voxl-emulator Docker image referenced in the documentation:

VOXL Emulator Documentation: https://docs.modalai.com/voxl-emulator/#install-the-voxl-emulator-docker-image

However, in the Development Sources / Developer Portal there doesn’t seem to be any Docker image available for voxl-emulator.

Could you please confirm if the image is still available, or if there is an updated download location for it?

Hi everyone,

In the documentation, it mentions that there is a prebuilt simulation image/environment available for running simulated tests with the VOXL platform. However, we have not been able to find the image or download link anymore.

Could you please provide:

• The current simulation image list item
• The recommended simulation environment
• Or updated instructions/repos for running simulations

If the original image is deprecated, any updated alternative would be greatly appreciated.

Thanks in advance!

Hi everyone,
We are experiencing a critical issue with VIO stability on a VOXL2-based indoor drone platform.

Problem

When the drone starts gaining altitude, the VIO becomes unstable and the drone quickly becomes impossible to control manually. During hover close to the ground, the drone is relatively stable, but once altitude increases:

• Position estimation starts drifting
• list itemYaw estimation becomes unstable
• list itemHeight estimation errors appear
• list itemManual control becomes very difficult or impossible
• list itemPX4 eventually reports preflight or estimator failures

Current Setup
Hardware:
VOXL2
Starling 2 platform
Indoor environment
No GPS
Manual flight mode
QVIO enabled

Environment conditions:

Metallic industrial environment
Low texture surfaces
Variable lighting conditions
Errors observed

We frequently see:

Preflight Fail: height estimate not stable
Preflight Fail: Yaw estimate error
Preflight Fail: Attitude failure (pitch)

Additional Notes
We are NOT using QGroundControl during flight
The issue appears mainly when ascending
Near the ground the drone behaves much better
The instability increases progressively with altitude
It feels like VIO loses enough visual references when moving away from the floor

Questions
Is this a known limitation of QVIO / tracking camera placement?
Could this be related to insufficient floor texture?
Are there recommended tuning parameters for altitude-related instability?
Should we reduce dependency on QVIO and fuse additional sensors?
Would adding downward lighting or a ToF sensor significantly improve stability?
Is there a recommended EKF2 configuration for industrial indoor environments?