[effectiveness] module and tool to log and process control effectiveness

[gautierhattenberger]

This is an attempt to make a generic tool to log and process data used to estimate control effectiveness.
The module part can record all commands and imu data by default, plus a number of other sensor if required (position, speed, airspeed,...).
The ground tool is able to read the data and apply a series of filters before calling the optimization to find fitting parameters. A mixing matrix can also be applied to find cross talk like for full indi). Not all sensor models are implemented yet. The process is configured with a json file.
This is not really tested, only in the case of simple indi. And I'm not completely sure of the mixing part, so @EwoudSmeur , I would appreciate your opinion on this !
Hopefully some day we won't edit the code by hand for every aircraft to tune for indi ;)

[EwoudSmeur]

Very nice development Gautier! 😃

With the mixing, do I understand correctly that you want to be able to estimate the individual actuator control effectiveness from flying with a motor mixing matrix? And if you would be interested in the aggregated control effectiveness with motor mixing you would put an identity matrix there? I think that would be quite nice, but the risk is maybe that the control allocation is little bit more involved in the PPRZ motor mixing, (with scaling of the yaw command etc) such that the actuator commands may not be the same in reality as the ones on the drone. If that is what you want to do, wouldn't it make sense to log the actuator commands in the first place?

Would it be possible to make the logger able to use other loggers as well, such as logger_file or one of the other SD loggers? With a wrapper maybe?

I haven't tried it yet, but I'm excited to do so! Do you have a data file ready that I could maybe already see the script in action?

[EwoudSmeur]

Nice work Gautier!

[EwoudSmeur]

I think here it would be nice to put the time constant in rad/s, and then do the transformation to discrete time with the first order hold in the script such that it is irrespective of sample frequency. Also, this could be a property of an actuator as they can have different dynamics.

[gautierhattenberger]

I agree, but then embedded should also do that to make configuration easier, not sure it is already the case

[EwoudSmeur]

What are these coefs?

[gautierhattenberger]

the result is an array with commands in lines and inputs on columns, so you can select the one you want for a pretty print output with the display section

[gautierhattenberger]

The mixing matrix is not reflecting the motor mixing of the aircraft. It just tells for each commands (lines) which inputs (columns) should be considered.
For instance, if you do simple INDI, the four lines corresponds to ROLL, PITCH, YAW, THRUST (paparazzi "commands") and each of them is related to a single input (P, Q, R, az), except YAW with also a second order term.
For full INDI, le lines are MOTOR1, M2, M3, M4 (paparazzi "actuators"), inputs are the same, but you have a matrix (almost) full of 1. since you want to consider all cross interactions.
At least, that is what I was aiming for...
Of course, the commands and the inputs are all pre-processed by a series of filters, derivators, etc.

[gautierhattenberger]

This is a test log that should work with ./control_effectiveness_estimation.py -p config/quadrotor.json pprzlog_0004_1euro.csv

pprzlog_0004_1euro.tar.gz

[gautierhattenberger]

Regarding the logger interface, it is not homogeneous in paparazzi, so it means a lot of ifdef. I would rather spend some time to clean the logger API, but this is another job...