Evaluation with identified model

[Jaeyoung-Lim]

Description Previously discussed with @manumerous, we wanted to try and see if identifying a model through a flight log that was already using estimated parameters (so that we know the groundtruth dynamics) to evaluate this pipeline

Experiment Setup

• Generate a model through a lissajous excited trajectory using https://github.com/Jaeyoung-Lim/mavros_controllers/pull/193
• Estimate the parameters from the log generated from previous step using

  make estimate-model

• Run https://github.com/Jaeyoung-Lim/mavros_controllers/pull/193 with the estimated parameters by doing the following Start the simulation with

  Tools/sitl_run.sh -m iris -s iris_aerodynamics

  Start the lissajous trajectory excitation with https://github.com/Jaeyoung-Lim/mavros_controllers/pull/193

Results The estimated parameters does not seem to be consistent with the previous model that the trajectory was generated from. The vehicle is not able to fly with https://github.com/Jaeyoung-Lim/mavros_controllers/pull/193, which the model was originally trained on.

• Original log: https://logs.px4.io/plot_app?log=335127f8-32f0-45a5-a6f8-28eeecfee7ca
• Flight log with estimated parameters: https://logs.px4.io/plot_app?log=b116b55b-fc1b-41f7-bc0b-b34d01e4a64d

This can be interpreted in different ways, but I think this means that while the model estimated is good enough to "fly" the vehicle in auto modes, but the estimated dynamics seem to be inconsistent with the ground truth model that the stability of the nonlinear geometric controller has become unstable

Other comments I had to jump through a lot of hoops to get this setup working.

The following is general notes what I needed to do to get this working

• When starting this repository from a roslaunch file, the data driven dynamics plugin does not start properly. Therefore I had to run the simulation from this repo and run the ros package separately. Might be related to one of the GAZEBO_PATH_* environment variables used through a different route in ROS
• The gazebo plugin assumes that the estimated parameter file is called model_results/quadrotor_model.yml. The process that needs to happen is that you first estimate the model, rename the file to model_results/quadrotor_model.yml since the dates are included in the filename.
• When the above happens it is very unclear whether the gazebo plugin is not loaded because of a general installation problem or because it can't find the yaml file. This can be fixed by throwing with the appropriate messages

[pascalau]

I identified the issue for the incorrect parameter estimation. The actuator input for feature calculation is given in rpm and normalized using the function normalize_actuators() which assumes that the rpm is bounded between 1000 and 2000 rpm. And normalizes this range between [0,1]. The resulting actuator input has a mean of around 0.5. During simulation I observed that the actuator input also has a range between [0,1] but a mean of 0.7 which means that the a actuator input value of 0 corresponds to 0 rpm and 1 to 2000 rpm. I don't now what program/node publishes the actuator input, but setting the lower bound of normalize_actuators() to 0 instead of 1000 allows the regression to estimate more or less the original values.

[pascalau]

parameters.zip Here are the parameters for the simulation and the estimated parameters from the log.

[Jaeyoung-Lim]

@pascalau Awesome work!

normalize_actuators() to 0 instead of 1000 allows the regression to estimate more or less the original values.

Is this regarding https://github.com/ethz-asl/data-driven-dynamics/blob/29775ea5743c3e36c721cad9b1596c712354aed2/Tools/parametric_model/src/models/dynamics_model.py#L179 ?

@manumerous It seems like @pascalau solved the problem!

[pascalau]

Does anyone now what provides actuator_input to the plugin and how these values are mapped to rotor rpm?

[pascalau]

Is this regarding

https://github.com/ethz-asl/data-driven-dynamics/blob/29775ea5743c3e36c721cad9b1596c712354aed2/Tools/parametric_model/src/models/dynamics_model.py#L179

Yes

[Jaeyoung-Lim]

@pascalau So on the simulation side, the thrust is being calculated by the rotor velocity (RPM) in the gazebo_motor_model plugin in

https://github.com/PX4/PX4-SITL_gazebo/blob/27298574ce33a79ba6cfc31ed4604974605e7257/src/gazebo_motor_model.cpp#L201

This message comes from the gazebo_mavlink_interface, which receives the normalized actuator commands from PX4 and scales them to rpm commands

https://github.com/PX4/PX4-SITL_gazebo/blob/27298574ce33a79ba6cfc31ed4604974605e7257/src/gazebo_mavlink_interface.cpp#L1115-L1124

The relevant parameters such as input offset and input scaling are defined in the sdf file as is

https://github.com/ethz-asl/data-driven-dynamics/blob/29775ea5743c3e36c721cad9b1596c712354aed2/models/iris_aerodynamics/iris_aerodynamics.sdf#L446-L453

I know this is a bit convoluted but hope you can navigate through the problem :)

[pascalau]

If I see this correctly the model used for the simulation is: https://github.com/PX4/PX4-SITL_gazebo/blob/27298574ce33a79ba6cfc31ed4604974605e7257/models/iris/iris.sdf.jinja#L353-L369 Which implies that the range [0,1] should be mapped to [0,2200] because of the inputscaling of 2 and the maxRotVelocity of 1100.

[Jaeyoung-Lim]

@pascalau Ah your right the pre-estimation model is that one and your probably right.

So basically the estimated models all had the wrong input scaling and that is where the difference of behavior was coming from

[pascalau]

A max_output value of 2200 does not lead to the same parameters as the groundtruth. I'm not sure if I am missing something.

[manumerous]

That is very cool! Good catch!

I had a quick look at the parameters and they seem to be close enough as you said.

If it is true that the iris has a max output of 2200 it would be good to add the min/max output values to the config of each vehicle. This way the normalization could be adapted to each vehicles need.