Add quadrotor model linked to generated model from pipeline

[Jaeyoung-Lim]

Problem Description
This PR adds the capability of linking the generated parametric model into the gazebo simulation for multirotors.

• Added a multirotor model with the data driven dynamics plugin integrated
• Read vehicle parameters from yaml file
• Add rotor force calculation in the aerodynamics plugin
• Rename fw_dynamics plugin to data-driven-dynamics-plugin
• Test flight in SITL
• Comparison with groundtruth parameters (Addressed in Add moment calculation for simulation #117)
• Add rotor moment calculation in the aerodynamics plugin (Addressed in Add moment calculation for simulation #117)

Additional Context

• This PR depends on Fix config file generation naming #88
• This PR depends on Dump model config into output #91

[Jaeyoung-Lim]

@manumerous The pipeline is set(for force), but it seems like the estimated thrust is not able to lift the vehicle up from the ground.

• Looking at the estimated parameters, I can see that the estimated thrust is significantly lower than the one that is modeled in the simulation(Gazebo MotorModelPlugin), enough to not able to takeoff or hover:

• Comparison with zero input airspeed

• References:
  • Visualization is done by Tools/visualize_rotorfeatures.py included in this PR
  • Parameters from default iris model: https://github.com/PX4/PX4-SITL_gazebo/blob/55e479aa80b57da850e307b0105baf0f262ec284/models/iris/iris.sdf.jinja#L353
  • Rotor thrust calculations from GazeboMotorModelPlugin: https://github.com/PX4/PX4-SITL_gazebo/blob/55e479aa80b57da850e307b0105baf0f262ec284/src/gazebo_motor_model.cpp#L224

[Jaeyoung-Lim]

Vehicle flying in PX4 SITL with ONLY force estimation

• notice that the rotors are not spinning, due to the motor plugin not running.

[manumerous]

@manumerous The pipeline is set(for force), but it seems like the estimated thrust is not able to lift the vehicle up from the ground.

* Looking at the estimated parameters, I can see that the estimated thrust is significantly lower than the one that is modeled in the simulation([Gazebo MotorModelPlugin](https://github.com/PX4/PX4-SITL_gazebo/blob/master/src/gazebo_motor_model.cpp)), enough to not able to takeoff or hover:

* Comparison with zero input airspeed

* References:
  
  * Visualization is done by `Tools/visualize_rotorfeatures.py` included in this PR
  * Parameters from default iris model: https://github.com/PX4/PX4-SITL_gazebo/blob/55e479aa80b57da850e307b0105baf0f262ec284/models/iris/iris.sdf.jinja#L353
  * Rotor thrust calculations from GazeboMotorModelPlugin: https://github.com/PX4/PX4-SITL_gazebo/blob/55e479aa80b57da850e307b0105baf0f262ec284/src/gazebo_motor_model.cpp#L224

Sorry if this was unclear. The other models, apart from the tiltwing were estimating accelerations instead of forces. But as it seems from #107 you figured that out by now. :)

[manumerous]

Vehicle flying in PX4 SITL with ONLY force estimation

* notice that the rotors are not spinning, due to the motor plugin not running.

that is very cool :)

[Jaeyoung-Lim]

@manumerous Since this PR seems to be growing, I suggest that we merge this at the current state (flying with forces)

I have already tried adding moments and drag to the model, but this seems to be very unstable. (most likely due to having different moment of inertia in the sim and the estimation). Therefore, I will address it in a separate PR

[manumerous]

@manumerous Since this PR seems to be growing, I suggest that we merge this at the current state (flying with forces)

I have already tried adding moments and drag to the model, but this seems to be very unstable. (most likely due to having different moment of inertia in the sim and the estimation). Therefore, I will address it in a separate PR

I can have a look at it on Tuesday. If you want to go ahead before its okay for me.

[manumerous]

In the data-driven-dyanmics pipeline each rotor is assigned to a rotor group (e.g. vertical) whereby all rotors from the same group share the same coefficients. To distinguish the coefficients the name of the group is added before the coefficients name.

If I understand correctly this rotor parameters are not specific to multi-rotors but general? Would it not make sense to keep the naming general in that case?

[Jaeyoung-Lim]

This is actually not feasible with the yaml parser macro in this repo. The variable name needs to be exactly the same as what you are parsing from the results file

[manumerous]

Do you plan to implement that for other models like for example the delta quadplane, which has two different groups of rotors? Could we maybe get the names of the rotor groups out of the config file and then generate the variables needed to access all the values?

[Jaeyoung-Lim]

@manumerous I am not sure - I have not looked into the quadplane yet. I am just trying to parse whatever config variables there is in the config file, and the API currently in this repo requires you to have the same variable name with what you are parsing. If we want a better config management then we need to discuss what we want 😄 However, I don't think this is relevant for this PR.

Could we maybe get the names of the rotor groups out of the config file and then generate the variables needed to access all the values?

I am actually not sure if I understand what you mean. I think this depends more on how the config file is being generated? Is this correct?

[Jaeyoung-Lim]

Removed

[manumerous]

How do you plan to structure the generation of different models in gazebo? will all different vehicle type dynamics be generated from the file src/parametric_dynamics_model.cpp ?

[Jaeyoung-Lim]

How do you plan to structure the generation of different models in gazebo? will all different vehicle type dynamics be generated from the file src/parametric_dynamics_model.cpp ?

Yes, so nothing should change on the gazebo side. Gazebo should be just reading configs and applying them