@Nikos-Mavr You're welcome! And can you please start a new forum post for this new issue? Thanks!

@Myles-Levine , if you are masking out 90% of down-facing camera, then it is probably useless any movement of the features will get it out of the unmasked region very easily and feature will be dropped.. It may hurt VIO as there may be features going in and out, only trackable for a few frames (just adds to the complexity).

You should try to move the down-facing camera to free up it's FOV or even have it facing slightly angled to the back of the drone..

Alex

Hi @austin-c ,

I ran some tests with Tmotor MN4006-23 380kV and 15-inch MS1503 propeller, using M0138 ESC. Tests were done with a battery and a power supply. Please see results below.

the colors may vary from plot to plot, but the one with slower deceleration is "regen off" 🙂 did not run large rpm steps on power supply because the power supply was already current limited regen peaks were 31V (pwm step) and 33V (rpm step) for the power supply test motor acceleration is almost identical for regen on/off tests very large difference in motor deceleration, especially for the large high-to-low rpm transitions also note that the power supply tests result in slower deceleration even with regen on (because the power supply cannot sink the current) TVS diode did not blow out in this test, because the spikes were short and only a few at a time

Please note that, in theory, it is possible to decelerate the motor faster without regenerative braking (by applying more power, but out of phase), however we do not have this implemented.

If the motor deceleration is slowed down due to lack of regenerative braking, the attitude control will be affected because the motor response is highly asymmetric for acceleration vs deceleration. Overall, this will result in effectively reducing the average responsiveness of the motor, so you would need to decrease control gains and probably will not be able to handle large disturbances very well and cause oscillations if not tuned properly.

Please review the plots (which are not surprising), and we can discuss further..

Alex

6S battery, Power step test:
75e2acb0-7505-4f57-9ad0-607768c923cf-image.png

6S battery, RPM small step test
e5e02d3a-ac63-4fbf-b8e6-b64d4b33f983-image.png

6S battery, RPM large step test
7b2f7b28-6825-4498-908e-68353de9fa79-image.png

11A Power Supply, Power step test:
d6888452-1155-4567-8309-a994d7d717ff-image.png

11A Power Supply, RPM small step test
d88b5433-2756-42c7-9de6-804bbef8b814-image.png

@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!

@emarcphera @Eric-Katzfey thank you so much after upgrading to voxl-mainline im getting GPS readingScreenshot from 2026-02-28 01-45-10.png

@Eric-Katzfey
We will look into updating the sdk, but that's always a fair bit of work.

@bendraper
Hello,
I hope this quick clarification helps for warnings:

CMake Policy warnings: OV internally (external dir in the repo) still uses boost and references an older cmake version -- it's a harmless warning for devs (as you are building from scratch)

Yaml-cpp lib warnings: This is a third party dependency that gets compiled from scratch during the make/build process. We use C++ 17 but the library is based on an older C++ version; nevertheless, it compiles fine on C++ 17 with minor warnings. -- it's a harmless warning

TrackOCL warning: ModalFlow is a core library written in C++ 17 that allows function call usage as done in TrackOCL, i.e., the narrowing conversion is harmless in this case.

That being said, we are actively working on the dev branch, so all flight--impacting warnings are hopefully caught early. We currently have no flight-impacting warnings/bugs identified, but if you found one warning/bug that caught your attention, please feel free to share.

All the best,
ZBFT

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads

Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.

@Alex-Kushleyev The Alfa Network AWU2036

@qubotics-admin First you need to determine the version of PX4 running. With ssh or adb you can run the following at the command line: px4-ver all. You will see PX4 version and Vendor version. So, for example, for px4 version 1.14.0 and vendor version 8.134.3 then you would checkout the tag v1.14.0-8.134.3-dev from the repo to see that commit.

@ndwe Whether you use a VOXL or Jetson as a companion computer shouldn't make any difference unless you want to use the VOXL SDK. The version you run is totally up to you. If our v1.14.0 based version works for you then use it. We do plan to transition to v1.17.x in the near future. I don't think the issues you are seeing are related to something specific in the flight core v2 hardware setup. I would think that if you swapped it out for some other brand you would see the same issue. I would ask on the PX4 forums to see if others have experienced the same issues.

Hi @Alex-Kushleyev, sorry for the late reaction, it took some time before i could update to the new SDK (1.6). the system now works normally with the resolution 2704x1540, and downscaled to 1920x1080 for the MISP pipeline. Thanks for the help!

@Piyush-Singh , can you please provide more details

how exactly all cameras are connected to VOXL2 mini (including interposers, flexes), etc. A diagram would help a lot which kernel variant are you running on your voxl2 mini (2.0.0 or 2.0.2).

Are all the other cameras working if you disable the TOF sensor in the camera server config?

Alex

@cbay voxl-fpv-px4 is based on voxl-px4 but has some custom tuning code / parameters for our fpv drones that isn't in voxl-px4. So, it's kind of a superset. But there isn't anything related to low level i2c drivers so I have no idea how that could be causing this issue.

@Jetson-Nano , since we currently have no plans to do the MIPI integration of this sensor, you always have the option to use USB connection and voxl-uvc-server to publish images via MPA. You would need to check if the sensor supports the standard UVC interface and try it out...

Alex

@Alex-Kushleyev Thank you for the hint. We have fixed the issue by changing the resolution to 2704x1540 in the voxl-camera-server.conf. Now, the actual DFOV is 150°.

Hi @Vinny

Thank you for your reply! That's good news:)
We are looking forward to it!

@colombe-ai , please see https://forum.modalai.com/topic/5116/gnss-emi-mitigation-guidelines

@Alex-Kushleyev Thanks Alex, very helpful!

@Maxwell-Schaefer Thanks for your reply. Is this step also applicable for the BetaFPV Nano RX? Should this also used ModalAI's firmware repo? Or will this use BetaFPV's? I did look into trying to flash the Nano RX initially, but stopped short of doing it as the physical RX itself did not have a BetaFPV silkscreen on it, so I assumed that it might be using a different firmware from the stock BetaFPV

Are you able to advise on the other queries regarding the new wifi adapter board?