Topics created by Kashish Garg 0

@Kashish-Garg-0 It's possible your board has a QSM8250 (M0054-2) instead of a QRB5165 (M0054-1), see here for the diffs: https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2

If that is the case then you will have to QDL using a different build, which you can download from downloads.modalai.com, look for M0054-2 Starling QDL Image 1.7.4 2024-02-09-1.7.4-M0054-2.zip under the "All" category

@Kashish-Garg-0

You might be able to find the raw lens parameters here

The PMD libraries use those calibrations to adjust the point cloud data, so it may be corrected prior to being published as a depth map or point cloud. We have not used those lens parameters directly ourslves.

Hello @Kashish-Garg-0

we have a curve that is "motor voltage vs rpm", meaning that for a desired RPM, it tells the ESC what average motor voltage should be applied. The average motor voltage is defined as battery_voltage * motor_pmw_duty_cycle. The battery voltage in this curve is in millivolts. Since you are typically controlling the desired RPM, as a user you do not need to worry about what "throttle" or voltage to apply - the ESC does this automatically in order to achieve the desired RPM. this calibration curve is used as a feed-forward term in the RPM controller. The ESC does support an "open loop" type of control where you specify the power from 0 to 100%, which is similar to a standard ESC, but PX4 does not use that ESC control mode.

By the way, you can test the ESC directly (not using PX4) using our voxl-esc tools (https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/tree/master/voxl-esc-tools) which works directly on VOXL2 or a standalone linux PC (or mac). voxl-esc-spin.py has a --power argument where you specify the power from 0 to 100, which translates directly to the average duty cycle applied to the motor.

Here is the calibration for the Starling V2 motor / propeller that we use:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/mavic_mini_2/mavic_mini_2.xml?ref_type=heads#L63

Also, you can take a look at this post to see how to interpret those parameters a0, a1, a2 : https://forum.modalai.com/topic/2522/esc-calibration/2

We also have some dyno tests for this motor / propeller : https://gitlab.com/voxl-public/flight-core-px4/dyno_data/-/blob/master/data/mavic_mini2_timing_test/mavic_mini2_modal_esc_pusher_7.4V_timing0.csv . We are not sure how accurate that is, but it can be used as a starting point. @James-Strawson can you please confirm that is the correct dyno data for the Starling V2 motors?

Alex

@Kashish-Garg-0

Yes, everything in the aerospace industry including PX4 and ardupilot use the standard NED coordinate frame with Z pointing down. A significant portion of the code in MAVROS seems to be flipping the direction of the Y and Z axis back and forth when converting from mavlink to ros topics.

I suggest using the vvhub_body_wrt_local pipe instead of the qvio pipe as the qvio data is centered around the imu whereas voxl-vision-hub transforms this to be centered around the body (COG) and corrects for gravity alignment.

You can inspect the local pose on VOXL natively with

voxl-inspect-pose vvhub_body_wrt_local
OR
voxl-inspect-pose --local

Note this pipe was called vvpx4_body_wrt_local in SDK0.9 and older.

I don't think ROS libraries like TF2 care which way gravity points. A transform is a transform, you can have it oriented however you prefer when you do your math. You should only need to change coordinate frames for the sake of visualization if RVIS doesn't let you define a default orientation or rotate the ground plane around in the UI.