Clarification please re. thrust command velocity or force or %

[maciejmatuszak]

I would like some clarification. The linear MPC documentation says:

command/roll_pitch_yawrate_thrust of type mav_msgs/RollPitchYawrateThrust. This is the command to the low level controller. Angles are in rad and thrust is in N.

It publishes the z thrust component in Newtons, however the matlab scripts seems to treat it as velocity. The falcon2_sysid_roll_pitch_onboard.m has a scaling constant

k_thrust = 0.0019965;

I presume the constant was evaluated using the regression scripts similar to the regression_height_falcon2.m that script scales the joystick input to match vertical velocity.

To confuse it more the DJIInterface::commandRollPitchYawrateThrustCallback that accepts the command seems to have limits (minimumthrust and maximumthrust) suggesting it is 0-100% The falcon2_sysid_height_onboard.m fits the throttle command with transfer function into vertical velocity as well.

So, should the thrust.z be a Force in [N], velocity [m/s] or [%]? Or is does not really matter as long as as the values are the same for experiments and actual control?

Why I am asking ? I am trying to replicate your experiment with M100 with custom quadrotor frame and N3 controller. I created ros node that sends mav_msgs/RollPitchYawrateThrust with roll/pitch in [rad] and thrust.z as 0...100. I am creating those from /dji_sdk/rc topic.

[fmina]

The attitude/z_velocity is deprecated. It was the first version we tested, now the interface supports attitude thrust. I would stick with attitude thrust in [N].

[maciejmatuszak]

The instructions for collecting the data https://github.com/ethz-asl/mav_dji_ros_interface/wiki/Dynamic-System-Identification (the table on top) indicate input as dji_sdk/vc_cmd/thrust/ and output as dji_sdk/velocity/. Are you saying those instructions are outdated? Is there falcon2_sysid_height_onboard.m equivalent dealing with acceleration rather than velocity?

[maciejmatuszak]

Was thinking some more about it, the scripts for roll, pitch calculate the 1'st and 2'nd order transfer function parameters from roll command to roll taken from imu orientation, same for pitch and yaw rate. angle to angle, angle rate to angle rate. However thrust transfer function parameters are calculated from trust.z command to vertical velocity? Should that be force to force function I mean from thrust.z to imu.linear_acceleration.z * uav_mass? The MPC is going to send the thrust.z command as Newtons. Am I missing something here? @inkyusa Inku, I notice you have been working on those scripts, can you shade some light on this? regards Maciej

[maciejmatuszak]

OK, I think I found what it is about. The paper dealing with dynamic system identification mention that the DJI SDK only allows for the command to control velocity and not acceleration.

2) Stick inputs: The common transmitter inputs are pitch, roll angles ( rad), yaw rate ( rad/s), and thrust (N). However, the vertical stick input of the platform is velocity (m/s) that permits easier and safer manual flight. To address this different, we use a classic PID vertical position controller alongside linear MPC horizontal position controller.

Is that still the case in the master branch of mav_control_rw? If I understood the code correctly the nonlinear mpc in master branch is using transfer functions of first and second order for roll, pitch and yaw rate, but I can only find the penalty values for the thrust: q_z, q_vz, r_thtust. Do not see any references to PID in the code.

My plan is to use this config: https://github.com/ethz-asl/mav_dji_ros_interface/blob/master/dji_interface/launch/raven_indoor_rovio_nMPC_trj.launch. Plugin the transfer function parameters from roll, pitch, yaw_rate experiments and change the sampling_time parameter to match the 400Hz IMU and MSF pose stream from N3 controller.

If you see any problem with this approach please let me know.

[fmina]

Since we wrote the new interface, we use roll, pitch yaw rate and thrust [N]. Z velocity is not used, and no identification beside roll/pitch dynamics is needed.

I don't think you need to run MSF/NMPC at 400 Hz, that's too much. I would go for 50, max 100 Hz if the serial communication doesn't give issues.

[fmina]

@inkyusa I think we should update the documentation of the SysID to match what we have in this repo.

[maciejmatuszak]

Thanks @fmina ! What you say matches my understanding of the code and the parameters in the config file. I also was thinking to drop the frequency, the serial communication copes quite well with 400Hz via USB/Serial converter but the tasks that process the data seems to be heavy on CPU. What a shame to drop the yaw transfer function in my case it fits the validation data with 91% accuracy :)

Maciej

[maciejmatuszak]

Thank you for your support, I decided on a compromise the Visual Odometry works really nice with 400Hz IMU, so I run that and MSF at 400Hz and then publish odometry from MSF at 50Hz (every 8'th frame) to nMPC. The DJI N3 controller need some tuning but it works well, I tested it with step responses in square: https://www.youtube.com/watch?v=3LoL0Xdj7PY Thank you again!

[inkyusa]

Since we have changed control input interface from virtual RC that sends roll angle, pitch angle, yaw rate, and vertical velocity to thrust command (all same except sending 0-100% thrust command instead vertical velocity as Mina mentioned). I created another dynamic system identification page for thrust command and we will update in an early manner. If this issue resolved, please close it. Best,

[fmina]

I will close this. Please reopen if needed.