Skip to content

nn_module_utilities.md

Latest commit

 

History

History
31 lines (21 loc) · 4.04 KB

nn_module_utilities.md

File metadata and controls

31 lines (21 loc) · 4.04 KB

Neural Network Module Utilities

This page will explain the parts of the module that does not directly concern something with the neural network, but PX4 related implementations, so that you more easily can shape the module to your needs.

To learn more about how PX4 works in general, it is recommended to start with Getting started.

Autostart

In the PX4-Autopilot source code there are startup scripts, in these I have added a line for the mc_nn_control module. in ROMFS/px4fmu_common/init.d/rc.mc_apps it checks wether the module is included by looking for the parameter MC_NN_EN. If this is set to 1, which is the default value, the module will be started when booting PX4. Similarly you could create other parameters in the src/modules/mc_nn_control/mc_nn_control_params.c file for other startup script checks.

:::info Note that it's only the first time you build that the default param value will overwrite the current one. So if you change it in the param file it will not be changed when flashing to the controller again. Todo this you can change it in QGC or in the terminal. :::

Custom Flight Mode

The module creates its own flight mode "Neural Control" which lets you choose it from the flight mode menu in QGC and bind it to a switch on you RC controller. This is done by using the ROS 2 Interface Library internally. This involves several steps:

  1. Publish a RegisterExtComponentRequest. This specifies what you want to create, you can read more about this in the Control Interface. In this case we register an arming check and a mode.
  2. Wait for a RegisterExtComponentReply. This will give feedback on wether the mode registration was successful, and what the mode and arming check id is for the new mode.
  3. [Optional] With the mode id, publish a VehicleControlMode message on the config_control_setpoints topic. Here you can configure what other modules run in parallel. The example controller replaces everything, so it turns off allocation. If you want to replace other parts you can enable or disable the modules accordingly.
  4. [Optional] With the mode id, publish a ConfigOverrides on the config_overrides_request topic. (This is not done in the example module) This will let you defer failsafes or stop it from automatically disarming.
  5. When the mode has been registered a ArmingCheckRequest will be sent, asking if your mode has everything it needs to run. This message must be answered with a ArmingCheckReply so the mode is not flagged as unresponsive. In this response it is possible to set what requirements the mode needs to run, like local position. If any of these requirements are set the commander will stop you from switching to the mode if they are not fulfilled. It is also important to set health_component_index and num_events to 0 to not get a segmentation fault. Unless you have a health component or events.
  6. Listen to the VehicleStatus topic. If the nav_state equals the assigned mode_id, then the Neural Controller is activated.
  7. When active the module will run the controller and publish to ActuatorMotors. If you want to replace a different part of the controller, you should find the appropriate topic to publish to.

To see how the requests are handled you can check out src/modules/commander/ModeManagement.cpp.

Logging

To add module specific logging a new topic has been added to uORB called NeuralControl. The message definition is also added in msg/CMakeLists.txt, and to src/modules/logger/logged_topics.cpp under the debug category. So for these messages to be saved in you ulog logs you need to include debug in the SDLOG_PROFILE parameter.

Timing