mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-05-27 18:27:05 +08:00
New Crowdin translations - ko (#26246)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
PX4 Build Bot
GitHub
@@ -0,0 +1,21 @@
|
||||
# Neural Network Control
|
||||
|
||||
PX4 supports the following mechanisms for using neural networks for multirotor control:
|
||||
|
||||
- [MC Neural Networks Control](../neural_networks/mc_neural_network_control.md)<Badge type="warning" text="Experimental" /> — A generic neural network module that you can modify to use different underlying neural network and training models and compile into the firmware.
|
||||
- [RAPTOR: A Neural Network Module for Adaptive Quadrotor Control](../neural_networks/raptor.md)<Badge type="warning" text="Experimental" /> — An adaptive RL NN module that works well with different Quad configurations without additional training.
|
||||
|
||||
Generally you will select the former if you wish to experiment with custom neural network architectures and train them using PyTorch or TensorFlow, and the latter if you want to use a pre-trained neural-network controller that works out-of-the-box (without training for your particular platform) or if you train your own policies using [RLtools](https://rl.tools).
|
||||
|
||||
Note that both modules are experimental and provided for experimentation.
|
||||
The table below provides more detail on the differences.
|
||||
|
||||
| Use Case | [`mc_raptor`](../neural_networks/raptor.md) | [`mc_nn_control`](../neural_networks/mc_neural_network_control.md) |
|
||||
| ---------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------ |
|
||||
| Pre-trained policy that adapts to any quadrotor without training | ✓ RAPTOR | ✘ |
|
||||
| Train policy in PyTorch/TF | ✘ | ✓ TF Lite |
|
||||
| Train policy in RLtools | ✓ | ✘ |
|
||||
| Use manual control (remote) with NN policy | ✘ GPS/MoCap | ✓ Manual attitude commands |
|
||||
| Load policy checkpoints from SD card | ✓ Upload via MAVLink FTP | ✘ Compiled into firmware |
|
||||
| Offboard setpoints | ✓ MAVLink | ✘ |
|
||||
| Internal Trajectory Generator | ✓ (Position, Lissajous) | ✘ |
|
||||
@@ -0,0 +1,119 @@
|
||||
# MC Neural Networks Control
|
||||
|
||||
<Badge type="tip" text="PX4 v1.17" /> <Badge type="warning" text="Experimental" />
|
||||
|
||||
:::warning
|
||||
This is an experimental module.
|
||||
Use at your own risk.
|
||||
:::
|
||||
|
||||
The Multicopter Neural Network (NN) module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) is an example module that allows you to experiment with using a pre-trained neural network on PX4.
|
||||
It might be used, for example, to experiment with controllers for non-traditional drone morphologies, computer vision tasks, and so on.
|
||||
|
||||
The module integrates a pre-trained neural network based on the [TensorFlow Lite Micro (TFLM)](./tflm.md) module.
|
||||
The module is trained for the [X500 V2](../frames_multicopter/holybro_x500v2_pixhawk6c.md) multicopter frame.
|
||||
While the controller is fairly robust, and might work on other platforms, we recommend [Training your own Network](#training-your-own-network) if you use a different vehicle.
|
||||
Note that after training the network you will need to update and rebuild PX4.
|
||||
|
||||
TLFM is a mature inference library intended for use on embedded devices.
|
||||
It has support for several architectures, so there is a high likelihood that you can build it for the board you want to use.
|
||||
If not, there are other possible NN frameworks, such as [Eigen](https://eigen.tuxfamily.org/index.php?title=Main_Page) and [Executorch](https://pytorch.org/executorch-overview).
|
||||
|
||||
This document explains how you can include the module in your PX4 build, and provides a broad overview of how it works.
|
||||
The other documents in the section provide more information about the integration, allowing you to replace the NN with a version trained on different data, or even to replace the TLFM library altogether.
|
||||
|
||||
If you are looking for more resources to learn about the module, a website has been created with links to a youtube video and a workshop paper. A full master's thesis will be added later. [A Neural Network Mode for PX4 on Embedded Flight Controllers](https://ntnu-arl.github.io/px4-nns/).
|
||||
|
||||
## Neural Network PX4 Firmware
|
||||
|
||||
:::warning
|
||||
This module requires Ubuntu 24.04 or newer (it is not supported in Ubuntu 22.04).
|
||||
:::
|
||||
|
||||
The module has been tested on a number of configurations, which can be build locally using the commands:
|
||||
|
||||
```sh
|
||||
make px4_sitl_neural
|
||||
```
|
||||
|
||||
```sh
|
||||
make px4_fmu-v6c_neural
|
||||
```
|
||||
|
||||
```sh
|
||||
make mro_pixracerpro_neural
|
||||
```
|
||||
|
||||
You can add the module to other board configurations by modifying their `default.px4board file` configuration to include these lines:
|
||||
|
||||
```sh
|
||||
CONFIG_LIB_TFLM=y
|
||||
CONFIG_MODULES_MC_NN_CONTROL=y
|
||||
```
|
||||
|
||||
:::tip
|
||||
The `mc_nn_control` module takes up roughly 50KB, and many of the `default.px4board file` are already close to filling all the flash on their boards. To make room for the neural control module you can remove the include statements for other modules, such as FW, rover, VTOL and UUV.
|
||||
:::
|
||||
|
||||
## Example Module Overview
|
||||
|
||||
The example module replaces the entire controller structure as well as the control allocator, as shown in the diagram below:
|
||||
|
||||
|
||||
|
||||
In the [controller diagram](../flight_stack/controller_diagrams.md) you can see the [uORB message](../middleware/uorb.md) flow.
|
||||
We hook into this flow by subscribing to messages at particular points, using our neural network to calculate outputs, and then publishing them into the next point in the flow.
|
||||
We also need to stop the module publishing the topic to be replaced, which is covered in [Neural Network Module: System Integration](nn_module_utilities.md)
|
||||
|
||||
### Input
|
||||
|
||||
The input can be changed to whatever you want.
|
||||
Set up the input you want to use during training and then provide the same input in PX4.
|
||||
In the Neural Control module the input is an array of 15 numbers, and consists of these values in this order:
|
||||
|
||||
- [3] Local position error. (goal position - current position)
|
||||
- [6] The first 2 rows of a 3 dimensional rotation matrix.
|
||||
- [3] Linear velocity
|
||||
- [3] Angular velocity
|
||||
|
||||
All the input values are collected from uORB topics and transformed into the correct representation in the `PopulateInputTensor()` function.
|
||||
PX4 uses the NED frame representation, while the Aerial Gym Simulator, in which the NN was trained, uses the ENU representation.
|
||||
Therefore two rotation matrices are created in the function and all the inputs are transformed from the NED representation to the ENU one.
|
||||
|
||||
|
||||
|
||||
ENU and NED are just rotation representations, the translational difference is only there so both can be seen in the same figure.
|
||||
|
||||
### 출력
|
||||
|
||||
The output consists of 4 values, the motor forces, one for each motor.
|
||||
These are transformed in the `RescaleActions()` function.
|
||||
This is done because PX4 expects normalized motor commands while the Aerial Gym Simulator uses physical values.
|
||||
So the output from the network needs to be normalized before they can be sent to the motors in PX4.
|
||||
|
||||
The commands are published to the [ActuatorMotors](../msg_docs/ActuatorMotors.md) topic.
|
||||
The publishing is handled in `PublishOutput(float* command_actions)` function.
|
||||
|
||||
:::tip
|
||||
If the neural control mode is too aggressive or unresponsive the [MC_NN_THRST_COEF](../advanced_config/parameter_reference.md#MC_NN_THRST_COEF) parameter can be tuned.
|
||||
Decrease it for more thrust.
|
||||
:::
|
||||
|
||||
## Training your own Network
|
||||
|
||||
The network is currently trained for the [X500 V2](../frames_multicopter/holybro_x500v2_pixhawk6c.md).
|
||||
But the controller is somewhat robust, so it could work directly on other platforms, but performing system identification and training a new network is recommended.
|
||||
|
||||
Since the Aerial Gym Simulator is open-source you can download it and train your own networks as long as you have access to an NVIDIA GPU.
|
||||
If you want to train a control network optimized for your platform you can follow the instructions in the [Aerial Gym Documentation](https://ntnu-arl.github.io/aerial_gym_simulator/9_sim2real/).
|
||||
|
||||
You should do one system identification flight for this and get an approximate inertia matrix for your platform.
|
||||
On the `sys-id` flight you need ESC telemetry, you can read more about that in [DSHOT](../peripherals/dshot.md).
|
||||
|
||||
Then do the following steps:
|
||||
|
||||
- Do a hover flight
|
||||
- Read of the logs what RPM is required for the drone to hover.
|
||||
- Use the weight of each motor, length of the motor arms, total weight of the platform with battery to calculate an approximate inertia matrix for the platform.
|
||||
- Insert these values into the Aerial Gym configuration and train your network.
|
||||
- Convert the network as explained in [TFLM](tflm.md).
|
||||
@@ -0,0 +1,86 @@
|
||||
# Neural Network Module: System Integration
|
||||
|
||||
The neural control module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) implements an end-to-end controller utilizing neural networks.
|
||||
|
||||
The parts of the module directly concerned with generating the code for the trained neural network and integrating it into the module are covered in [TensorFlow Lite Micro (TFLM)](./tflm.md).
|
||||
This page covers the changes that were made to integrate the module into PX4, both within the module, and in larger system configuration.
|
||||
|
||||
:::tip
|
||||
This topic should help you to shape the module to your own needs.
|
||||
|
||||
You will need some familiarity with PX4 development.
|
||||
For more information see the developer [Getting Started](../dev_setup/getting_started.md).
|
||||
:::
|
||||
|
||||
## 자동 실행
|
||||
|
||||
A line to autostart the [mc_nn_control](../modules/modules_controller.md#mc-nn-control) module has been added in the [`ROMFS/px4fmu_common/init.d/rc.mc_apps`](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d/rc.mc_apps) startup script.
|
||||
|
||||
It checks whether the module is included by looking for the parameter [MC_NN_EN](../advanced_config/parameter_reference.md#MC_NN_EN).
|
||||
If this is set to `1` (the default value), the module will be started when booting PX4.
|
||||
Similarly you could create other parameters in the [`mc_nn_control_params.c`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mc_nn_control/mc_nn_control_params.c) file for other startup script checks.
|
||||
|
||||
## 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](../ros2/px4_ros2_interface_lib.md) internally.
|
||||
This involves several steps and is visualized here:
|
||||
|
||||
:::info
|
||||
The module does not actually use ROS 2, it just uses the API exposed through uORB topics.
|
||||
:::
|
||||
|
||||
:::info
|
||||
In some QGC versions the flight mode does not show up, so make sure to update to the newest version.
|
||||
This only works for some flight controllers, so you might have to use an RC controller to switch to the correct external flight mode.
|
||||
:::
|
||||
|
||||
|
||||
|
||||
1. Publish a [RegisterExtComponentRequest](../msg_docs/RegisterExtComponentRequest.md).
|
||||
This specifies what you want to create, you can read more about this in the [Control Interface](../ros2/px4_ros2_control_interface.md).
|
||||
In this case we register an arming check and a mode.
|
||||
2. Wait for a [RegisterExtComponentReply](../msg_docs/RegisterExtComponentReply.md).
|
||||
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](../msg_docs/VehicleControlMode.md) 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](../msg_docs/ConfigOverrides.md) 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](../msg_docs/ArmingCheckRequest.md) will be sent, asking if your mode has everything it needs to run.
|
||||
This message must be answered with a [ArmingCheckReply](../msg_docs/ArmingCheckReply.md) 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](../msg_docs/VehicleStatus.md) 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](../msg_docs/ActuatorMotors.md).
|
||||
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](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/ModeManagement.cpp).
|
||||
|
||||
## 로깅
|
||||
|
||||
To add module-specific logging a new topic has been added to [uORB](../middleware/uorb.md) called [NeuralControl](../msg_docs/NeuralControl.md).
|
||||
The message definition is also added in `msg/CMakeLists.txt`, and to [`src/modules/logger/logged_topics.cpp`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/logger/logged_topics.cpp) under the debug category.
|
||||
For these messages to be saved in your logs you need to include `debug` in the [SDLOG_PROFILE](../advanced_config/parameter_reference.md#SDLOG_PROFILE) parameter.
|
||||
|
||||
## Timing
|
||||
|
||||
The module has two includes for measuring the inference times.
|
||||
The first one is a driver that works on the actual flight controller units, but a second one, `chrono`, is loaded for SITL testing.
|
||||
Which timing library is included and used is based on wether PX4 is built with NUTTX or not.
|
||||
|
||||
## Changing the setpoint
|
||||
|
||||
The module uses the [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) message's position fields to define its target.
|
||||
To follow a trajectory, you can send updated setpoints.
|
||||
For an example of how to do this in a PX4 module, see the [mc_nn_testing](https://github.com/SindreMHegre/PX4-Autopilot-public/tree/main/src/modules/mc_nn_testing) module in this fork.
|
||||
Note that this is not included in upstream PX4.
|
||||
To use it, copy the module folder from the linked repository into your workspace, and enable it by adding the following line to your `.px4board` file:
|
||||
|
||||
```sh
|
||||
CONFIG_MODULES_MC_NN_TESTING=y
|
||||
```
|
||||
@@ -0,0 +1,221 @@
|
||||
# RAPTOR: A Neural Network Module for Adaptive Quadrotor Control
|
||||
|
||||
<Badge type="tip" text="main (planned for PX4 v1.18)" /> <Badge type="info" text="Multicopter" /> <Badge type="warning" text="Experimental" />
|
||||
|
||||
:::warning
|
||||
This is an experimental module.
|
||||
Use at your own risk.
|
||||
:::
|
||||
|
||||
RAPTOR is a tiny reinforcement-learning based neural network module for quadrotor control that can be used to control a wide variety of quadrotors without retuning.
|
||||
|
||||
This topic provides an overview of the fundamental concepts, and explains how you can use the module in simulation and real hardware.
|
||||
|
||||
## 개요
|
||||
|
||||
|
||||
|
||||
RAPTOR is an adaptive policy for end-to-end quadrotor control.
|
||||
It is motivated by the human ability to adapt learned behaviours to similar situations.
|
||||
For example, while humans may initially require many hours of driving experience to be able to smoothly control the car and blend into traffic, when faced with a new vehicle they do not need to re-learn how to drive — they only need to experience a few rough braking/acceleration/steering responses to adjust their previously learned behavior.
|
||||
|
||||
Reinforcement Learning (RL) is a machine learning technique that uses trial and error to learn decision making/control behaviors, which is similar to the way that humans learn to drive.
|
||||
RL is interesting for controlling robots (and particularly UAVs) because it overcomes some fundamental limitations of classic, modular control architectures (information loss at module boundaries, requirement for expert tuning, etc).
|
||||
RL has been very successful in [high-performance quadrotor flight](https://doi.org/10.1038/s41586-023-06419-4), but previous designs have not been particularly adaptable to new frames and vehicle types.
|
||||
|
||||
RAPTOR fills this gap and demonstrates a single, tiny neural-network control policy that can control a wide variety of quadrotors (tested on real quadrotors from 32 g to 2.4 kg).
|
||||
|
||||
For more details please refer to this video:
|
||||
|
||||
<lite-youtube videoid="hVzdWRFTX3k" title="RAPTOR: A Foundation Policy for Quadrotor Control"/>
|
||||
|
||||
The method we developed for training the RAPTOR policy is called Meta-Imitation Learning:
|
||||
|
||||
|
||||
|
||||
You can torture test the RAPTOR policy in your browser at [https://raptor.rl.tools](https://raptor.rl.tools) or in the embedded app here:
|
||||
|
||||
<iframe src="https://rl-tools.github.io/raptor.rl.tools?raptor=false" width="100%" height="1000" style="border: none;"></iframe>
|
||||
|
||||
For more information please refer to the paper at [https://arxiv.org/abs/2509.11481](https://arxiv.org/abs/2509.11481).
|
||||
|
||||
## 구조
|
||||
|
||||
The RAPTOR control policy is an end-to-end policy that takes position, orientation, linear velocity and angular velocity as inputs and outputs motor commands (`actuator_motors`).
|
||||
To integrate it into PX4 we use the external mode registration facilities in PX4 (which also works well for internal modes as demonstrated in `mc_nn_control`).
|
||||
Because of this architecture the `mc_raptor` module is completely decoupled from all other PX4 logic.
|
||||
|
||||
By default, the RAPTOR module expects setpoints via `trajectory_setpoint` messages.
|
||||
If no `trajectory_setpoint` messages are received or if no `trajectory_setpoint` is received within 200 ms, the current position and orientation (with zero velocity) is used as the setpoint.
|
||||
Since feeding setpoints reliably via telemetry is still a challenge, we also implement a simple option to generate internal reference trajectories (controlled through the `MC_RAPTOR_INTREF` parameter) for demonstration and benchmarking purposes.
|
||||
|
||||
## 특징
|
||||
|
||||
- Tiny neural network (just 2084 parameters) => minimal CPU usage
|
||||
- Easily maintainable
|
||||
- Simple CMake setup
|
||||
- Self-contained (no interference with other modules)
|
||||
- Single, simple and well-maintained dependency (RLtools)
|
||||
- Loading neural network parameters from SD card
|
||||
- Minimal flash usage (for possible inclusion into default build configurations)
|
||||
- Easy development: Train new neural network and just upload it via MAVLink FTP without requiring to re-flash the firmware
|
||||
- Tested on 10+ different real platforms (including flexible frames, brushed motors)
|
||||
- Actively developed and maintained
|
||||
|
||||
## 사용법
|
||||
|
||||
### SITL
|
||||
|
||||
Build PX4 SITL with Raptor, disable QGC requirement, and adjust the `IMU_GYRO_RATEMAX` to match the simulation IMU rate
|
||||
|
||||
```sh
|
||||
make px4_sitl_raptor gz_x500
|
||||
param set NAV_DLL_ACT 0
|
||||
param set COM_DISARM_LAND -1 # When taking off in offboard the landing detector can cause mid-air disarms
|
||||
param set IMU_GYRO_RATEMAX 250 # Just for SITL. Tested with IMU_GYRO_RATEMAX=400 on real FCUs
|
||||
param set MC_RAPTOR_ENABLE 1 # Enable the mc_raptor module
|
||||
param save
|
||||
```
|
||||
|
||||
Upload the RAPTOR checkpoint to the "SD card": Separate terminal
|
||||
|
||||
```bash
|
||||
mavproxy.py --master udp:127.0.0.1:14540
|
||||
ftp mkdir /raptor # for the real FMU use: /fs/microsd/raptor
|
||||
ftp put src/modules/mc_raptor/blob/policy.tar /raptor/policy.tar
|
||||
```
|
||||
|
||||
Restart (<kbd>Ctrl+C</kbd>)
|
||||
|
||||
```sh
|
||||
make px4_sitl_raptor gz_x500
|
||||
commander takeoff
|
||||
commander status
|
||||
```
|
||||
|
||||
Note the external mode ID of `RAPTOR` in the status report
|
||||
|
||||
```sh
|
||||
commander mode ext{RAPTOR_MODE_ID}
|
||||
```
|
||||
|
||||
#### Internal Reference Trajectory Generation
|
||||
|
||||
In our experience, feeding the `trajectory_setpoint` via MAVLink (even via WiFi telemetry) is unreliable.
|
||||
But we do not want to constrain this module to only platforms that have a companion board.
|
||||
|
||||
For this reason we have integrated a simple internal reference trajectory generator for testing and benchmarking purposes.
|
||||
It supports position (constant position and yaw setpoint) as well as configurable [Lissajous trajectories](https://en.wikipedia.org/wiki/Lissajous_curve).
|
||||
|
||||
The Lissajous generator can, for example, generate smooth figure-eight trajectories that contain interesting accelerations for benchmarking and testing purposes.
|
||||
Please refer to the embedded configurator later in this section to explore the Lissajous parameters and view the resulting trajectories.
|
||||
|
||||
To use the internal reference generator, select the mode: `0`: Off/activation position tracking, `1`: Lissajous
|
||||
|
||||
```sh
|
||||
param set MC_RAPTOR_INTREF 1
|
||||
```
|
||||
|
||||
Restart (ctrl+c)
|
||||
|
||||
```sh
|
||||
commander takeoff
|
||||
commander mode ext{RAPTOR_MODE_ID}
|
||||
mc_raptor intref lissajous 0.5 1 0 2 1 1 10 3
|
||||
```
|
||||
|
||||
The trajectory is relative to the position and yaw of the vehicle at the point where the RAPTOR mode is activated (or the position and yaw where the parameters are changed if it is already activated).
|
||||
|
||||
You can adjust the parameters of the trajectory with the following tool.
|
||||
Make sure to copy the generated CLI string at the end:
|
||||
|
||||
<iframe src="https://rl-tools.github.io/mc-raptor-trajectory-tool" width="100%" height="1700" style="border: none;"></iframe>
|
||||
|
||||
### Real-World
|
||||
|
||||
#### 설정
|
||||
|
||||
The `mc_raptor` module has been mostly tested with the Holybro X500 V2 but it should also work out-of-the-box with other platforms (see the [Other Platforms](#other-platforms) section).
|
||||
|
||||
```sh
|
||||
make px4_fmu-v6c_raptor upload
|
||||
```
|
||||
|
||||
We recommend initially testing the RAPTOR mode using a dead man's switch.
|
||||
For this we configure the mode selection to be connected to a push button or a switch with a spring that automatically switches back.
|
||||
In the default position we configure e.g. `Stabilized Mode` and in the pressed configuration we select `External Mode 1` (since the name of the external mode is only transmitted at runtime).
|
||||
This allows to take off manually and then just trigger the RAPTOR mode for a split-second to see how it behaves.
|
||||
In our experiments it has been exceptionally stable (zero crashes) but we still think progressively activating it for longer is the safest way to build confidence.
|
||||
|
||||
:::warning
|
||||
Make sure that your platform uses the standard PX4 quadrotor motor layout:
|
||||
|
||||
1: front-right, 2: back-left, 3: front-left, 4: back-right
|
||||
:::
|
||||
|
||||
##### Other Platforms
|
||||
|
||||
To enable the `mc_raptor` module in other platforms, just add `CONFIG_MODULES_MC_RAPTOR=y` and `CONFIG_LIB_RL_TOOLS=y`
|
||||
|
||||
```diff
|
||||
+++ b/boards/px4/fmu-v6c/raptor.px4board
|
||||
@@ -35,2 +35,3 @@
|
||||
CONFIG_DRIVERS_UAVCAN=y
|
||||
+CONFIG_LIB_RL_TOOLS=y
|
||||
CONFIG_MODULES_AIRSPEED_SELECTOR=y
|
||||
@@ -64,2 +65,3 @@
|
||||
CONFIG_MODULES_MC_POS_CONTROL=y
|
||||
+CONFIG_MODULES_MC_RAPTOR=y
|
||||
CONFIG_MODULES_MC_RATE_CONTROL=y
|
||||
```
|
||||
|
||||
#### Results
|
||||
|
||||
Even though there were moderate winds (~ 5 m/s) during the test, we found good figure-eight tracking performance at velocities up to 12 m/s:
|
||||
|
||||
|
||||
|
||||
We also tested the linear velocity in a straight line and found that the RAPTOR policy can reliably fly at > 17 m/s (the wind direction was orthogonal to the line):
|
||||
|
||||
|
||||
|
||||
### 문제 해결
|
||||
|
||||
#### 로깅
|
||||
|
||||
Use this logging configuration to log all relevant topics at maximum rate:
|
||||
|
||||
```sh
|
||||
cat > logger_topics.txt << EOF
|
||||
raptor_status 0
|
||||
raptor_input 0
|
||||
trajectory_setpoint 0
|
||||
vehicle_local_position 0
|
||||
vehicle_angular_velocity 0
|
||||
vehicle_attitude 0
|
||||
vehicle_status 0
|
||||
actuator_motors 0
|
||||
EOF
|
||||
```
|
||||
|
||||
Use mavproxy FTP to upload it:
|
||||
|
||||
```sh
|
||||
mavproxy.py
|
||||
```
|
||||
|
||||
##### Real
|
||||
|
||||
```sh
|
||||
ftp mkdir /fs/microsd/etc
|
||||
ftp mkdir /fs/microsd/etc/logging
|
||||
ftp put logger_topics.txt /fs/microsd/etc/logging/logger_topics.txt
|
||||
```
|
||||
|
||||
##### SITL
|
||||
|
||||
```sh
|
||||
ftp mkdir etc
|
||||
ftp mkdir logging
|
||||
ftp put logger_topics.txt etc/logging/logger_topics.txt
|
||||
```
|
||||
@@ -0,0 +1,77 @@
|
||||
# TensorFlow Lite Micro (TFLM)
|
||||
|
||||
The PX4 [MC Neural Networks Control](../neural_networks/mc_neural_network_control.md) module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) integrates a neural network that uses the [TensorFlow Lite Micro (TFLM)](https://github.com/tensorflow/tflite-micro) inference library.
|
||||
|
||||
This is a mature inference library intended for use on embedded devices, and is hence a suitable choice for PX4.
|
||||
|
||||
This guide explains how the TFLM library is integrated into the [mc_nn_control](../modules/modules_controller.md#mc-nn-control) module, and the changes you would have to make to use it for your own neural network.
|
||||
|
||||
:::tip
|
||||
For more information, see the [TFLM guide](https://ai.google.dev/edge/litert/microcontrollers/get_started).
|
||||
:::
|
||||
|
||||
## TLMF NN Formats
|
||||
|
||||
TFLM uses networks in its own [tflite format](https://ai.google.dev/edge/litert/models/convert).
|
||||
However, since many microcontrollers do not have native filesystem support, a tflite file can be converted to a C++ source and header file.
|
||||
|
||||
This is what is done in `mc_nn_control`.
|
||||
The tflight neural network is represented in code by the files [`control_net.cpp`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mc_nn_control/control_net.cpp) and [`control_net.hpp`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mc_nn_control/control_net.hpp).
|
||||
|
||||
### Getting a Network in tflite Format
|
||||
|
||||
There are many online resource for generating networks in the `.tflite` format.
|
||||
|
||||
For this example we trained the network in the open source [Aerial Gym Simulator](https://ntnu-arl.github.io/aerial_gym_simulator/).
|
||||
Aerial Gym includes a guide, and supports RL both for control and vision-based navigation tasks.
|
||||
|
||||
The project includes conversion code for `PyTorch -> TFLM` in the [resources/conversion](https://github.com/ntnu-arl/aerial_gym_simulator/tree/main/resources/conversion) folder.
|
||||
|
||||
### Updating `mc_nn_control` with your own NN
|
||||
|
||||
You can convert a `.tflite` network into a `.cc` file in the ubuntu terminal with this command:
|
||||
|
||||
```sh
|
||||
xxd -i converted_model.tflite > model_data.cc
|
||||
```
|
||||
|
||||
You will then have to modify the `control_net.hpp` and `control_net.cpp` to include the data from `model_data.cc`:
|
||||
|
||||
- Take the size of the network in the bottom of the `.cc` file and replace the size in `control_net.hpp`.
|
||||
- Take the data in the model array in the `cc` file, and replace the ones in `control_net.cpp`.
|
||||
|
||||
You are now ready to run your own network.
|
||||
|
||||
## Code Explanation
|
||||
|
||||
This section explains the code used to integrate the NN in `control_net.cpp`.
|
||||
|
||||
### Operations and Resolver
|
||||
|
||||
Firstly we need to create the resolver and load the needed operators to run inference on the NN.
|
||||
This is done in the top of `mc_nn_control.cpp`.
|
||||
The number in `MicroMutableOpResolver<3>` represents how many operations you need to run the inference.
|
||||
|
||||
A full list of the operators can be found in the [micro_mutable_op_resolver.h](https://github.com/tensorflow/tflite-micro/blob/main/tensorflow/lite/micro/micro_mutable_op_resolver.h) file.
|
||||
There are quite a few supported operators, but you will not find the most advanced ones.
|
||||
In the control example the network is fully connected so we use `AddFullyConnected()`.
|
||||
Then the activation function is ReLU, and we `AddAdd()` for the bias on each neuron.
|
||||
|
||||
### Interpreter
|
||||
|
||||
In the `InitializeNetwork()` we start by setting up the model that we loaded from the source and header file.
|
||||
Next is to set up the interpreter, this code is taken from the TFLM documentation and is thoroughly explained there.
|
||||
The end state is that the `_control_interpreter` is set up to later run inference with the `Invoke()` member function.
|
||||
The `_input_tensor` is also defined, it is fetched from `_control_interpreter->input(0)`.
|
||||
|
||||
### 입력
|
||||
|
||||
The `_input_tensor` is filled in the `PopulateInputTensor()` function.
|
||||
`_input_tensor` works by accessing the `->data.f` member array and fill in the required inputs for your network.
|
||||
The inputs used in the control network is covered in [MC Neural Networks Control](../neural_networks/mc_neural_network_control.md).
|
||||
|
||||
### 출력
|
||||
|
||||
For the outputs the approach is fairly similar to the inputs.
|
||||
After setting the correct inputs, calling the `Invoke()` function the outputs can be found by getting `_control_interpreter->output(0)`.
|
||||
And from the output tensor you get the `->data.f` array.
|
||||
Reference in New Issue
Block a user