-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Use Commands instead of actuator_pprz #3265
Conversation
There was a problem hiding this 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
… of commands. Avoid unnecessary array to list conversion.
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. |
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. |
Co-authored-by: Gautier Hattenberger <[email protected]>
There was a problem hiding this 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.
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:
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:
An example commands section of an airframe would then look something like:
I have an airframe modified like this but I need my other PR (#3261) to be approved first.