... | ... | @@ -3,7 +3,7 @@ |
|
|
|
|
|
# Intro
|
|
|
|
|
|
This package is used to control the landing on the (moving) aruco marker. It consists of two cascaded nodes: The `velocity_controller` and the `velocity_commander`. Their interdependence is shown in the figure below.
|
|
|
This package is used to control the landing on the (moving) aruco marker. Currently its is only capable of keeping a hovering position over the marker. The package consists of two cascaded nodes: The `velocity_controller` and the `velocity_commander`. Their interdependence is shown in the figure below.
|
|
|
|
|
|
```mermaid
|
|
|
graph LR
|
... | ... | @@ -31,7 +31,7 @@ graph LR |
|
|
class A,B,C,D,E empty
|
|
|
```
|
|
|
|
|
|
The `velocity_controller` uses the position of the aruco marker relative to the camera and the current position of the pixhawk to build up an internal transformation tree (see tbd). This tree is used to estimate the position of the drone, relative to the aruco marker. This leads to the control deviation which is the input to the controller. The controller itself is designed as a PI (proportional-integral) controller. The gains can be adjusted by publishing a float value to the given topic. The controller output is then send to the `velocity_commander`. This node fits the commanded velocity into the PX4 internal datastructure for instrumenting its base controllers. \
|
|
|
The `velocity_controller` uses the position of the aruco marker relative to the camera and the current attitude of the pixhawk to build up an internal transformation tree (see [here](#determine-control-deviation-e)). This tree is used to estimate the position of the drone, relative to the aruco marker. This leads to the control deviation which is the input to the controller. The controller itself is designed as a PI (proportional-integral) controller. The gains can be adjusted by publishing a float value to the given topic. The controller output is then send to the `velocity_commander`. This node fits the commanded velocity into the PX4 internal datastructure for instrumenting its base controllers. \
|
|
|
**Note:** The existence of two nodes for this packages has evolved during their development. To keep a better overview and to avoid delays due to interprocess communication, the two nodes could be merged into a single one.
|
|
|
|
|
|
## Input
|
... | ... | @@ -76,7 +76,7 @@ These transformations should not be used for further processing. Their purpose i |
|
|
|
|
|
# Quickstart
|
|
|
|
|
|
As explained in the [introduction](#intro), this package consists of two nodes. In the following, quickstart guides for only using the `velocity_commander` and for using the full setup are given. These can be executed in a simulation with gazebo or on the target hardware. In case the procedure differs, this is explained. \
|
|
|
As explained in the [introduction](#intro), this package consists of two nodes. In the following, three quickstart guides are given, which build up on one another. The first one uses the `velocity_commander` only. The second adds the `velocity_controller` and the third one demonstrates the application of the `image_processing` node with this node. The first two guides can be applied in a simulation with gazebo or on the target hardware. In case the procedure differs, this is explained. \
|
|
|
To follow this quickstart manual, [QGroundControl](https://docs.qgroundcontrol.com/master/en/getting_started/quick_start.html) must be installed. Also for execution on the target hardware, make sure that the [RTPS Connection](hardware/rtps-connection) is set up properly.
|
|
|
|
|
|
## Velocity Commmander only
|
... | ... | @@ -127,7 +127,7 @@ If an error occurs, this package is probably not installed. To fix this, type: |
|
|
sudo apt-get install ros-$ROS_DISTRO-teleop-twist-keyboard
|
|
|
```
|
|
|
|
|
|
Once the node is started, the avaible keys to control the drone are presented. For the current setup, the Holonomic mode must be used by pressing the shift key. \
|
|
|
Once the node is started, the available keys to control the drone are presented. For the current setup, the Holonomic mode must be used by pressing the shift key. \
|
|
|
To start the drone, go to QGroundControl, press the `Takeoff` button on the left and confirm by moving the slider on the bottom of the window. Once the drone has reached its hold altitude, click on the flight mode in the top left corner (on the right of the 'Flying' tag) and choose `Offboard`. Now switch back to the terminal with the teleoperation node. When applying the shown controls, the drone moves according to these commands.
|
|
|
|
|
|
## Landing Controller package
|
... | ... | @@ -138,13 +138,13 @@ Then execute the corresponding launch file, depending on wether simulation or ta |
|
|
ros2 launch landing_controller simulation.launch.py
|
|
|
ros2 launch landing_controller realworld.launch.py
|
|
|
```
|
|
|
The content of these launch files is discussed [below](#launch-system). \
|
|
|
The content of these launch files is discussed [below](#launch-system).
|
|
|
|
|
|
To simulate the image processing, start the provided node:
|
|
|
```
|
|
|
ros2 run landing_controller test_pub_aruco
|
|
|
```
|
|
|
This simulates the transformation from the camera frame to the aruco marker frame (which is usually generated by the nodes from the `image_processing` package). At the state of writing, the simulated aruco marker moves in a circle around the home position of the drone. The movement of is generated in the `update_marker` method in the `test_pub_aruco.py` file. It could be modified to e.g. random or straight movements. \
|
|
|
This simulates the transformation from the camera frame to the aruco marker frame (which is usually generated by the nodes from the `image_processing` package). At the state of writing, the simulated aruco marker moves in a circle around the home position of the drone. The movement of is generated in the `update_marker` method in the `test_pub_aruco.py` file. It could be modified to e.g. random or straight movements.
|
|
|
|
|
|
Finally, the commanding authority must be given to the Raspberry Pi using QGroundControl as explained in the last chapter (i.e. setting the flight mode to Offboard).
|
|
|
|
... | ... | @@ -170,14 +170,14 @@ graph TD; |
|
|
|
|
|
## Entry Launchfiles
|
|
|
|
|
|
The launch files that are supposed to be called using `ros2 launch` are `simulation.launch.py` and `realworld.launch.py`. Both of them start the `micrortps_agent` (see [RTPS Communication](/eriksuer/specialtopics/-/wikis/hardware/rtps-communication), but with different parameters. While the simulation launcher starts it on the UDP port, the realworld launch file accesses the serial port `ttyUSB0`. After setting up the RTPS connection, both launch files call `general.launch.py`.
|
|
|
The launch files that are supposed to be called using `ros2 launch` are `simulation.launch.py` and `realworld.launch.py`. Both of them start the `micrortps_agent` (see [RTPS Communication](/eriksuer/specialtopics/-/wikis/hardware/rtps-communication)), but with different parameters. While the simulation launcher starts it on the UDP port, the realworld launch file accesses the serial port `ttyUSB0`. After setting up the RTPS connection, both launch files call `general.launch.py`.
|
|
|
|
|
|
## General Launchfile
|
|
|
|
|
|
This launch file starts all nodes which are independent of the environment (i.e. simulation or realworld). At first the `velocity_controller` and `velocity_commander` are started. Afterwards the launch file calls the rosbag to record all necessary topics. Therefore, the `VelocityCommander` class is examined and all topics which communicate with it are added to the list with the recorded topics.
|
|
|
|
|
|
# Documentation of nodes
|
|
|
The `landing_controller` package consists of two nodes. Their main function an how they interact with each other is explained in the [Intro](#intro). In the following, they are examined in more detail.
|
|
|
The `landing_controller` package consists of two nodes. Their main function and how they interact with each other is explained in the [Intro](#intro). In the following, they are examined in more detail.
|
|
|
|
|
|
## Velocity Controller
|
|
|
The `velocity_controller` uses the position of the aruco marker and the current attitude which is calculated by the PX4 firmware to determine the control deviation e. This serves as input for the controller, which outputs a velocity command to the PX4. \
|
... | ... | @@ -205,16 +205,26 @@ The values for $`T_{sys}`$ and $`T_{sys,delay}`$ can be determined by experiment |
|
|
|
|
|
![system_identification.svg](uploads/d5d5ce6a9ea4211dd58ab6df5463846d/system_identification.svg)
|
|
|
|
|
|
The value of $`T_{sys,delay}`$ is the time between the step command and the first reaction of the velocity response (here $´0.25s´$) and $`T_{sys}`$ is the time from the first response until $`63%`$ of the final value is reached (here $´0.65s´$). The PT1 approximation with delay can now be simulated with exactly the same input. The result (yellow line) shows, that it is a very good representation of the dynamics. \
|
|
|
The value of $`T_{sys,delay}`$ is the time between the step command and the first reaction of the velocity response (here $`0.25s`$) and $`T_{sys}`$ is the time from the first response until $`63`$% of the final value is reached (here $`0.65s`$). The PT1 approximation with delay can now be simulated with exactly the same input. The result (yellow line) shows, that it is a very good representation of the dynamics. \
|
|
|
The transfer function now serves as the basis for tuning the PI controller (see [Controller](#controller)).
|
|
|
|
|
|
- Identification as PT1 element
|
|
|
|
|
|
### Determine control deviation e
|
|
|
- internal tf tree
|
|
|
- determining error e
|
|
|
The input to the controller is the control deviation e. This sections desribes how it is determined. The node subscribes to the transformation messages in the topic `/tf`. With the help of the [tf2_ros package](http://wiki.ros.org/tf2_ros) an internal transformation tree is built up. The following graphic shows which frames are of importance and how their relation is determined:
|
|
|
|
|
|
```mermaid
|
|
|
graph TD
|
|
|
|
|
|
map-->|static rotation around elementary axis|ned
|
|
|
ned-->|Estimated attitude of pixhawk|pixhawk
|
|
|
pixhawk-->|fixed by construction|camera
|
|
|
camera-->|image_processing node|aruco_marker
|
|
|
```
|
|
|
|
|
|
This transformation tree can now be used to transform a point from any one of these frames to any other frame. In this case, the origin of the `aruco_marker` frame is transformed into the `ned` frame (see [Velocity Commander](#velocity-commander) to understand, why it must be transformed into the `ned` frame). The result can be interpreted as a 3D Vector in the global frame of the pixhawk to the aruco marker. When discarding the z-component, it represents only the lateral deviation. This is used as the control deviation e. If the controller can bring this vector two a zero in both components, the drone is hovering right above the aruco marker.
|
|
|
|
|
|
### Controller
|
|
|
For the landing controller, a PI controller with the following transfer function is used:
|
|
|
To control the control error to zero, a PI controller with the following transfer function is used:
|
|
|
|
|
|
```math
|
|
|
F_{ctrl} = \frac{K_I}{s} + K_P = \frac{K_I + K_Ps}{s}
|
... | ... | @@ -229,4 +239,4 @@ When the lag element is discarded, the gains $`K_I`$ and $`K_P`$ can now be calc |
|
|
In the `velocity_controller` node, the controller gains are stored in the dictionary `gains`, which is a class variable. It contains the keys "P" and "I". The node subscribes to the topics which are stored under the TOPICS class variable (currently `"/landing_controller/p_gain"` and `"/landing_controller/i_gain"`). If a float is published to these topics, the local controller gains are overwritten with these values.
|
|
|
|
|
|
## Velocity Commander
|
|
|
-> no arming nor changing mode |
|
|
\ No newline at end of file |
|
|
The `velocity_commander` is used to translate the commands from the `velocity_controller` into a px4 understandable format. In previous versions it was also used to arm the drone and let it take off, but currently this is done manually by the pilot. The authority is then given to the velocity commander by changing the flight mode from a manual one to offboard, using QGroundControl. Most of the functionality is taken from the [PX4 wiki page](https://docs.px4.io/master/en/ros/ros2_offboard_control.html). As one can see there, the px4 internal topic is called `vehicle_local_position_setpoint`. The [description](https://github.com/PX4/PX4-Autopilot/blob/v1.12.1/msg/vehicle_local_position_setpoint.msg) for this topic shows, that the commands are given in the NED frame of the pixhawk. That is why this frame is also chosen as the operating frame of the velocity controller. |
|
|
\ No newline at end of file |