Posts made by DronAlan

@DronAlan

Dear ModalAI Support Team,

I am writing to report a critical failure of my VOXL 2 Starling drone and to express my deep dissatisfaction with the product.

Incident Description:
While operating the drone in-flight, the system suffered a total collapse. The aircraft suddenly stopped responding to any commands, including all manual RC controller inputs. It was as if the CPU had completely frozen. As a direct result of this hardware/software failure, the drone crashed.

I am extremely disappointed with the build quality, as several plastic components shattered upon impact—an impact that was caused entirely by the drone’s own internal failure.

Current Technical Status:
Since the crash, the drone has become impossible to use. While the status LEDs appear normal, the communication bus automatically shuts down approximately 30 seconds after boot-up. This appears to be a critical hardware issue, possibly related to overheating or a sensor failure.

I managed to capture the following dmesg output during one of the brief 30-second connection windows before the system disables the interfaces:

starling (D0005):~$ dmesg | tail -n 50
[    7.787640] Started adbd. 
[    7.831722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    7.834130] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[    7.835626] QTI:Netlink Query to Kernel Success
[    7.845433] QTI:Netlink Query to Kernel Success
[    7.860899] QCMAP:Start DHCP server
[    7.871965] CAM_ERR: CAM-ISP: cam_ife_hw_mgr_print_acquire_info: 710 Successfully acquire single IFE[5 -1] with [0 pix] [0 pd] [1 rdi] ports for ctx:1
[    7.873469] CAM_INFO: CAM-CSIPHY: cam_csiphy_core_cfg: 1137 START_DEV: CSIPHY_IDX: 3, Device_slot: 0, Datarate: 384000000, Settletime: 2800000000
[    7.881706] CAM_INFO: CAM-ISP: cam_vfe_bus_ver3_init_hw: 3659 Overriding clock gating at bus input
[    7.881709] CAM_INFO: CAM-ISP: cam_vfe_top_ver3_init_hw: 246 Disable clock gating at IFE top
[    7.881717] CAM_ERR: CAM-ISP: cam_ife_mgr_start_hw: 4510 ->Config HW, 00000000931b72ed
[    7.882024] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 1089 CAM_START_DEV Success, sensor_id:0x7750,sensor_slave_addr:0xe2
[    7.899348] QCMAP:DHCP server started
[    8.018042] IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready
[    8.079637] QCMAP:GSB disabled
[    8.098746] QCMAP:Init Complete
[    8.102721] QTI:Netlink Query to Kernel Success
[    8.833992] msm_vidc:   err : ffffffff: .....: DBLP Set: status 0
[   12.338705] i2c_geni 988000.i2c: i2c error :-107
[   12.367696] i2c_geni 988000.i2c: i2c error :-107
[   12.614463] RTW: wlan0- hw port(0) mac_addr =00:c0:ca:b3:a3:c7
[   12.659978] RTW: rtw_set_802_11_connect(wlan0)  fw_state=0x00000008
[   12.825582] RTW: start auth
[   12.826322] RTW: auth success, start assoc
[   12.827464] RTW: assoc success
[   12.830723] RTW: ============ STA [f0:09:0d:da:f4:f4]  ===================
[   12.830725] RTW: mac_id : 0
[   12.830727] RTW: wireless_mode : 0x44
[   12.830729] RTW: mimo_type : 0
[   12.830730] RTW: static smps : N
[   12.830733] RTW: bw_mode : 80MHz, ra_bw_mode : 80MHz
[   12.830735] RTW: rate_id : 10
[   12.830737] RTW: rssi : -1 (%), rssi_level : 0
[   12.830739] RTW: is_support_sgi : Y, is_vht_enable : Y
[   12.830740] RTW: disable_ra : N, disable_pt : N
[   12.830742] RTW: is_noisy : N
[   12.830743] RTW: txrx_state : 0
[   12.830746] RTW: curr_tx_rate : CCK_1M (L)
[   12.830748] RTW: curr_tx_bw : 20MHz
[   12.830750] RTW: curr_retry_ratio : 0
[   12.830751] RTW: ra_mask : 0x00000000003ffff0
[   12.840829] RTW: recv eapol packet 1/4
[   12.841329] RTW: send eapol packet 2/4
[   12.843888] RTW: recv eapol packet 3/4
[   12.844194] RTW: send eapol packet 4/4
[   12.849264] RTW: set pairwise key camid:0, addr:f0:09:0d:da:f4:f4, kid:0, type:AES
[   12.853095] RTW: set group key camid:1, addr:f0:09:0d:da:f4:f4, kid:1, type:AES
[   33.760144] usb30_prim_gdsc: disabling
[   33.762015] vdd_tof: disabling
[   33.762018] vdd_hap_boost: disabling

I think the most important lines are:

starling (D0005):~$ dmesg | tail -n 50
[    7.787640] Started adbd. 
[    7.831722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    7.834130] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
...
[   12.338705] i2c_geni 988000.i2c: i2c error :-107
[   12.367696] i2c_geni 988000.i2c: i2c error :-107
...
[   33.760144] usb30_prim_gdsc: disabling
[   33.762015] vdd_tof: disabling
[   33.762018] vdd_hap_boost: disabling

Analysis:
The log shows multiple I2C errors (-107) followed by the system disabling critical power rails (usb30_prim_gdsc and vdd_tof) at the 33-second mark. This confirms a hardware-level failure that likely originated during flight, causing the total loss of control.

Request:
In light of this situation, I would truly appreciate your guidance on how to proceed. Since the drone is currently unresponsive and shows these internal errors, I would like to know if it would be possible to send the unit back to your facilities for a professional inspection.

I am very interested in a repair or a full revision of the board and the damaged plastic parts, as I would love to have the drone back in working order. Could you please let me know what options are available for this case and what the next steps would be to initiate a check-up?

Thank you very much for your time and for any help you can provide. I look forward to hearing from you soon.

Best regards,

Alan

I am reporting a critical connectivity failure with my VOXL 2 drone (Starling model).

While operating the drone, it suddenly stopped responding to all commands. Currently, the device appears to be powered on as all status LEDs are active and showing their normal patterns, but there is a complete lack of data communication.

Problem Details:

No ADB detection: The device is not detected by adb devices, sometimes yes, but avergane no, i dont understand. I have tested several verified data cables and different USB ports on my workstation.

SSH unreachable: The drone does not connect to the network and is not reachable via SSH.

Suspected Issue:
Since the status LEDs indicate the board is receiving power and attempting to run, but there is zero data throughput via USB or Wi-Fi, I suspect a factory defect or a hardware failure in the communication bus (USB/Wi-Fi controller). The device seems to have "locked up" internally regarding its external interfaces.

@Cliff-Wong Yes, I can confirm that flying manually in Position mode works correctly and accurately follows the XYZ coordinates shown in the voxl-portal VIO page. Additionally, the drone successfully performs the figure 8 trajectories in offboard mode as expected.

@Cliff-Wong

{
"config_file_version": 1,
"en_localhost_mavlink_udp": false,
"localhost_udp_port_number": 14551,
"en_vio": true,
"vio_pipe": "qvio",
"secondary_vio_pipe": "ov",
"vfc_vio_pipe": "ov",
"en_reset_vio_if_initialized_inverted": true,
"vio_warmup_s": 3,
"send_odom_while_failed": true,
"horizon_cal_tolerance": 0.5,
"en_hitl": false,
"offboard_mode": "figure_eight",
"follow_tag_id": 0,
"figure_eight_move_home": true,
"robot_radius": 0.300000011920929,
"collision_sampling_dt": 0.1,
"max_lookahead_distance": 1,
"wps_move_home": true,
"wps_stride": 0,
"wps_timeout": 0,
"wps_damp": 1,
"wps_vfc_mission": true,
"wps_vfc_mission_loop": false,
"wps_vfc_mission_to_ramp": 25,
"wps_vfc_mission_to_kp": 0.10000000149011612,
"wps_vfc_mission_cruise_speed": 1,
"tracking_trigger_ch": 12,
"tracking_trigger_ch_thresh_temp": 1200,
"tracking_trigger_ch_thresh_new": 1800,
"en_tag_fixed_frame": false,
"fixed_frame_filter_len": 5,
"en_transform_mavlink_pos_setpoints_from_fixed_frame": false,
"en_voa": true,
"voa_upper_bound_m": -0.15000000596046448,
"voa_lower_bound_m": 0.15000000596046448,
"voa_voa_memory_s": 1,
"voa_max_pc_per_fusion": 100,
"voa_pie_max_dist_m": 20,
"voa_pie_min_dist_m": 0.25,
"voa_pie_under_trim_m": 1,
"voa_pie_threshold": 3,
"voa_send_rate_hz": 20,
"voa_pie_slices": 36,
"voa_pie_bin_depth_m": 0.15000000596046448,
"voa_inputs": [{
"enabled": true,
"type": "point_cloud",
"input_pipe": "dfs_point_cloud",
"frame": "stereo_l",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}, {
"enabled": true,
"type": "point_cloud",
"input_pipe": "stereo_front_pc",
"frame": "stereo_front_l",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}, {
"enabled": true,
"type": "point_cloud",
"input_pipe": "stereo_rear_pc",
"frame": "stereo_rear_l",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}, {
"enabled": true,
"type": "tof",
"input_pipe": "tof",
"frame": "tof",
"max_depth": 6,
"min_depth": 0.15000000596046448,
"cell_size": 0.079999998211860657,
"threshold": 3,
"x_fov_deg": 106.5,
"y_fov_deg": 85.0999984741211,
"conf_cutoff": 125
}, {
"enabled": true,
"type": "rangefinder",
"input_pipe": "rangefinders",
"frame": "body",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}]
}

this is my /etc/modalai/voxl-vision-hub.conf, what should i change????

@Cliff-Wong

I am experiencing a severe issue with trajectory execution in the SLAM/Mapper mode where the drone exhibits an inverted and cumulative 'mirror' behavior regarding position setpoints.

As shown in the attached image:

1. If I set a first waypoint directly in front of the drone (1st Point), the drone flies backward instead, covering the intended distance but in the exact opposite direction.
2. From that new incorrect position, if I command the drone to return backward by the same distance (2nd point, aiming to return to the original starting location), the drone does not return. Instead, it flies forward, doubling the distance in the opposite direction from the newly commanded point.

It appears as though the drone is accumulating a starting error or interpreting the coordinate frame in a completely mirrored way (FRD vs NED mismatch), where both the direction and the origin reference point are inverted. The dashed lines in the image represent the intended path, while the solid arrows represent the actual path flown. I am on SDK 1.6.3 with factory settings.

@Cliff-Wong

I have just updated to SDK 1.6.3 doing a complete wipe and applying the factory configuration, but the drone is still executing the trajectory in reverse/backwards. I really don't know what else to try at this point. Any ideas on what could be causing this inverted behavior despite the clean install?

@Cliff-Wong said in tarling - Path planning (blue line) is erratic and drone moves to wrong locations:

/etc/modalai/vio_cams.conf

Hi there, thanks for the detailed suggestions!

I have gone through all your steps to discard physical and configuration issues, but it seems I'll need to upgrade. Here is the checklist of what I tested:

1. Camera orientation: I checked the front camera in voxl-portal and it is completely upright (tops are aligned, ceiling is up, floor is down).

2. Physical mounts: The VOXL 2 unit is mounted correctly from the factory (USB-C port facing the ground, WiFi dongle on the top side).

3. IMU Calibration: I ran a full 6DOF voxl-calibrate-imu on a flat surface. It completed successfully, and voxl-inspect-imu shows perfect readings now (X and Y at ~0.00, and Z gravity at exactly -9.80).

4. VIO config: I checked /etc/modalai/vio_cams.conf. tracking_down is disabled/not present, and it is only using the front camera as expected. Here is my exact configuration:

{
"cams": [{
"enable": true,
"name": "tracking",
"pipe_for_preview": "tracking",
"pipe_for_tracking": "tracking",
"is_occluded_on_ground": false,
"imu": "imu_apps",
"cal_file": "opencv_tracking_intrinsics.yml"
}]
}

Since all physical and configuration checks passed perfectly, I am going to follow your advice and proceed to flash SDK 1.6.3 to take advantage of the advanced config installer and move to OpenVINS.

Thanks again for the help, I'll keep you posted on how the 1.6.3 update goes!

@Cliff-Wong please response

@Cliff-Wong

Hi,

Thank you for the detailed response and suggestions. I have carefully followed all the steps you mentioned, but unfortunately, the issue persists.

Here is what I did:

1. I edited /etc/modalai/voxl-vision-hub.conf to set the reset parameter to false. Here is my current file:

{
"config_file_version": 1,
"en_localhost_mavlink_udp": false,
"localhost_udp_port_number": 14551,
"en_vio": true,
"vio_pipe": "qvio",
"secondary_vio_pipe": "ov",
"vfc_vio_pipe": "ov",
"en_reset_vio_if_initialized_inverted": false,
"vio_warmup_s": 3,
"send_odom_while_failed": true,
"horizon_cal_tolerance": 0.5,
"en_hitl": false,
"offboard_mode": "trajectory",
"follow_tag_id": 0,
"figure_eight_move_home": true,
"robot_radius": 0.300000011920929,
"collision_sampling_dt": 0.1,
"max_lookahead_distance": 1,
"backtrack_seconds": 60,
"backtrack_rc_chan": 8,
"backtrack_rc_thresh": 1500,
"wps_move_home": true,
"wps_stride": 0,
"wps_timeout": 0,
"wps_damp": 1,
"wps_vfc_mission": true,
"wps_vfc_mission_loop": false,
"wps_vfc_mission_to_ramp": 25,
"wps_vfc_mission_to_kp": 0.10000000149011612,
"wps_vfc_mission_cruise_speed": 1,
"en_tag_fixed_frame": false,
"fixed_frame_filter_len": 5,
"en_transform_mavlink_pos_setpoints_from_fixed_frame": false,
"vfc_rate": 100,
"vfc_rc_chan_min": 980,
"vfc_rc_chan_max": 2020,
"vfc_thrust_ch": 3,
"vfc_roll_ch": 1,
"vfc_pitch_ch": 2,
"vfc_yaw_ch": 4,
"vfc_submode_ch": 6,
"vfc_alt_mode_rc_min": 0,
"vfc_alt_mode_rc_max": 0,
"vfc_flow_mode_rc_min": 0,
"vfc_flow_mode_rc_max": 0,
"vfc_hybrid_flow_mode_rc_min": 0,
"vfc_hybrid_flow_mode_rc_max": 0,
"vfc_position_mode_rc_min": 0,
"vfc_position_mode_rc_max": 2100,
"vfc_traj_mode_rc_min": 0,
"vfc_traj_mode_rc_max": 0,
"vfc_yaw_deadband": 30,
"vfc_vxy_deadband": 50,
"vfc_vz_deadband": 150,
"vfc_min_thrust": 0,
"vfc_max_thrust": 0.800000011920929,
"vfc_tilt_max": 0.43599998950958252,
"vfc_yaw_rate_max": 3,
"vfc_thrust_hover": 0.5,
"vfc_vz_max": 1,
"vfc_kp_z": 5.2899999618530273,
"vfc_kd_z": 5.9800000190734863,
"vfc_vxy_max": 3,
"vfc_kp_xy": 0.63999998569488525,
"vfc_kd_xy": 2.559999942779541,
"vfc_kp_z_vio": 5.2899999618530273,
"vfc_kd_z_vio": 5.9800000190734863,
"vfc_kp_xy_vio": 3.2400000095367432,
"vfc_kd_xy_vio": 3.9600000381469727,
"vfc_w_filt_xy_vio": 10,
"vfc_w_filt_xy_flow": 3,
"vfc_vel_ff_factor_vio": 0.899999976158142,
"vfc_xy_acc_limit_vio": 2.5,
"vfc_max_z_delta": 3,
"vfc_att_transition_time": 0.5,
"vfc_stick_move_threshold": 30,
"vfc_flow_transition_time": 1,
"vfc_q_min": 10,
"vfc_points_min": 7,
"vfc_en_submode_announcement": 1,
"vfc_disable_fallback": false,
"vfc_traj_csv": "/data/voxl-vision-hub/traj.csv",
"en_voa": true,
"voa_upper_bound_m": -0.15000000596046448,
"voa_lower_bound_m": 0.15000000596046448,
"voa_voa_memory_s": 1,
"voa_max_pc_per_fusion": 100,
"voa_pie_max_dist_m": 20,
"voa_pie_min_dist_m": 0.25,
"voa_pie_under_trim_m": 1,
"voa_pie_threshold": 3,
"voa_send_rate_hz": 20,
"voa_pie_slices": 36,
"voa_pie_bin_depth_m": 0.15000000596046448,
"voa_inputs": [{
"enabled": false,
"type": "point_cloud",
"input_pipe": "dfs_point_cloud",
"frame": "stereo_l",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}, {
"enabled": false,
"type": "point_cloud",
"input_pipe": "stereo_front_pc",
"frame": "stereo_front_l",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}, {
"enabled": false,
"type": "point_cloud",
"input_pipe": "stereo_rear_pc",
"frame": "stereo_rear_l",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}, {
"enabled": true,
"type": "tof",
"input_pipe": "tof",
"frame": "tof",
"max_depth": 6,
"min_depth": 0.15000000596046448,
"cell_size": 0.079999998211860657,
"threshold": 3,
"x_fov_deg": 106.5,
"y_fov_deg": 85.0999984741211,
"conf_cutoff": 125
}, {
"enabled": false,
"type": "rangefinder",
"input_pipe": "rangefinders",
"frame": "body",
"max_depth": 8,
"min_depth": 0.300000011920929,
"cell_size": 0.079999998211860657,
"threshold": 4,
"x_fov_deg": 68,
"y_fov_deg": 56,
"conf_cutoff": 0
}]
}

2. I forced the VIO reset right before takeoff.
I ran systemctl restart voxl-qvio-server via SSH just as you suggested, keeping the drone perfectly still on the ground.

3. I verified the extrinsics settings.
I checked /etc/modalai/extrinsics.conf and confirmed that the body to imu parameter is indeed [0, 0, 0].
Here is my current extrinsics file:
{
"name": "starling_v2_voxl2",
"extrinsics": [{
"parent": "imu_apps",
"child": "tracking",
"T_child_wrt_parent": [0.0229, 0.006, 0.023],
"RPY_parent_to_child": [0, 45, 90]
}, {
"parent": "body",
"child": "imu_apps",
"T_child_wrt_parent": [0.0407, -0.006, -0.0188],
"RPY_parent_to_child": [0, 0, 0]
}, {
"parent": "body",
"child": "tof",
"T_child_wrt_parent": [0.068, -0.0116, -0.0168],
"RPY_parent_to_child": [0, 90, 180]
}, {
"parent": "body",
"child": "lepton0_raw",
"T_child_wrt_parent": [-0.06, 0, 0.01],
"RPY_parent_to_child": [0, 0, 90]
}, {
"parent": "body",
"child": "ground",
"T_child_wrt_parent": [0, 0, 0.0309],
"RPY_parent_to_child": [0, 0, 0]
}]
}

Despite doing all of this, the 180-degree rotation (mirror effect) is still happening.

Given that these steps didn't resolve the issue and you mentioned that these anomalies have been corrected in newer versions, would you recommend that my best course of action right now is to flash the drone and upgrade to SDK 1.6.x (or newer) to use the new OpenVINS subsystem?

I would also appreciate it if you could take a look at the files I sent you in this message to make sure everything is correct.

One more thing:

Looking at my SKU (MRB-D0005-4-V2...), is it possible that the tracking camera or the IMU was physically mounted 180° rotated at the factory?

If this is a known hardware discrepancy for this specific batch, should I manually compensate for it in the extrinsics or will the SDK 1.6.x upgrade fix it automatically?

Thanks again for your help!

@DronAlan

Now he's doing it the other way around, I don't understand anything

@DronAlan

Just one more quick detail to add: this behavior is not constant. Sometimes the drone executes the trajectory perfectly fine, and other times it does the opposite thing and goes to (-1,-1).

@Cliff-Wong said in tarling - Path planning (blue line) is erratic and drone moves to wrong locations:

voxl-inspect-qvio -n

As requested, here is the system information and SKU from the splash screen:

• system-image: 1.8.04-M0054-14.1a-perf
• kernel: #1 SMP PREEMPT Mon Mar 24 21:47:11 UTC 2025 4.19.125
• hw platform: M0054
• mach.var: 1.0.0
• SKU: MRB-D0005-4-V2-C6-T7-M0-X0
• voxl-suite: 1.5.0

While optimizing the CPU usage helped stabilize the services, I am now experiencing a new flight behavior that perfectly aligns with your suspicion about an extrinsics error. When I command the drone (via offboard mode) to go to position (1, 1), it physically flies in the exact opposite direction to (-1, -1). It seems its internal orientation is completely inverted or mirrored.

Given my specific SKU, what is the correct procedure to fix this extrinsics orientation? Are there specific rotation matrices or parameters I need to change in /etc/modalai/extrinsic_config.txt, voxl-camera-server, or voxl-vision-hub so that "forward" matches the physical front of the drone?

Thanks again for your continuous support!

Hi @Cliff-Wong ,

Thank you so much for your detailed response and help! Actually, I have some great news: it is working now! Before I saw your message, I had already performed most of those resets and reconfigurations because I noticed something critical: the CPU was completely saturated. When running voxl-inspect-services, several services (especially the portal and mapper) were maxing out the CPU with percentages in red.

Once I managed to clean up the configurations, restart the pipes, and get the CPU usage back to normal, stable levels (no red percentages in the inspector), the drone started behaving correctly. I tested the trajectory planning and it executed it decently. There is still a tiny bit of error/drift, but it is much more reliable now and no longer going crazy.

I really appreciate your troubleshooting steps regarding the extrinsics and the VIO resets, it's great to know how to diagnose those for future tests. Thanks again for the support!

Hi,

I am having significant issues with the voxl-mapper on a Starling drone. When using the "Plan to a Point" feature in the VOXL Web Portal, the system fails to calculate or execute a reliable path.

Even in a clear environment, after clicking "Plan to a Point", the calculated trajectory (blue line) becomes erratic. Instead of following the direct path, the drone often moves to incorrect locations, diverges from the intended target, or the planning simply fails to produce a viable route.

Hardware Details (Starling):

1. Flight Controller/Compute: VOXL 2 (MDK-M0054-1)

2. ToF Sensor: MDK-M0040 (PMD)

3. Tracking Sensor: ov7251

4. VIO: voxl-qvio-server (Stable)

Why is the path planner generating such erratic trajectories instead of a direct path to the waypoint? Are there specific tuning parameters for the Starling's ToF setup to make the planner more reliable?

Thanks