Use Commands instead of actuator_pprz

[tmldeponti]

This Pull request is the first of a series of pull requests to make sure that modules such as Rotwing State and Rotwing Effectveess scheduling can be used by both the onleoop controller as well as a more conventional INDI cascaded controller.
This specific pull requests aims to solve:

1. Have shared modules which do not use actuator_pprz hardcoded references ( e.g. actuator_pprz[6] ) . This can be problematic as different actuator orders will not work.
2. Have a way to clearly specify how many actuators there are and what type of actuator they are (e.g. Real, Virtual, Passive and Other) so that variables such as "INDI_NUM_ACT" are not used outside of INDI files and cannot mistakely be assigned a wrong value.

With @dewagter we thought to revert back the controllers to assign commands to the commands[ ] array rather than actuator_pprz[ ]. Therefore, one would define a command per actuator to be controlled and use that in the command laws.
It would then be possible to make sure that the shared modules are always using the correct actuator index (e.g. commands[ROT_MECH])

I have also changed the gen_airframe file to add the attribute "actuator_type" to the commands in the airframe, and have counters for each sub-type. Then one can replace the hardcoded definitions such as "ANDI_NUM_ACT" or "INDI_NUM_ACT" with the gnerated definitions from the airframe (See how i have changed my oneloop controller). This is my first time writing in OCALM, the changes i made work but i am open to improvements.
This is what is generated from the airframe:

#define COMMAND_MOTOR_FRONT 0
#define COMMAND_MOTOR_RIGHT 1
#define COMMAND_MOTOR_BACK 2
#define COMMAND_MOTOR_LEFT 3
#define COMMAND_MOTOR_PUSHER 4
#define COMMAND_ROLL 5
#define COMMAND_PITCH 6
#define COMMAND_ROT_MECH 7
#define COMMAND_YAW 8
#define COMMAND_THRUST 9
#define COMMANDS_NB_OTHER 2
#define COMMANDS_NB_PASSIVE 1
#define COMMANDS_NB_VIRTUAL 2
#define COMMANDS_NB_REAL 5
#define COMMANDS_NB 10
#define COMMANDS_FAILSAFE {0,0,0,0,0,0,0,0,0,0}

An example commands section of an airframe would then look something like:

   <commands>
        <!-- Real actuators commands -->
        <axis name="MOTOR_FRONT"  actuator_type ="REAL" failsafe_value="0"/> <!-- IDX 0--> 
        <axis name="MOTOR_RIGHT"  actuator_type ="REAL" failsafe_value="0"/> <!-- IDX 1-->
        <axis name="MOTOR_BACK"   actuator_type ="REAL" failsafe_value="0"/> <!-- IDX 2-->
        <axis name="MOTOR_LEFT"   actuator_type ="REAL" failsafe_value="0"/> <!-- IDX 3-->
        <axis name="MOTOR_PUSHER" actuator_type ="REAL" failsafe_value="0"/> <!-- IDX 4-->
        <!-- Virtual actuators commands -->
        <axis name="ROLL"         actuator_type ="VIRTUAL" failsafe_value="0"/> <!-- ID X 5-->
        <axis name="PITCH"        actuator_type ="VIRTUAL" failsafe_value="0"/> <!-- IDX 6-->
        <!-- Passive actuators commands -->
        <axis name="ROT_MECH"     actuator_type ="PASSIVE" failsafe_value="0"/> <!-- IDX 7-->
        <!-- Legacy commands-->
        <axis name="YAW"          actuator_type ="OTHER" failsafe_value="0"/>
        <axis name="THRUST"       actuator_type ="OTHER" failsafe_value="0"/>
    </commands>

I have an airframe modified like this but I need my other PR (#3261) to be approved first.

[gautierhattenberger]

no so bad for a first try with Ocaml

[tmldeponti]

After a talk with @dewagter we realized that this is also a good opportunity to streamline the use of the defined commands in the airframe directly in NPS. Currently we provide in the airframe redundant info like the name and number of actuators:

    <section name="SIMULATOR" prefix="NPS_">
        <define name="ACTUATOR_NAMES"  value="front_motor, right_motor, back_motor, left_motor, pusher" type="string[]"/> 
        <define name="JSBSIM_MODEL"    value="rotwingv3c_SI" type="string"/>
        <define name="SENSORS_PARAMS"  value="nps_sensors_params_default.h" type="string"/>
        <define name="COMMANDS_NB"     value="5"/> 
        <define name="USE_COMMANDS"    value="TRUE"/>
        <define name="JS_AXIS_MODE"    value="4"/>
    </section>

This can be a source of errors, as for example one can provide the names of the actuators in the wrong order. The proposed changes first allow for the automatic generation of an array of strings from the commands names. The result is something like:

#define COMMAND_NAMES { "MOTOR_FRONT", "MOTOR_RIGHT", "MOTOR_BACK", "MOTOR_LEFT", "MOTOR_PUSHER", "ROLL", "PITCH", "ROT_MECH", "YAW", "THRUST" }

This array is then used in NPS to set always in the right order the actuator names when "NPS_USE_COMMANDS" is defined, resulting in a more streamlined nps section in the airframe:

    <section name="SIMULATOR" prefix="NPS_">
        <define name="JSBSIM_MODEL"    value="rotwingv3c_SI" type="string"/>
        <define name="SENSORS_PARAMS"  value="nps_sensors_params_default.h" type="string"/>
        <define name="USE_COMMANDS"    value="TRUE"/>
        <define name="JS_AXIS_MODE"    value="4"/>
    </section>

Finally the JSBSIM model should be modified so that the properties match the commands names, e.g.:

    <property>fcs/MOTOR_FRONT</property>
    <property>fcs/MOTOR_FRONT_lag</property>
    <property>fcs/MOTOR_FRONT_d</property>
    <property>fcs/MOTOR_RIGHT</property>
    <property>fcs/MOTOR_RIGHT_lag</property>
    <property>fcs/MOTOR_RIGHT_d</property>
    <property>fcs/MOTOR_BACK</property>
    <property>fcs/MOTOR_BACK_lag</property>
    <property>fcs/MOTOR_BACK_d</property>
    <property>fcs/MOTOR_LEFT</property>
    <property>fcs/MOTOR_LEFT_lag</property>
    <property>fcs/MOTOR_LEFT_d</property>

I will be able to push a sample airframe and JSBSIM model for the rotating wing drone C once PR (#3261) is approved.

[gautierhattenberger]

I don't mind having command names also used for NPS. If it works for specific frames, maybe you can harmonise other airframes later for the generic jsbsim models.

[dewagter]

Good step towards using COMMANDS to have virtual, real or passive commands driven independently.
I particularly like not needing to specify the simulator order of commands.
This should not damage anything, so it can be merged.