Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Commands instead of actuator_pprz #3265

Merged
merged 7 commits into from
Apr 16, 2024

Conversation

tmldeponti
Copy link
Contributor

@tmldeponti tmldeponti commented Apr 11, 2024

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.

@tmldeponti tmldeponti self-assigned this Apr 11, 2024
@tmldeponti tmldeponti added the New Feature To draft up an idea for a new feature in issue que label Apr 11, 2024
@tmldeponti tmldeponti requested a review from dewagter April 11, 2024 16:48
Copy link
Member

@gautierhattenberger gautierhattenberger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no so bad for a first try with Ocaml

sw/tools/generators/gen_airframe.ml Outdated Show resolved Hide resolved
sw/tools/generators/gen_airframe.ml Outdated Show resolved Hide resolved
sw/tools/generators/gen_airframe.ml Outdated Show resolved Hide resolved
@tmldeponti
Copy link
Contributor Author

tmldeponti commented Apr 15, 2024

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.

sw/tools/generators/gen_airframe.ml Outdated Show resolved Hide resolved
sw/simulator/nps/nps_fdm_jsbsim.cpp Outdated Show resolved Hide resolved
@gautierhattenberger
Copy link
Member

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.

Copy link
Member

@dewagter dewagter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@tmldeponti tmldeponti marked this pull request as ready for review April 16, 2024 13:22
@gautierhattenberger gautierhattenberger merged commit 50694ba into paparazzi:master Apr 16, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New Feature To draft up an idea for a new feature in issue que
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants