Compare commits

..

6 Commits

Author SHA1 Message Date
Hamish Willee c97a332d18 Update aws docs deployment (match current 1.16) 2025-10-01 15:38:05 +10:00
PX4 Build Bot bd71881f8a New Crowdin translations - ko (#25659)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
2025-10-01 13:53:06 +10:00
Hamish Willee 4dab1108c3 VehicleOdometry.msg - clarify frames (#23444) 2025-10-01 10:03:09 +10:00
Henry Kotzé dbd13070e5 esp32: pwm register updates correctly on change (#25653)
- removed the bug where some overflow would occur on the PWM signal when
  changing the duty cycle of the signal after power up. (PWM_MAIN_DIS,
PWM_MAIN_MIN or PWM_MAIN_MAX)

removed commented code

cleanup of previous cherry-pick

Co-authored-by: henrykotze <henry@autonosky.com>
2025-09-30 11:15:06 -08:00
Jacob Dahl f3b2599d33 ekf: range fusion: fix height ref (#25654)
* ekf2: range height skip "unhealthy" samples, but respect timeout

 - we should never directly use an "unhealthy" range finder sample for
   state corrections or resets, but we also shouldn't immediately abort
   active rng_hgt until the timeout has passed

* check starting_conditions_passing once

* ekf2: conditional range aid change height ref

---------

Co-authored-by: Daniel Agar <daniel@agar.ca>
2025-09-30 11:14:26 -08:00
Daniel Agar e3309b9f87 ekf2: rng don't allow bad measurement in bad_acc_vertical (#25636)
- if bad vertical acceleration is detected there's an emergency case
   where rejected range finder observations are allowed to be used, but
   this still can't happen if the sample itself is known to be bag
2025-09-30 11:14:04 -08:00
63 changed files with 625 additions and 797 deletions
@@ -7,42 +7,50 @@ on:
- "release/**"
paths:
- "docs/en/**"
- "docs/zh/**"
- "docs/uk/**"
- "docs/ko/**"
pull_request:
branches:
- "**"
paths:
- "docs/en/**"
workflow_dispatch:
- "docs/zh/**"
- "docs/uk/**"
- "docs/ko/**"
permissions:
contents: read
actions: read
id-token: write # for AWS OIDC
concurrency:
group: docs-deploy
cancel-in-progress: false
env:
BRANCH_NAME: ${{ github.head_ref || github.ref_name }}
jobs:
build:
runs-on:
[
runs-on,
runner=8cpu-linux-x64,
image=ubuntu24-full-x64,
"run-id=${{ github.run_id }}",
spot=false,
extras=s3-cache,
]
runs-on: [runs-on,runner=8cpu-linux-x64,image=ubuntu24-full-x64,"run-id=${{ github.run_id }}",spot=false,extras=s3-cache]
outputs:
branchname: ${{ steps.set-branch.outputs.branchname }}
releaseversion: ${{ steps.set-version.outputs.releaseversion }}
steps:
- uses: runs-on/action@v1
- name: Checkout
uses: actions/checkout@v4
- id: set-branch
run: echo "branchname=${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}}" >> $GITHUB_OUTPUT
- id: set-version
run: |
branch="${{ steps.set-branch.outputs.branchname }}"
if [[ "$branch" == "main" ]]; then
version="main"
else
version="v${branch#release/}"
fi
echo "releaseversion=$version" >> $GITHUB_OUTPUT
- name: Setup Node
uses: actions/setup-node@v4
with:
@@ -55,6 +63,8 @@ jobs:
- name: Build with VitePress
working-directory: ./docs
env:
BRANCH_NAME: ${{ steps.set-version.outputs.releaseversion }}
run: |
npm run docs:build_ubuntu
touch .vitepress/dist/.nojekyll
@@ -91,14 +101,14 @@ jobs:
- name: Upload HTML with short cache
run: |
aws s3 sync ~/_book/ s3://px4-docs/${{ env.BRANCH_NAME }}/ \
aws s3 sync ~/_book/ s3://px4-docs/${{ needs.build.outputs.releaseversion }}/ \
--delete \
--exclude "*" --include "*.html" \
--cache-control "public, max-age=60"
- name: Upload assets with long cache
run: |
aws s3 sync ~/_book/ s3://px4-docs/${{ env.BRANCH_NAME }}/ \
aws s3 sync ~/_book/ s3://px4-docs/${{ needs.build.outputs.releaseversion }}/ \
--delete \
--exclude "*.html" \
--cache-control "public, max-age=86400, immutable"
@@ -1,5 +1,5 @@
#!/bin/sh
# @name Generic Ackermann Rover
# @name Rover Ackermann
# @type Rover
# @class Rover
@@ -14,32 +14,30 @@ param set-default SIM_GZ_EN 1 # Gazebo bridge
param set-default NAV_ACC_RAD 0.5
# Ackermann Parameters
param set-default RA_WHEEL_BASE 0.5
param set-default RA_WHEEL_BASE 0.321
param set-default RA_ACC_RAD_GAIN 2
param set-default RA_ACC_RAD_MAX 1.5
param set-default RA_ACC_RAD_MAX 3
param set-default RA_MAX_STR_ANG 0.5236
param set-default RA_STR_RATE_LIM 360
# Rate Control Parameters
param set-default RO_YAW_RATE_I 0.01
param set-default RO_YAW_RATE_P 0.25
param set-default RO_YAW_RATE_LIM 130
param set-default RO_YAW_ACCEL_LIM 800
param set-default RO_YAW_DECEL_LIM 800
param set-default RO_YAW_RATE_CORR 1
param set-default RO_YAW_EXPO 0.85
param set-default RO_YAW_SUPEXPO 0.3
# Rover Control Parameters
param set-default RO_ACCEL_LIM 3
param set-default RO_DECEL_LIM 6
param set-default RO_JERK_LIM 15
param set-default RO_MAX_THR_SPEED 3.1
# Attitude Control Parameters
# Rover Rate Control Parameters
param set-default RO_YAW_RATE_I 0.1
param set-default RO_YAW_RATE_P 1
param set-default RO_YAW_RATE_LIM 180
param set-default RO_YAW_RATE_CORR 1
# Rover Attitude Control Parameters
param set-default RO_YAW_P 3
# Velocity Control Parameters
param set-default RO_ACCEL_LIM 4
param set-default RO_DECEL_LIM 6
param set-default RO_JERK_LIM 10
param set-default RO_MAX_THR_SPEED 3.1
param set-default RO_SPEED_LIM 2.5
param set-default RO_SPEED_I 0.01
# Rover Velocity Control Parameters
param set-default RO_SPEED_LIM 3
param set-default RO_SPEED_I 0.1
param set-default RO_SPEED_P 1
param set-default RO_SPEED_RED 1
@@ -50,8 +48,8 @@ param set-default PP_LOOKAHD_MIN 1
# Wheels
param set-default SIM_GZ_WH_FUNC1 101
param set-default SIM_GZ_WH_MIN1 70
param set-default SIM_GZ_WH_MAX1 130
param set-default SIM_GZ_WH_MIN1 0
param set-default SIM_GZ_WH_MAX1 200
param set-default SIM_GZ_WH_DIS1 100
# Steering
@@ -1,5 +1,5 @@
#!/bin/sh
# @name Generic Mecanum Rover
# @name Aion Robotics R1 Rover
# @type Rover
# @class Rover
@@ -7,15 +7,14 @@
PX4_SIMULATOR=${PX4_SIMULATOR:=gz}
PX4_GZ_WORLD=${PX4_GZ_WORLD:=rover}
PX4_SIM_MODEL=${PX4_SIM_MODEL:=rover_mecanum}
PX4_SIM_MODEL=${PX4_SIM_MODEL:=r1_rover_mecanum}
param set-default SIM_GZ_EN 1 # Gazebo bridge
param set-default NAV_ACC_RAD 0.5
# Mecanum Parameters
param set-default RM_WHEEL_TRACK 0.6
param set-default RM_YAW_STK_GAIN 0.6
param set-default RM_WHEEL_TRACK 0.3
# Rover Control Parameters
param set-default RO_ACCEL_LIM 3
@@ -30,21 +29,15 @@ param set-default RO_YAW_RATE_LIM 120
param set-default RO_YAW_ACCEL_LIM 240
param set-default RO_YAW_DECEL_LIM 1000
param set-default RO_YAW_RATE_CORR 1.75
param set-default RO_YAW_EXPO 0.85
param set-default RO_YAW_SUPEXPO 0.3
# Rover Attitude Control Parameters
param set-default RO_YAW_P 5
# Velocity Control Parameters
param set-default RO_ACCEL_LIM 4
param set-default RO_DECEL_LIM 6
param set-default RO_JERK_LIM 10
param set-default RO_MAX_THR_SPEED 3.1
param set-default RO_SPEED_LIM 2.5
param set-default RO_SPEED_I 0.01
param set-default RO_SPEED_P 0.1
param set-default RO_SPEED_RED 0.5
# Rover Velocity Control Parameters
param set-default RO_SPEED_LIM 2
param set-default RO_SPEED_I 0.5
param set-default RO_SPEED_P 1
param set-default RO_SPEED_RED 1
# Pure Pursuit parameters
param set-default PP_LOOKAHD_GAIN 0.5
@@ -55,24 +48,24 @@ param set-default PP_LOOKAHD_MIN 1
param set-default SENS_EN_MAGSIM 1
# Actuator mapping
param set-default SIM_GZ_WH_FUNC1 104 # left wheel back
param set-default SIM_GZ_WH_FUNC1 102 # right wheel front
param set-default SIM_GZ_WH_MIN1 70
param set-default SIM_GZ_WH_MAX1 130
param set-default SIM_GZ_WH_DIS1 100
param set-default SIM_GZ_WH_FUNC2 103 # right wheel back
param set-default SIM_GZ_WH_FUNC2 101 # left wheel front
param set-default SIM_GZ_WH_MIN2 70
param set-default SIM_GZ_WH_MAX2 130
param set-default SIM_GZ_WH_DIS2 100
param set-default SIM_GZ_WH_FUNC3 102 # left wheel front
param set-default SIM_GZ_WH_FUNC3 104 # right wheel back
param set-default SIM_GZ_WH_MIN3 70
param set-default SIM_GZ_WH_MAX3 130
param set-default SIM_GZ_WH_DIS3 100
param set-default SIM_GZ_WH_FUNC4 101 # right wheel front
param set-default SIM_GZ_WH_FUNC4 103 # left wheel back
param set-default SIM_GZ_WH_MIN4 70
param set-default SIM_GZ_WH_MAX4 130
param set-default SIM_GZ_WH_DIS4 100
param set-default SIM_GZ_WH_REV 0
param set-default SIM_GZ_WH_REV 10
@@ -17,7 +17,6 @@ param set-default NAV_ACC_RAD 0.5
param set-default RD_WHEEL_TRACK 0.6
param set-default RD_TRANS_DRV_TRN 0.785398
param set-default RD_TRANS_TRN_DRV 0.174533
param set-default RD_YAW_STK_GAIN 0.6
# Rate Control Parameters
param set-default RO_YAW_RATE_I 0.01
@@ -26,8 +25,6 @@ param set-default RO_YAW_RATE_LIM 250
param set-default RO_YAW_ACCEL_LIM 400
param set-default RO_YAW_DECEL_LIM 800
param set-default RO_YAW_RATE_CORR 1
param set-default RO_YAW_EXPO 0.85
param set-default RO_YAW_SUPEXPO 0.3
# Attitude Control Parameters
param set-default RO_YAW_P 5
@@ -80,8 +80,10 @@ px4_add_romfs_files(
4009_gz_r1_rover
4010_gz_x500_mono_cam
4011_gz_lawnmower
4012_gz_rover_ackermann
4013_gz_x500_lidar_2d
4014_gz_x500_mono_cam_down
4015_gz_r1_rover_mecanum
4016_gz_x500_lidar_down
4017_gz_x500_lidar_front
4018_gz_quadtailsitter
@@ -112,8 +114,6 @@ px4_add_romfs_files(
17002_flightgear_tf-g2
50000_gz_rover_differential
51000_gz_rover_ackermann
52000_gz_rover_mecanum
60002_gz_uuv_bluerov2_heavy
@@ -1,45 +0,0 @@
#!/bin/sh
#
# @name Hiwonder Tracked
#
# @url https://www.hiwonder.com/products/suspended-shock-absorbing-tracked-chassis?variant=40378709835863
#
# @type Rover
# @class Rover
#
. ${R}etc/init.d/rc.rover_differential_defaults
param set-default HIWONDER_EMM_EN 1 # Enable motor driver
param set-default BAT1_N_CELLS 3
param set-default NAV_ACC_RAD 0.5
# Differential Parameters
param set-default RD_WHEEL_TRACK 0.16
param set-default RD_TRANS_DRV_TRN 0.785398
param set-default RD_TRANS_TRN_DRV 0.0872665
# Rover Rate Control Parameters
param set-default RO_YAW_EXPO 0.2
param set-default RO_YAW_SUPEXPO 0.1
param set-default RO_YAW_RATE_I 0.1
param set-default RO_YAW_RATE_P 0.1
param set-default RO_YAW_RATE_LIM 140
# Rover Attitude Control Parameters
param set-default RO_YAW_P 5
# Rover Velocity Control Parameters
param set-default RO_ACCEL_LIM 1
param set-default RO_DECEL_LIM 1
param set-default RO_JERK_LIM 10
param set-default RO_MAX_THR_SPEED 0.3
param set-default RO_SPEED_LIM 0.28
param set-default RO_SPEED_I 0.05
param set-default RO_SPEED_P 0.1
param set-default RO_SPEED_RED 1
# Pure Pursuit parameters
param set-default PP_LOOKAHD_GAIN 1
param set-default PP_LOOKAHD_MAX 10
param set-default PP_LOOKAHD_MIN 1
@@ -1,46 +0,0 @@
#!/bin/sh
#
# @name Hiwonder Ackermann
#
# @url https://www.hiwonder.com/products/ackermann-steering-chassis?variant=40382428348503
#
# @type Rover
# @class Rover
#
. ${R}etc/init.d/rc.rover_ackermann_defaults
param set-default HIWONDER_EMM_EN 1 # Enable motor driver
param set-default BAT1_N_CELLS 3
param set-default NAV_ACC_RAD 0.5
# Ackermann Parameters
param set-default RA_WHEEL_BASE 0.17
param set-default RA_ACC_RAD_GAIN 1
param set-default RA_ACC_RAD_MAX 1
param set-default RA_MAX_STR_ANG 0.698132
# Rover Rate Control Parameters
param set-default RO_YAW_EXPO 0.6
param set-default RO_YAW_SUPEXPO 0.3
param set-default RO_YAW_RATE_I 0.1
param set-default RO_YAW_RATE_P 0.1
param set-default RO_YAW_RATE_LIM 150
# Rover Attitude Control Parameters
param set-default RO_YAW_P 5
# Rover Velocity Control Parameters
param set-default RO_ACCEL_LIM 1.6
param set-default RO_DECEL_LIM 3
param set-default RO_JERK_LIM 10
param set-default RO_MAX_THR_SPEED 1.2
param set-default RO_SPEED_LIM 1.1
param set-default RO_SPEED_I 0.05
param set-default RO_SPEED_P 0.1
param set-default RO_SPEED_RED 1
# Pure Pursuit parameters
param set-default PP_LOOKAHD_GAIN 1
param set-default PP_LOOKAHD_MAX 10
param set-default PP_LOOKAHD_MIN 1
@@ -1,43 +0,0 @@
#!/bin/sh
#
# @name Hiwonder Mecanum
#
# @url https://www.hiwonder.com/products/large-metal-4wd-vehicle-chassis-green
#
# @type Rover
# @class Rover
#
. ${R}etc/init.d/rc.rover_mecanum_defaults
param set-default HIWONDER_EMM_EN 1 # Enable motor driver
param set-default BAT1_N_CELLS 3
param set-default NAV_ACC_RAD 0.5
# Mecanum Parameters
param set-default RM_WHEEL_TRACK 0.16
# Rover Rate Control Parameters
param set-default RO_YAW_EXPO 0.2
param set-default RO_YAW_SUPEXPO 0.1
param set-default RO_YAW_RATE_I 0.1
param set-default RO_YAW_RATE_P 0.1
param set-default RO_YAW_RATE_LIM 130
# Rover Attitude Control Parameters
param set-default RO_YAW_P 5
# Rover Velocity Control Parameters
param set-default RO_ACCEL_LIM 0.9
param set-default RO_DECEL_LIM 1.2
param set-default RO_JERK_LIM 10
param set-default RO_MAX_THR_SPEED 0.5
param set-default RO_SPEED_LIM 0.45
param set-default RO_SPEED_I 0.05
param set-default RO_SPEED_P 0.1
param set-default RO_SPEED_RED 1
# Pure Pursuit parameters
param set-default PP_LOOKAHD_GAIN 1
param set-default PP_LOOKAHD_MAX 10
param set-default PP_LOOKAHD_MIN 1
@@ -145,7 +145,6 @@ if(CONFIG_MODULES_ROVER_DIFFERENTIAL)
# [50000, 50999] Differential rovers
50000_generic_rover_differential
50001_aion_robotics_r1_rover
50002_hiwonder_tracked
)
endif()
@@ -154,7 +153,6 @@ if(CONFIG_MODULES_ROVER_ACKERMANN)
# [51000, 51999] Ackermann rovers
51000_generic_rover_ackermann
51001_axial_scx10_2_trail_honcho
51002_hiwonder_ackermann
)
endif()
@@ -162,7 +160,6 @@ if(CONFIG_MODULES_ROVER_MECANUM)
px4_add_romfs_files(
# [52000, 52999] Mecanum rovers
52000_generic_rover_mecanum
52001_hiwonder_mecanum
)
endif()
Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 171 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 271 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 236 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 263 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 648 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 306 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 223 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 77 KiB

After

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.6 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 21 KiB

After

Width:  |  Height:  |  Size: 2.1 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 2.2 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 2.1 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 2.1 MiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 67 KiB

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 60 KiB

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 64 KiB

+2 -6
View File
@@ -414,15 +414,11 @@
- [Basic Setup](config_rover/basic_setup.md)
- [Rate Tuning](config_rover/rate_tuning.md)
- [Attitude Tuning](config_rover/attitude_tuning.md)
- [Speed Tuning](config_rover/speed_tuning.md)
- [Velocity Tuning](config_rover/velocity_tuning.md)
- [Position Tuning](config_rover/position_tuning.md)
- [Apps & API](flight_modes_rover/api.md)
- [Complete Vehicles](complete_vehicles_rover/index.md)
- [Hiwonder Ackermann Chassi](complete_vehicles_rover/hiwonder_ackermann.md)
- [Hiwonder Tracked Chassi](complete_vehicles_rover/hiwonder_tracked.md)
- [Hiwonder Mecanum Chassi](complete_vehicles_rover/hiwonder_mecanum.md)
- [Aion Robotics R1 (Discontinued)](complete_vehicles_rover/aion_r1.md)
- [Developer Guide](frames_rover/developer_guide.md)
- [Aion Robotics R1](complete_vehicles_rover/aion_r1.md)
- [Submarines (experimental)](frames_sub/index.md)
- [BlueROV2](frames_sub/bluerov2.md)
- [Airframes Reference](airframes/airframe_reference.md)
@@ -1,98 +0,0 @@
# Hiwonder Ackermann
The [Hiwonder Ackermann](https://www.hiwonder.com/products/ackermann-steering-chassis?variant=40382428348503) rover is a bare-bones platform including a chassi, four wheels, two [motors with encoders](https://www.hiwonder.com/products/hall-encoder-dc-geared-motor?variant=40451123675223), a servo and a [motor driver board](https://www.hiwonder.com/products/4-channel-encoder-motor-driver).
The chassi offers many mounting points, providing the flexibility to attach your own flight controller, sensors and other payload.
![Hiwonder Ackermann](../../assets/airframes/rover/hiwonder_rovers/hiwonder_ackermann.png)
This documentation illustrates the setup of the rover and the configuration of the actuators.
## Parts List
::: info
The specific hardware used here only serves to examplify the process and can be easily replaced with what you have access to.
Ensure that the parts are compatible, including the ports available on your flight controller, and adapt the wiring to your hardware.
:::
The following parts are used in this build:
- Frame: [Hiwonder Ackermann Chassi](https://www.hiwonder.com/products/ackermann-steering-chassis?variant=40382428348503)
- Flight Controller: [Auterion Skynode S](https://auterion.com/product/skynode-s/) (Alternatives: [Flight Controllers](../flight_controller/index.md)).
- Receiver: [TBS Crossfire Nano RX](https://www.team-blacksheep.com/products/prod:crossfire_nano_rx?srsltid=AfmBOopvPF1mhPRIS11amSwdKf4OFZlt2ibj7XJwu05kVWt4S_L-ZNuD) (Alternatives: [PX4-Compatible Receivers](../getting_started/rc_transmitter_receiver.md#px4-compatible-receivers-compatible_receivers)).
- Power: 3S Lipo Battery
::: info
The motor driver board requires 3S, but your flight controller might require a different voltage.
To power the flight controller with the same battery you need a Dc-to-DC converter such as the ones listed in [Power Modules & Power Distribution Boards](../power_module/index.md).
(This is not the case in this build, since the flight controller used can be directly supplied by the 3S battery).
:::
- Dc-to-Dc Converter: [BEC12S-PRO](https://www.mateksys.com/?portfolio=bec12s-pro). The servo needs to be supplied with 6-8.4V. Since we are using a 3S battery, we need a Dc-to-Dc converter to transform the voltage into this range (Alternatives: Any other DC-to-DC converter with the correct input/output voltage and current rating higher than 3A).
- GPS: [RTK F9P GPS](https://holybro.com/products/h-rtk-f9p-gnss-series?srsltid=AfmBOoqmsqKx8y60GRVGfWtbcMv_V2m19V4U7-ql9R4NXtrwqzcyXlcF) (Alternatives: [Supported GNSS](../gps_compass/index.md#supported-gnss)).
- I2C Splitter
::: info
This part is only necessary if your flight controller has only one I2C port (we need one for the motor driver board and one for the compass in the gps module).
Many boards will have a dedicated GPS port (which often includes an I2C port) and one or more separate I2C ports for additional peripherals.
:::
- LTE Dongle: Used to establish a data link between the vehicle and the ground control station (There are many alternative ways to achieve this such as the ones listed in [Data Links](../data_links/index.md)).
## Wiring and Assembly
The following images shows the wiring of the various components of this build. Missing are the connections from the motors to the motor controller board.
![Hiwonder Wiring](../../assets/airframes/rover/hiwonder_rovers/hiwonder_wiring_annotated.png)
::: info
This image only serves as an example for the wiring process, with your hardware this can look very different.
Check the documentation of your parts to ensure that you connect to correct pins.
:::
Now connect the battery to the Dc-to-Dc converter to give it power.
To power the servo, connect the red (6-8.4V) and black (GND) wire to the output of the DC-to-Dc converter and the white (PWM) wire to a PWM output of your flight controller.
![Hiwonder Ackermann Servo Wiring](../../assets/airframes/rover/hiwonder_rovers/hiwonder_ackermann_wiring_annotated.png)
With the wiring complete, you can now securely attach your hardware to the chassi.
::: info
For a quick build you could use double sided tape, but for a long term solution we highly recommend 3d printing mounts that you attach to the chassi using the mounting points.
:::
## PX4 Configuration
Use _QGroundControl_ for rover configuration:
1. [Flash the rover build](../config_rover/index.md#flashing-the-rover-build) onto your flight controller with the following adjustments:
Navigate to the `rc.board_sensors` file of your board and add the following lines (for Skynode S this would be in [boards/auterion/fmu-v6s/init/rc.board_sensors](https://github.com/PX4/PX4-Autopilot/blob/main/boards/auterion/fmu-v6s/init/rc.board_sensors)):
```sh
if param compare HIWONDER_EMM_EN 1
then
hiwonder_emm start
fi
```
Also add the following line to the `rover.px4board` file of your board (for Skynode S this would be in [boards/auterion/fmu-v6s/rover.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/auterion/fmu-v6s/rover.px4board)):
```sh
CONFIG_DRIVERS_HIWONDER_EMM=y
```
2. In the [Basic Configuration](../config/index.md) section, select the [Airframe](../config/airframe.md) tab.
3. Choose **Hiwonder Ackermann** under the **Rover** category (Alternatively you can set the parameter `SYS_AUTOSTART` to `51002`).
Then configure the actuators:
1. Navigate to [Actuators Configuration & Testing](../config/actuators.md) in QGroundControl.
2. Select the Hiwonder EMM driver from the list of _Actuator Outputs_.
Assign the two populated channels of the motor controller board to `Throttle`. The channels are noted on the motor controller board (alternatively randomly assign the channels and use the actuator testing tab to find the correct assignments).
![Motor Setup](../../assets/airframes/rover/hiwonder_rovers/hiwonder_ackermann_motors.png)
3. Now ensure that both motors are spinning in the same direction. If that is not the case check the `Rev Range` box on one of the motors.
4. Arm the rover in [Manual Mode](../flight_modes_rover/manual.md#manual-mode) and use the trottle stick to drive forwards. If the rover drives backwards instead, invert the `Rev Range` checkboxes on **both** motors.
5. To configure the servo motor, assign the populated PWM channel to `Steering`. Set the minimum value to `800`, the maximum to `2200` and the disarm value to `1500`.
![Servo Setup](../../assets/airframes/rover/hiwonder_rovers/hiwonder_ackermann_servo.png)
6. Arm the rover in [Manual Mode](../flight_modes_rover/manual.md#manual-mode) and use the steering stick to move the servo. If the rover steers in the wrong direction check the `Rev Range` checkbox of the servo.
You have now successfully setup your rover and can start testing all [driving modes](../flight_modes_rover/index.md) PX4 has to offer!
@@ -1,88 +0,0 @@
# Hiwonder Mecanum
The [Hiwonder Mecanum](https://www.hiwonder.com/products/large-metal-4wd-vehicle-chassis-green) rover is a bare-bones platform including a chassi, four [mecanum wheels](https://www.hiwonder.com/products/97mm-mecanum-wheel), four [motors with encoders](https://www.hiwonder.com/products/hall-encoder-dc-geared-motor?variant=40451123675223) and a [motor driver board](https://www.hiwonder.com/products/4-channel-encoder-motor-driver).
The chassi offers many mounting points, providing the flexibility to attach your own flight controller, sensors and other payload.
![Hiwonder Mecanum](../../assets/airframes/rover/hiwonder_rovers/hiwonder_mecanum.png)
This documentation illustrates the setup of the rover and the configuration of the actuators.
## Parts List
::: info
The specific hardware used here only serves to examplify the process and can be easily replaced with what you have access to.
Ensure that the parts are compatible, including the ports available on your flight controller, and adapt the wiring to your hardware.
:::
The following parts are used in this build:
- Frame: [Hiwonder Mecanum Chassi](https://www.hiwonder.com/products/large-metal-4wd-vehicle-chassis-green)
- Flight Controller: [Auterion Skynode S](https://auterion.com/product/skynode-s/) (Alternatives: [Flight Controllers](../flight_controller/index.md)).
- Receiver: [TBS Crossfire Nano RX](https://www.team-blacksheep.com/products/prod:crossfire_nano_rx?srsltid=AfmBOopvPF1mhPRIS11amSwdKf4OFZlt2ibj7XJwu05kVWt4S_L-ZNuD) (Alternatives: [PX4-Compatible Receivers](../getting_started/rc_transmitter_receiver.md#px4-compatible-receivers-compatible_receivers)).
- Power: 3S Lipo Battery
::: info
The motor driver board requires 3S, but your flight controller might require a different voltage.
To power the flight controller with the same battery you need a Dc-to-DC converter such as the ones listed in [Power Modules & Power Distribution Boards](../power_module/index.md).
(This is not the case in this build, since the flight controller used can be directly supplied by the 3S battery).
:::
- GPS: [RTK F9P GPS](https://holybro.com/products/h-rtk-f9p-gnss-series?srsltid=AfmBOoqmsqKx8y60GRVGfWtbcMv_V2m19V4U7-ql9R4NXtrwqzcyXlcF) (Alternatives: [Supported GNSS](../gps_compass/index.md#supported-gnss)).
- I2C Splitter
::: info
This part is only necessary if your flight controller has only one I2C port (we need one for the motor driver board and one for the compass in the gps module).
Many boards will have a dedicated GPS port (which often includes an I2C port) and one or more separate I2C ports for additional peripherals.
:::
- LTE Dongle: Used to establish a data link between the vehicle and the ground control station (There are many alternative ways to achieve this such as the ones listed in [Data Links](../data_links/index.md)).
## Wiring and Assembly
The following images shows the wiring of the various components of this build. Missing are the connections from the motors to the motor controller board.
![Hiwonder Wiring](../../assets/airframes/rover/hiwonder_rovers/hiwonder_wiring_annotated.png)
::: info
This image only serves as an example for the wiring process, with your hardware this can look very different.
Check the documentation of your parts to ensure that you connect to correct pins.
:::
To assemble your rover connect the motors to the chassi using the supplied screws, mount the wheels to the motor shafts (there are 2 different types of mecanum wheels, make sure you mount them to the correct motor!) and securely attach your hardware.
::: info
For a quick build you could use double sided tape, but for a long term solution we highly recommend 3d printing mounts that you attach to the chassi using the mounting points.
:::
## PX4 Configuration
Use _QGroundControl_ for rover configuration:
1. [Flash the rover build](../config_rover/index.md#flashing-the-rover-build) onto your flight controller with the following adjustments:
Navigate to the `rc.board_sensors` file of your board and add the following lines (for Skynode S this would be in [boards/auterion/fmu-v6s/init/rc.board_sensors](https://github.com/PX4/PX4-Autopilot/blob/main/boards/auterion/fmu-v6s/init/rc.board_sensors)):
```sh
if param compare HIWONDER_EMM_EN 1
then
hiwonder_emm start
fi
```
Also add the following line to the `rover.px4board` file of your board (for Skynode S this would be in [boards/auterion/fmu-v6s/rover.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/auterion/fmu-v6s/rover.px4board)):
```sh
CONFIG_DRIVERS_HIWONDER_EMM=y
```
2. In the [Basic Configuration](../config/index.md) section, select the [Airframe](../config/airframe.md) tab.
3. Choose **Hiwonder Mecanum** under the **Rover** category (Alternatively you can set the parameter `SYS_AUTOSTART` to `52001`).
Then configure the actuators:
1. Navigate to [Actuators Configuration & Testing](../config/actuators.md) in QGroundControl.
1. Select the Hiwonder EMM driver from the list of _Actuator Outputs_.
Assign the channels to the corresponding motor. The channels are noted on the motor controller board (alternatively randomly assign the channels and use the actuator testing tab to find the correct assignments).
Now ensure that the motors are all spinning in the same direction. If that is not the case check the `Rev Range` box on the ones that are spinning in the opposite direction.
![Motor Setup](../../assets/airframes/rover/hiwonder_rovers/hiwonder_mecanum_motors.png)
1. Arm the rover in [Manual Mode](../flight_modes_rover/manual.md#manual-mode) and use the trottle stick to drive forwards. If the rover drives backwards instead, invert the `Rev Range` checkboxes on **all** motors.
You have now successfully setup your rover and can start testing all [driving modes](../flight_modes_rover/index.md) PX4 has to offer!
@@ -1,88 +0,0 @@
# Hiwonder Tracked
The [Hiwonder Tracked](https://www.hiwonder.com/products/suspended-shock-absorbing-tracked-chassis?variant=40378709835863) rover is a bare-bones platform including a chassi, two tracks, two [motors with encoders](https://www.hiwonder.com/products/hall-encoder-dc-geared-motor?variant=40451123675223) and a [motor driver board](https://www.hiwonder.com/products/4-channel-encoder-motor-driver).
The chassi offers many mounting points, providing the flexibility to attach your own flight controller, sensors and other payload.
![Hiwonder Tracked](../../assets/airframes/rover/hiwonder_rovers/hiwonder_tracked.png)
This documentation illustrates the setup of the rover and the configuration of the actuators.
## Parts List
::: info
The specific hardware used here only serves to examplify the process and can be easily replaced with what you have access to.
Ensure that the parts are compatible, including the ports available on your flight controller, and adapt the wiring to your hardware.
:::
The following parts are used in this build:
- Frame: [Hiwonder Tracked Chassi](https://www.hiwonder.com/products/suspended-shock-absorbing-tracked-chassis?variant=40378709835863)
- Flight Controller: [Auterion Skynode S](https://auterion.com/product/skynode-s/) (Alternatives: [Flight Controllers](../flight_controller/index.md)).
- Receiver: [TBS Crossfire Nano RX](https://www.team-blacksheep.com/products/prod:crossfire_nano_rx?srsltid=AfmBOopvPF1mhPRIS11amSwdKf4OFZlt2ibj7XJwu05kVWt4S_L-ZNuD) (Alternatives: [PX4-Compatible Receivers](../getting_started/rc_transmitter_receiver.md#px4-compatible-receivers-compatible_receivers)).
- Power: 3S Lipo Battery
::: info
The motor driver board requires 3S, but your flight controller might require a different voltage.
To power the flight controller with the same battery you need a Dc-to-DC converter such as the ones listed in [Power Modules & Power Distribution Boards](../power_module/index.md).
(This is not the case in this build, since the flight controller used can be directly supplied by the 3S battery).
:::
- GPS: [RTK F9P GPS](https://holybro.com/products/h-rtk-f9p-gnss-series?srsltid=AfmBOoqmsqKx8y60GRVGfWtbcMv_V2m19V4U7-ql9R4NXtrwqzcyXlcF) (Alternatives: [Supported GNSS](../gps_compass/index.md#supported-gnss)).
- I2C Splitter
::: info
This part is only necessary if your flight controller has only one I2C port (we need one for the motor driver board and one for the compass in the gps module).
Many boards will have a dedicated GPS port (which often includes an I2C port) and one or more separate I2C ports for additional peripherals.
:::
- LTE Dongle: Used to establish a data link between the vehicle and the ground control station (There are many alternative ways to achieve this such as the ones listed in [Data Links](../data_links/index.md)).
## Wiring and Assembly
The following images shows the wiring of the various components of this build. Missing are the connections from the motors to the motor controller board.
![Hiwonder Wiring](../../assets/airframes/rover/hiwonder_rovers/hiwonder_wiring_annotated.png)
::: info
This image only serves as an example for the wiring process, with your hardware this can look very different.
Check the documentation of your parts to ensure that you connect to correct pins.
:::
With the wiring complete, you can now securely attach your hardware to the chassi.
::: info
For a quick build you could use double sided tape, but for a long term solution we highly recommend 3d printing mounts that you attach to the chassi using the mounting points.
:::
## PX4 Configuration
Use _QGroundControl_ for rover configuration:
1. [Flash the rover build](../config_rover/index.md#flashing-the-rover-build) onto your flight controller with the following adjustments:
Navigate to the `rc.board_sensors` file of your board and add the following lines (for Skynode S this would be in [boards/auterion/fmu-v6s/init/rc.board_sensors](https://github.com/PX4/PX4-Autopilot/blob/main/boards/auterion/fmu-v6s/init/rc.board_sensors)):
```sh
if param compare HIWONDER_EMM_EN 1
then
hiwonder_emm start
fi
```
Also add the following line to the `rover.px4board` file of your board (for Skynode S this would be in [boards/auterion/fmu-v6s/rover.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/auterion/fmu-v6s/rover.px4board)):
```sh
CONFIG_DRIVERS_HIWONDER_EMM=y
```
2. In the [Basic Configuration](../config/index.md) section, select the [Airframe](../config/airframe.md) tab.
3. Choose **Hiwonder Tracked** under the **Rover** category (Alternatively you can set the parameter `SYS_AUTOSTART` to `50002`).
Then configure the actuators:
1. Navigate to [Actuators Configuration & Testing](../config/actuators.md) in QGroundControl.
1. Select the Hiwonder EMM driver from the list of _Actuator Outputs_.
Assign one of the populated channels of the motor controller board to the `Left Motor` and one to the `Right Motor`. The channels are noted on the motor controller board (alternatively randomly assign the channels and use the actuator testing tab to find the correct assignments).
Now ensure that both motors are spinning in the same direction. If that is not the case check the `Rev Range` box on one of the motors.
![Motor Setup](../../assets/airframes/rover/hiwonder_rovers/hiwonder_tracked_motors.png)
2. Arm the rover in [Manual Mode](../flight_modes_rover/manual.md#manual-mode) and use the trottle stick to drive forwards. If the rover drives backwards instead, invert the `Rev Range` checkboxes on **both** motors.
You have now successfully setup your rover and can start testing all [driving modes](../flight_modes_rover/index.md) PX4 has to offer!
+2 -10
View File
@@ -1,13 +1,5 @@
# Complete Vehicles (Rover)
The following guides exemplify the build process for various hardware setups and can be used as reference for your own rover:
This section contains information about fully assembled vehicles that use PX4:
## Ackermann
1. [Hiwonder Ackermann Chassi](../complete_vehicles_rover/hiwonder_ackermann.md)
## Differential
1. [Hiwonder Tracked Chassi](../complete_vehicles_rover/hiwonder_tracked.md)
2. [(Discontinued) Aion Robotics R1 UGV](../complete_vehicles_rover/aion_r1.md)
## Mecanum
1. [Hiwonder Mecanum Chassi](../complete_vehicles_rover/hiwonder_mecanum.md)
1. [Aion Robotics R1 UGV (Differential Rover)](../complete_vehicles_rover/aion_r1.md)
+1 -1
View File
@@ -19,7 +19,7 @@ Configure the following [parameters](../advanced_config/parameters.md) in QGroun
If you observe a steady state error in the yaw setpoint increase the the integrator of the rate controller: [RO_YAW_RATE_I](../advanced_config/parameter_reference.md#RO_YAW_RATE_I) .
:::
The rover is now ready to drive in [Stabilized mode](../flight_modes_rover/manual.md#stabilized-mode) and the configuration can be continued with [speed tuning](speed_tuning.md).
The rover is now ready to drive in [Stabilized mode](../flight_modes_rover/manual.md#stabilized-mode) and the configuration can be continued with [velocity tuning](velocity_tuning.md).
## Attitude Controller Structure (Info Only)
+1 -1
View File
@@ -9,7 +9,7 @@ Successive steps enable [drive modes](../flight_modes_rover/index.md) with more
| 1 | [Basic Setup](basic_setup.md) | [Full manual mode](../flight_modes_rover/manual.md#manual-mode) |
| 2 | [Rate Tuning](rate_tuning.md) | [Manual acro mode](../flight_modes_rover/manual.md#acro-mode) |
| 3 | [Attitude Tuning](attitude_tuning.md) | [Manual stabilized mode](../flight_modes_rover/manual.md#stabilized-mode) |
| 4 | [Speed Tuning](speed_tuning.md) | [Manual position mode](../flight_modes_rover/manual.md#manual-mode) |
| 4 | [Velocity Tuning](velocity_tuning.md) | [Manual position mode](../flight_modes_rover/manual.md#manual-mode) |
| 5 | [Position Tuning](position_tuning.md) | [Auto modes](../flight_modes_rover/auto.md) |
::: warning
+4 -4
View File
@@ -3,7 +3,7 @@
Position tuning is required in order to use [Auto modes](../flight_modes_rover/auto.md).
:::warning
The [speed tuning](speed_tuning.md) must've already been completed before this step!
The [velocity tuning](velocity_tuning.md) must've already been completed before this step!
:::
The position controller is responsible for autonomously guiding the vehicle to a position setpoint.
@@ -41,7 +41,7 @@ To tune the position controller configure the [parameters](../advanced_config/pa
These two parameters have to be tuned as a pair, repeat until you are satisfied with the behaviour.
:::
3. Plot the `adjusted_speed_body_x_setpoint` and `measured_speed_body_x` from the [RoverSpeedStatus](../msg_docs/RoverSpeedStatus.md) message over each other.
3. Plot the `adjusted_speed_body_x_setpoint` and `measured_speed_body_x` from the [RoverVelocityStatus](../msg_docs/RoverVelocityStatus.md) message over each other.
If the tracking of these setpoints is not satisfactory adjust the values for [RO_SPEED_P](../advanced_config/parameter_reference.md#RO_SPEED_P) and [RO_SPEED_I](../advanced_config/parameter_reference.md#RO_SPEED_I).
## Path Following
@@ -79,7 +79,7 @@ The following parameters are used to tune the algorithm:
During any auto navigation task observe the behaviour of the rover and if you are unsatisfied with the path following, there are 2 steps to take:
1. Check if all the setpoints ([rate](rate_tuning.md), [attitude](attitude_tuning.md) and [speed](speed_tuning.md)) are properly tracked.
1. Check if all the setpoints ([rate](rate_tuning.md), [attitude](attitude_tuning.md) and [velocity](velocity_tuning.md)) are properly tracked.
2. Further tune the [path following algorithm](#path-following).
## Ackermann Rover Only
@@ -157,7 +157,7 @@ When targeting a position setpoint this line is constructed from the current pos
The radius of the circle around the vehicle is used to tune the controller and is often referred to as look-ahead distance.
The look-ahead distance sets how aggressive the controller behaves and is defined as $l_d = v \cdot k$.
It depends on the speed $v$ of the rover and a tuning parameter $k$ that can be set with the parameter [PP_LOOKAHD_GAIN](#PP_LOOKAHD_GAIN).
It depends on the velocity $v$ of the rover and a tuning parameter $k$ that can be set with the parameter [PP_LOOKAHD_GAIN](#PP_LOOKAHD_GAIN).
::: info
A lower value of [PP_LOOKAHD_GAIN](#PP_LOOKAHD_GAIN) makes the controller more aggressive but can lead to oscillations!
+4 -5
View File
@@ -22,9 +22,8 @@ Configure the following [parameters](../advanced_config/parameters.md) in QGroun
If you see no need to limit the yaw rate, set this parameter to the maximum yaw rate the rover can achieve:
1. Set the [RO_YAW_RATE_LIM](#RO_YAW_RATE_LIM) to the maximum possible value, then in [Acro mode](../flight_modes_rover/manual.md#acro-mode) drive the rover at full throttle and with the maximum steering input.
1. In [Manual mode](../flight_modes_rover/manual.md#manual-mode) drive the rover at full throttle and with the maximum steering angle.
2. Plot the `measured_yaw_rate` from [RoverRateStatus](../msg_docs/RoverRateStatus.md) and enter the highest observed value for [RO_YAW_RATE_LIM](#RO_YAW_RATE_LIM).
Pay attention to the units, in the log the rate is given as $rad/s$, but the parameter has to be set in $deg/s$.
:::
@@ -54,9 +53,9 @@ Configure the following [parameters](../advanced_config/parameters.md) in QGroun
To tune this parameter:
1. Put the rover in [Acro mode](../flight_modes_rover/manual.md#acro-mode) and hold the throttle stick and the right stick at a few different levels for a couple of seconds each.
2. Disarm the rover and from the flight log plot the `adjusted_yaw_rate_setpoint` and the `measured_yaw_rate` from [RoverRateStatus](../msg_docs/RoverRateStatus.md) over each other.
3. Increase [RO_YAW_RATE_P](#RO_YAW_RATE_P) if the measured value does not track the setpoint fast enough or decrease it if the measurement overshoots the setpoint by too much.
4. Repeat until you are satisfied with the behaviour.
1. Disarm the rover and from the flight log plot the `adjusted_yaw_rate_setpoint` and the `measured_yaw_rate` from [RoverRateStatus](../msg_docs/RoverRateStatus.md) over each other.
1. Increase [RO_YAW_RATE_P](#RO_YAW_RATE_P) if the measured value does not track the setpoint fast enough or decrease it if the measurement overshoots the setpoint by too much.
1. Repeat until you are satisfied with the behaviour.
:::
4. [RO_YAW_RATE_I](#RO_YAW_RATE_I) [-]: Integral gain of the closed loop yaw rate controller.
@@ -1,4 +1,4 @@
# Speed Tuning
# Velocity Tuning
:::warning
The [attitude tuning](attitude_tuning.md) must've already been completed before this step!
@@ -6,13 +6,13 @@ The [attitude tuning](attitude_tuning.md) must've already been completed before
::: info
To tune we will be using the manual [Position mode](../flight_modes_rover/manual.md#position-mode).
This mode requires a global position estimate (GPS) and tuning of some parameters that go beyond the speed controller.
If you use a custom external flight mode that controls speed but does not require a global position estimate you can ignore the [manual position mode parameters](#manual-position-mode-parameters).
This mode requires a global position estimate (GPS) and tuning of some parameters that go beyond the velocity controller.
If you use a custom external flight mode that controls velocity but does not require a global position estimate you can ignore the [manual position mode parameters](#manual-position-mode-parameters).
:::
## Speed Parameters
To tune the speed controller configure the following [parameters](../advanced_config/parameters.md) in QGroundControl:
To tune the velocity controller configure the following [parameters](../advanced_config/parameters.md) in QGroundControl:
1. [RO_SPEED_LIM](#RO_SPEED_LIM) [m/s]: This is the maximum speed you want to allow for your rover.
This will define the stick-to-speed mapping for [Position mode](../flight_modes_rover/manual.md#position-mode) and set an upper limit for the speed setpoint.
@@ -27,7 +27,7 @@ To tune the speed controller configure the following [parameters](../advanced_co
1. Set [RO_SPEED_P](#RO_SPEED_P) and [RO_SPEED_I](#RO_SPEED_I) to zero.
This way the speed is only controlled by the feed-forward term, which makes it easier to tune.
2. Put the rover in [Position mode](../flight_modes_rover/manual.md#position-mode) and then move the left stick of your controller up and/or down and hold it at a few different levels for a couple of seconds each.
3. Disarm the rover and from the flight log plot the `adjusted_speed_body_x_setpoint` and the `measured_speed_body_x` from the [RoverSpeedStatus](../msg_docs/RoverSpeedStatus.md) message over each other.
3. Disarm the rover and from the flight log plot the `adjusted_speed_body_x_setpoint` and the `measured_speed_body_x` from the [RoverVelocityStatus](../msg_docs/RoverVelocityStatus.md) message over each other.
4. If the actual speed of the rover is higher than the speed setpoint, increase [RO_MAX_THR_SPEED](#RO_MAX_THR_SPEED).
If it is the other way around decrease the parameter and repeat until you are satisfied with the setpoint tracking.
@@ -86,10 +86,15 @@ These steps are only necessary if you are tuning/want to unlock the manual [Posi
The rover is now ready to drive in [Position mode](../flight_modes_rover/manual.md#position-mode) and the configuration can be continued with [position tuning](position_tuning.md).
## Speed Controller Structure (Info Only)
## Velocity Controller Structure (Info Only)
This section provides additional information for developers and people with experience in control system design.
The velocity vector is defined by the following two values:
1. The absolute speed [$m/s$]
2. The direction (bearing) [$rad$]
The speed controller uses the following structure:
![Rover Speed Controller](../../assets/config/rover/rover_speed_controller.png)
@@ -98,7 +103,7 @@ The feed forward mapping is done by interpolating the speed setpoint from [-[RO_
For ackermann and differential rovers the bearing is aligned with the vehicle yaw. Therefor the bearing is simply sent as a yaw setpoint to the [yaw controller](attitude_tuning.md#attitude-controller-structure-info-only) and the speed setpoint is always defined in body x direction.
For mecanum vehicles, the bearing and yaw are decoupled. The direction is controlled by splitting the speed vector into one speed component in body x direction and one in body y direction.
For mecanum vehicles, the bearing and yaw are decoupled. The direction is controlled by splitting the velocity vector into one speed component in body x direction and one in body y direction.
Both these setpoint are then sent to their own closed loop speed controllers.
## Parameter Overview
-69
View File
@@ -1,69 +0,0 @@
# Developer Guide
This developer guide aims to provide information on the structure and design philosophy of the rover modules to kick-start your development.
The guide is structured into the following sections:
- [Developer Guide](#developer-guide)
- [Module Structure](#module-structure)
- [Control Structure](#control-structure)
- [High Level Structure](#high-level-structure)
- [Code Structure](#code-structure)
- [Testing in Simulation](#testing-in-simulation)
- [Contributing](#contributing)
## Module Structure
The rover modules are structured with a focus on modularity and clearly defined interfaces. This allows a developer to work on a specific area or add a new feature without having to worry about the rest of the codebase.
In the following we will elaborate on this structure on different levels:
### Control Structure
The rover modules use a hierarchical structure in which sepoints can be injected at various level through rover specific uORB messages:
![Control Structure](../../assets/middleware/ros2/px4_ros2_interface_lib/rover_control_structure.svg)
The individual controllers (indicated with green boxes) will subscribe to the setpoint coming from the controller one level above and publish a setpoint to the lower level (setpoints indicated with blue boxes).
The strucutre leads to a cascaded PID controller:
![Rover Position Controller](../../assets/config/rover/rover_position_controller.png)
This cascaded structure is highly modular, we only run the loops that are required to control the highest level setpoint that is provided.
### High Level Structure
Putting the control structure into context of the setpoint generation gives us the full picture of the rover module including its external interfaces:
![High Level Structure](../../assets/airframes/rover/high_level_structure.png)
Important to note, is that the highest setpoint that is provided to the control structure will cause the lower setpoints to be overriden by the controllers.
The highest level setpoint is either provided by PX4 if the vehicle is in a PX4 internal drive mode or injected through the API (DDS Bridge).
### Code Structure
The bulk of the rover related code is located in [src/modules](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules). Each rover type has its own subfolder i.e. [src/modules/rover_ackermann](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/rover_ackermann).
Inside the subfolder you will find the following structure exemplified with the ackermann rover module (some files are excluded here):
| Folder or File Names | Purpose |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| RoverAckermann.hpp/cpp | Entry Point for the rover module. Responsible for configuring the module, generating Setpoints if the vehicle is in a PX4 internal drive mode and calling the individual controllers. |
| module.yaml | Definition of parameters specific to the rover type. |
| AckermannDriveModes | Contains implementations of the PX4 internal drive modes. |
| AckermannPosControl | Position Controller: Turns position setpoints into speed and attitude setpoints. |
| AckermannSpeedControl | Speed Controller: Turns speed sepoints into throttle setpoints. |
| AckermannAttControl | Attitude Controller: Turns attitude setpoints into rate setpoints. |
| AckermannRateControl | Rate Controller: Turns rate setpoints into normalized steering setpoints. |
| AckermannActControl | Actuator Controller: Turns normalized steering/throttle setpoints into actuator setpoints. |
Additionally, there is a [src/lib/rover_control](https://github.com/PX4/PX4-Autopilot/tree/main/src/lib/rover_control) library that includes functions and parameter definitions that are shared among the rover modules.
## Testing in Simulation
PX4 provides synthetic simulation models for [Gazebo](../sim_gazebo_gz/index.md) of all three rover types to test the software and validate changes and new features:
- [Ackermann rover](../sim_gazebo_gz/vehicles.md#ackermann-rover)
- [Differential rover](../sim_gazebo_gz/vehicles.md#differential-rover)
- [Mecanum rover](../sim_gazebo_gz/vehicles.md#mecanum-rover)
![Rover gazebo simulation](../../assets/airframes/rover/rover_simulation.png)
## Contributing
When adding new features it is important to maintain the interfaces of the [High Level Structure](#high-level-structure).
Before opening a PR test your features/improvements in simulation and ideally also on hardware.
In your PR you should include a concise description of your changes and ideally provide logs, screenshots or videos of your code in action.
+15 -8
View File
@@ -5,17 +5,16 @@
:::warning
Support for rover is [experimental](../airframes/index.md#experimental-vehicles).
Maintainer volunteers, [contribution](../contribute/index.md) of new features, new frame configurations, or other improvements would all be very welcome!
Check the [Rover Developer Guide](../frames_rover/developer_guide.md) to kick-start your development!
:::
![Rovers](../../assets/airframes/rover/hiwonder_rovers/hiwonder_rovers.png)
![Rovers](../../assets/airframes/rover/rovers.png)
PX4 provides support for the three most common types of rovers:
| Rover Type | Steering |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [**Ackermann**](#ackermann) | Direction is controlled by pointing wheels in the direction of travel. This kind of steering is used on most commercial vehicles, including cars, trucks etc. |
| [**Differential**](#differential) | Direction is controlled by moving the left- and right-side wheels (or tracks) at different speeds. |
| [**Differential**](#differential) | Direction is controlled by moving the left- and right-side wheels at different speeds. |
| [**Mecanum**](#mecanum) | Direction is controlled by moving each mecanum wheel individually at different speeds and in different directions. |
The supported frames can be seen in [Airframes Reference > Rover](../airframes/airframe_reference.md#rover).
@@ -27,12 +26,12 @@ The supported frames can be seen in [Airframes Reference > Rover](../airframes/a
An Ackermann rover controls its direction by pointing the front wheels in the direction of travel — the [Ackermann steering geometry](https://en.wikipedia.org/wiki/Ackermann_steering_geometry) compensates for the fact that wheels on the inside and outside of the turn move at different rates.
This kind of steering is used on most commercial vehicles, including cars, trucks etc.
![Ackermann rover](../../assets/airframes/rover/hiwonder_rovers/hiwonder_ackermann.png)
::: info
PX4 does not require that the vehicle uses the Ackermann geometry and will work with any front-steering rover.
:::
![Axial Trail Honcho](../../assets/airframes/rover/axial_trail_honcho.png)
## Differential
<Badge type="tip" text="PX4 v1.16" /> <Badge type="warning" text="Experimental" />
@@ -41,7 +40,7 @@ A differential rover's motion is controlled using a differential drive mechanism
Forward motion is achieved by driving both wheels at the same speed in the same direction.
Rotation is achieved by driving the wheels at different speeds in opposite directions, allowing the rover to turn on the spot.
![Tracked Rover](../../assets/airframes/rover/hiwonder_rovers/hiwonder_tracked.png)
![Aion R1](../../assets/airframes/rover/aion_r1/r1_rover_no_bg.png)
::: info
The differential setup also work for rovers with skid or tank steering.
@@ -54,7 +53,7 @@ The differential setup also work for rovers with skid or tank steering.
A Mecanum rover is a type of mobile robot that uses Mecanum wheels to achieve omnidirectional movement. These wheels are unique because they have rollers mounted at a 45-degree angle around their circumference, allowing the rover to move not only forward and backward but also side-to-side and diagonally without needing to rotate first.
Each wheel is driven by its own motor, and by controlling the speed and direction of each motor, the rover can move in any direction or spin in place.
![Mecanum rover](../../assets/airframes/rover/hiwonder_rovers/hiwonder_mecanum.png)
![Mecanum rover](../../assets/airframes/rover/rover_mecanum.png)
## See Also
@@ -62,4 +61,12 @@ Each wheel is driven by its own motor, and by controlling the speed and directio
- [Configuration/Tuning](../config_rover/index.md)
- [Apps & API](../flight_modes_rover/api.md)
- [Complete Vehicles](../complete_vehicles_rover/index.md)
- [Developer Guide](../frames_rover/developer_guide.md)
## Simulation
[Gazebo](../sim_gazebo_gz/index.md) provides simulations for ackermann and differential rovers:
- [Ackermann rover](../sim_gazebo_gz/vehicles.md#ackermann-rover)
- [Differential rover](../sim_gazebo_gz/vehicles.md#differential-rover)
![Rover gazebo simulation](../../assets/airframes/rover/rover_simulation.png)
+1 -5
View File
@@ -58,10 +58,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### Simulation
- Overhaul rover simulation:
- Add synthetic differential rover model: [PX4-gazebo-models#107](https://github.com/PX4/PX4-gazebo-models/pull/107)
- Add synthetic mecanum rover model: [PX4-gazebo-models#113](https://github.com/PX4/PX4-gazebo-models/pull/113)
- Update synthetic ackermann rover model: [PX4-gazebo-models#117](https://github.com/PX4/PX4-gazebo-models/pull/117)
- TBD
### Ethernet
@@ -94,7 +91,6 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
- Removed deprecated rover module ([PX4-Autopilot#25054](https://github.com/PX4/PX4-Autopilot/pull/25054)).
- Add support for [Apps & API](../flight_modes_rover/api.md) ([PX4-Autopilot#25074](https://github.com/PX4/PX4-Autopilot/pull/25074), [PX4-ROS2-Interface-Lib#140](https://github.com/Auterion/px4-ros2-interface-lib/pull/140)).
- Update [rover simulation](../frames_rover/index.md#simulation) ([PX4-Autopilot#25644](https://github.com/PX4/PX4-Autopilot/pull/25644)) (see [Simulation](#simulation) release note for details).
### ROS 2
+26 -28
View File
@@ -50,24 +50,22 @@ This runs both the PX4 SITL instance and the Gazebo client.
The supported vehicles and `make` commands are listed below.
Note that all gazebo make targets have the prefix `gz_`.
| Vehicle | Command | `PX4_SYS_AUTOSTART` |
| ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | ------------------- |
| [Quadrotor (x500)](../sim_gazebo_gz/vehicles.md#x500-quadrotor) | `make px4_sitl gz_x500` | 4001 |
| [X500 Quadrotor with Depth Camera (Front-facing)](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-depth-camera-front-facing) | `make px4_sitl gz_x500_depth` | 4002 |
| [Quadrotor(x500) with Vision Odometry](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-visual-odometry) | `make px4_sitl gz_x500_vision` | 4005 |
| [Quadrotor(x500) with 1D LIDAR (Down-facing)](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-1d-lidar-down-facing) | `make px4_sitl gz_x500_lidar_down` | 4016 |
| [Quadrotor(x500) with 2D LIDAR](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-2d-lidar) | `make px4_sitl gz_x500_lidar_2d` | 4013 |
| [Quadrotor(x500) with 1D LIDAR (Front-facing)](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-1d-lidar-front-facing) | `make px4_sitl gz_x500_lidar_front` | 4017 |
| [Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-gimbal-front-facing) | `make px4_sitl gz_x500_gimbal` | 4019 |
| [VTOL](../sim_gazebo_gz/vehicles.md#standard-vtol) | `make px4_sitl gz_standard_vtol` | 4004 |
| [Plane](../sim_gazebo_gz/vehicles.md#standard-plane) | `make px4_sitl gz_rc_cessna` | 4003 |
| [Advanced Plane](../sim_gazebo_gz/vehicles.md#advanced-plane) | `make px4_sitl gz_advanced_plane` | 4008 |
| [Quad Tailsitter VTOL](../sim_gazebo_gz/vehicles.md#quad-tailsitter-vtol) | `make px4_sitl gz_quadtailsitter` | 4018 |
| [Tiltrotor VTOL](../sim_gazebo_gz/vehicles.md#tiltrotor-vtol) | `make px4_sitl gz_tiltrotor` | 4020 |
| [Differential Rover](../sim_gazebo_gz/vehicles.md#differential-rover) | `make px4_sitl gz_rover_differential` | 50000 |
| [Ackermann Rover](../sim_gazebo_gz/vehicles.md#ackermann-rover) | `make px4_sitl gz_rover_ackermann` | 51000 |
| [Mecanum Rover](../sim_gazebo_gz/vehicles.md#mecanum-rover) | `make px4_sitl gz_rover_mecanum` | 52000 |
| Vehicle | Command | `PX4_SYS_AUTOSTART` |
| ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | ------------------- |
| [Quadrotor (x500)](../sim_gazebo_gz/vehicles.md#x500-quadrotor) | `make px4_sitl gz_x500` | 4001 |
| [X500 Quadrotor with Depth Camera (Front-facing)](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-depth-camera-front-facing) | `make px4_sitl gz_x500_depth` | 4002 |
| [Quadrotor(x500) with Vision Odometry](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-visual-odometry) | `make px4_sitl gz_x500_vision` | 4005 |
| [Quadrotor(x500) with 1D LIDAR (Down-facing)](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-1d-lidar-down-facing) | `make px4_sitl gz_x500_lidar_down` | 4016 |
| [Quadrotor(x500) with 2D LIDAR](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-2d-lidar) | `make px4_sitl gz_x500_lidar_2d` | 4013 |
| [Quadrotor(x500) with 1D LIDAR (Front-facing)](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-1d-lidar-front-facing) | `make px4_sitl gz_x500_lidar_front` | 4017 |
| [Quadrotor(x500) with gimbal (Front-facing) in Gazebo](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-gimbal-front-facing) | `make px4_sitl gz_x500_gimbal` | 4019 |
| [VTOL](../sim_gazebo_gz/vehicles.md#standard-vtol) | `make px4_sitl gz_standard_vtol` | 4004 |
| [Plane](../sim_gazebo_gz/vehicles.md#standard-plane) | `make px4_sitl gz_rc_cessna` | 4003 |
| [Advanced Plane](../sim_gazebo_gz/vehicles.md#advanced-plane) | `make px4_sitl gz_advanced_plane` | 4008 |
| [Differential Rover](../sim_gazebo_gz/vehicles.md#differential-rover) | `make px4_sitl gz_r1_rover` | 4009 |
| [Ackermann Rover](../sim_gazebo_gz/vehicles.md#ackermann-rover) | `make px4_sitl gz_rover_ackermann` | 4012 |
| [Quad Tailsitter VTOL](../sim_gazebo_gz/vehicles.md#quad-tailsitter-vtol) | `make px4_sitl gz_quadtailsitter` | 4018 |
| [Tiltrotor VTOL](../sim_gazebo_gz/vehicles.md#tiltrotor-vtol) | `make px4_sitl gz_tiltrotor` | 4020 |
All [vehicle models](../sim_gazebo_gz/vehicles.md) (and [worlds](#specify-world)) are included as a submodule from the [Gazebo Models Repository](../sim_gazebo_gz/gazebo_models.md) repository.
@@ -166,16 +164,16 @@ PX4_GZ_WORLD=windy make px4_sitl gz_x500
The [supported worlds](../sim_gazebo_gz/worlds.md) are listed below.
| World | Command | Description |
| ----------------- | --------------------------------- | ----------------------------------------------------------- |
| `default` | `make px4_sitl *` | Empty world (a grey plane) |
| `aruco` | `make px4_sitl *_aruco` | Empty world with aruco marker for testing precision landing |
| `baylands` | `make px4_sitl *_baylands` | Baylands world surrounded by water |
| `lawn` | `make px4_sitl *_lawn` | Lawn world for testing rovers |
| `rover` | `make px4_sitl *_rover` | Rover world (optimised/preferred) |
| `walls` | `make px4_sitl *_walls` | Wall world for testing collision prevention |
| `windy` | `make px4_sitl *_windy` | Empty world with wind enabled |
| `moving_platform` | `make px4_sitl *_moving_platform` | World with moving takeoff / landing platform |
| World | Command | Description |
| ----------------- | ---------------------------------- | ----------------------------------------------------------- |
| `default` | `make px4_sitl *` | Empty world (a grey plane) |
| `aruco` | `make px4_sitl *_aruco` | Empty world with aruco marker for testing precision landing |
| `baylands` | `make px4_sitl *_baylands` | Baylands world surrounded by water |
| `lawn` | `make px4_sitl *_lawn` | Lawn world for testing rovers |
| `rover` | `make px4_sitl *_rover` | Rover world (optimised/preferred) |
| `walls` | `make px4_sitl *_walls` | Wall world for testing collision prevention |
| `windy` | `make px4_sitl *_windy` | Empty world with wind enabled |
| `moving_platform` | `make px4_sitl *_moving_platform` | World with moving takeoff / landing platform |
:::warning
Note that if no world is specified, PX4 will use the `default` world.
+1 -11
View File
@@ -185,7 +185,7 @@ make px4_sitl gz_tiltrotor
[Differential Rover](../frames_rover/index.md#differential) uses the [rover world](../sim_gazebo_gz/worlds.md#rover) by default.
```sh
make px4_sitl gz_rover_differential
make px4_sitl gz_r1_rover
```
![Differential Rover in Gazebo](../../assets/simulation/gazebo/vehicles/rover_differential.png)
@@ -199,13 +199,3 @@ make px4_sitl gz_rover_ackermann
```
![Ackermann Rover in Gazebo](../../assets/simulation/gazebo/vehicles/rover_ackermann.png)
### Mecanum Rover
[Mecanum Rover](../frames_rover/index.md#mecanum) uses the [rover world](../sim_gazebo_gz/worlds.md#rover) by default.
```sh
make px4_sitl gz_rover_mecanum
```
![Mecanum Rover in Gazebo](../../assets/simulation/gazebo/vehicles/rover_mecanum.png)
+2
View File
@@ -436,6 +436,7 @@
- [Attitude Tuning](config_rover/attitude_tuning.md)
- [Velocity Tuning](config_rover/velocity_tuning.md)
- [Position Tuning](config_rover/position_tuning.md)
- [Apps & API](flight_modes_rover/api.md)
- [Complete Vehicles](complete_vehicles_rover/index.md)
- [Aion Robotics R1](complete_vehicles_rover/aion_r1.md)
- [Submarines (experimental)](frames_sub/index.md)
@@ -872,6 +873,7 @@
- [PX4 ROS 2 Interface Library](ros2/px4_ros2_interface_lib.md)
- [Control Interface](ros2/px4_ros2_control_interface.md)
- [Navigation Interface](ros2/px4_ros2_navigation_interface.md)
- [Waypoint Missions](ros2/px4_ros2_waypoint_missions.md)
- [ROS 2 Message Translation Node](ros2/px4_ros2_msg_translation_node.md)
- [ROS 1 (Deprecated)](ros/ros1.md)
- [ROS/MAVROS 설치 가이드](ros/mavros_installation.md)
+27 -27
View File
@@ -9,7 +9,7 @@ Failure injection is disabled by default, and can be enabled using the [SYS_FAIL
Failure injection still in development.
At time of writing (PX4 v1.14):
- 시뮬레이션에서만 사용할 수 있습니다(실제 비행에서 실패 주입 모두 지원 예정).
- Support may vary by failure type and between simulatiors and real vehicle.
- It requires support in the simulator.
It is supported in Gazebo Classic
- 많은 실패 유형이 광범위하게 구현되지 않았습니다.
@@ -33,31 +33,31 @@ failure <component> <failure_type> [-i <instance_number>]
- _component_:
- 센서:
- `gyro`: Gyro.
- `accel`: Accelerometer.
- `gyro`: Gyroscope
- `accel`: Accelerometer
- `mag`: Magnetometer
- `baro`: Barometer
- `gps`: GPS
- `gps`: Global navigation satellite system
- `optical_flow`: Optical flow.
- `vio`: Visual inertial odometry.
- `vio`: Visual inertial odometry
- `distance_sensor`: Distance sensor (rangefinder).
- `airspeed`: Airspeed sensor.
- `airspeed`: Airspeed sensor
- 시스템:
- `battery`: Battery.
- `motor`: Motor.
- `servo`: Servo.
- `avoidance`: Avoidance.
- `rc_signal`: RC Signal.
- `mavlink_signal`: MAVLink signal (data telemetry).
- `battery`: Battery
- `motor`: Motor
- `servo`: Servo
- `avoidance`: Avoidance
- `rc_signal`: RC Signal
- `mavlink_signal`: MAVLink data telemetry connection
- _failure_type_:
- `ok`: Publish as normal (Disable failure injection).
- `off`: Stop publishing.
- `stuck`: Report same value every time (_could_ indicate a malfunctioning sensor).
- `garbage`: Publish random noise. 초기화되지 않은 메모리를 읽는 것처럼 보입니다.
- `wrong`: Publish invalid values (that still look reasonable/aren't "garbage").
- `slow`: Publish at a reduced rate.
- `delayed`: Publish valid data with a significant delay.
- `intermittent`: Publish intermittently.
- `ok`: Publish as normal (Disable failure injection)
- `off`: Stop publishing
- `stuck`: Constantly report the same value which _can_ happen on a malfunctioning sensor
- `garbage`: Publish random noise. This looks like reading uninitialized memory
- `wrong`: Publish invalid values that still look reasonable/aren't "garbage"
- `slow`: Publish at a reduced rate
- `delayed`: Publish valid data with a significant delay
- `intermittent`: Publish intermittently
- _instance number_ (optional): Instance number of affected sensor.
0 (기본값) 지정된 유형의 모든 센서를 나타냅니다.
@@ -65,16 +65,16 @@ failure <component> <failure_type> [-i <instance_number>]
To simulate losing RC signal without having to turn off your RC controller:
1. Enable the parameter [SYS_FAILURE_EN](../advanced_config/parameter_reference.md#SYS_FAILURE_EN).
1. Enable the parameter [SYS_FAILURE_EN](../advanced_config/parameter_reference.md#SYS_FAILURE_EN). And specifically to turn off motors also [CA_FAILURE_MODE](../advanced_config/parameter_reference.md#CA_FAILURE_MODE).
2. Enter the following commands on the MAVLink console or SITL _pxh shell_:
```sh
# Fail RC (turn publishing off)
failure rc_signal off
```sh
# Fail RC (turn publishing off)
failure rc_signal off
# Restart RC publishing
failure rc_signal ok
```
# Restart RC publishing
failure rc_signal ok
```
## MAVSDK 실패 플러그인
+87 -41
View File
@@ -62,6 +62,11 @@ bool thrust_and_torque
bool direct_actuator
```
:::warning
The following list shows the `OffboardControlMode` options for copter, fixed-wing, and VTOL.
For rovers see the [rover section](#rover).
:::
The fields are ordered in terms of priority such that `position` takes precedence over `velocity` and later fields, `velocity` takes precedence over `acceleration`, and so on.
The first field that has a non-zero value (from top to bottom) defines what valid estimate is required in order to use offboard mode, and the setpoint message(s) that can be used.
For example, if the `acceleration` field is the first non-zero value, then PX4 requires a valid `velocity estimate`, and the setpoint must be specified using the `TrajectorySetpoint` message.
@@ -90,20 +95,93 @@ Before using offboard mode with ROS 2, please spend a few minutes understanding
- Velocity setpoint (`velocity` different from `NaN` and `position` set to `NaN`). Non-`NaN` values acceleration are used as feedforward terms for the inner loop controllers.
- Acceleration setpoint (`acceleration` different from `NaN` and `position` and `velocity` set to `NaN`)
- All values are interpreted in NED (Nord, East, Down) coordinate system and the units are \[m\], \[m/s\] and \[m/s^2\] for position, velocity and acceleration, respectively.
- All values are interpreted in NED (Nord, East, Down) coordinate system and the units are `[m]`, `[m/s]` and `[m/s^2]` for position, velocity and acceleration, respectively.
- [px4_msgs::msg::VehicleAttitudeSetpoint](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/VehicleAttitudeSetpoint.msg)
- The following input combination is supported:
- quaternion `q_d` + thrust setpoint `thrust_body`.
Non-`NaN` values of `yaw_sp_move_rate` are used as feedforward terms expressed in Earth frame and in \[rad/s\].
Non-`NaN` values of `yaw_sp_move_rate` are used as feedforward terms expressed in Earth frame and in `[rad/s]`.
- The quaternion represents the rotation between the drone body FRD (front, right, down) frame and the NED frame. The thrust is in the drone body FRD frame and expressed in normalized \[-1, 1\] values.
- The quaternion represents the rotation between the drone body FRD (front, right, down) frame and the NED frame.
The thrust is in the drone body FRD frame and expressed in normalized \[-1, 1\] values.
- [px4_msgs::msg::VehicleRatesSetpoint](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/VehicleRatesSetpoint.msg)
- The following input combination is supported:
- `roll`, `pitch`, `yaw` and `thrust_body`.
- All the values are in the drone body FRD frame. The rates are in \[rad/s\] while thrust_body is normalized in \[-1, 1\].
- All the values are in the drone body FRD frame.
The rates are in `[rad/s]` while thrust_body is normalized in `[-1, 1]`.
### 탐사선
Rover modules must set the control mode using `OffboardControlMode` and use the appropriate messages to configure the corresponding setpoints.
The approach is similar to other vehicle types, but the allowed control mode combinations and setpoints are different:
| Category | 사용법 | Setpoints |
| -------------------------------------------------------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| (Recommended) [Rover Setpoints](#rover-setpoints) | General rover control | [RoverPositionSetpoint](../msg_docs/RoverPositionSetpoint.md), [RoverSpeedSetpoint](../msg_docs/RoverSpeedSetpoint.md), [RoverAttitudeSetpoint](../msg_docs/RoverAttitudeSetpoint.md), [RoverRateSetpoint](../msg_docs/RoverRateSetpoint.md), [RoverThrottleSetpoint](../msg_docs/RoverThrottleSetpoint.md), [RoverSteeringSetpoint](../msg_docs/RoverSteeringSetpoint.md) |
| [Actuator Setpoints](#actuator-setpoints) | Direct actuator control | [ActuatorMotors](../msg_docs/ActuatorMotors.md), [ActuatorServos](../msg_docs/ActuatorServos.md) |
| (Deprecated) [Trajectory Setpoint](#deprecated-trajectory-setpoint) | General vehicle control | [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) |
#### Rover Setpoints
The rover modules use a hierarchical structure to propagate setpoints:
![Rover Control Structure](../../assets/middleware/ros2/px4_ros2_interface_lib/rover_control_structure.svg)
The "highest" setpoint that is provided will be used within the PX4 rover modules to generate the setpoints that are below it (overriding them!).
With this hierarchy there are clear rules for providing a valid control input:
- Provide a position setpoint **or**
- One of the setpoints on the "left" (speed **or** throttle) **and** one of the setpoints on the "right" (attitude, rate **or** steering).
All combinations of "left" and "right" setpoints are valid.
The following are all valid setpoint combinations and their respective control flags that must be set through [OffboardControlMode](../msg_docs/OffboardControlMode.md) (set all others to _false_).
Additionally, for some combinations we require certain setpoints to be published with `NAN` values so that the setpoints of interest are not overridden by the rover module (due to the hierarchy above).
&check; are the relevant setpoints we publish, and &cross; are the setpoint that need to be published with `NAN` values.
| Setpoint Combination | Control Flag | [RoverPositionSetpoint](../msg_docs/RoverPositionSetpoint.md) | [RoverSpeedSetpoint](../msg_docs/RoverSpeedSetpoint.md) | [RoverThrottleSetpoint](../msg_docs/RoverThrottleSetpoint.md) | [RoverAttitudeSetpoint](../msg_docs/RoverAttitudeSetpoint.md) | [RoverRateSetpoint](../msg_docs/RoverRateSetpoint.md) | [RoverSteeringSetpoint](../msg_docs/RoverSteeringSetpoint.md) |
| -------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------- |
| Position | position | &check; | | | | | |
| Speed + Attitude | velocity | | &check; | | &check; | | |
| Speed + Rate | velocity | | &check; | | &cross; | &check; | |
| Speed + Steering | velocity | | &check; | | &cross; | &cross; | &check; |
| Throttle + Attitude | attitude | | | &check; | &check; | | |
| Throttle + Rate | body_rate | | | &check; | | &check; | |
| Throttle + Steering | thrust_and_torque | | | &check; | | | &check; |
:::info
If you intend to use the rover setpoints, we recommend using the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) instead since it simplifies the publishing of these setpoints.
:::
#### Actuator Setpoints
Instead of controlling the vehicle using position, speed, rate and other setpoints, you can directly control the motors and actuators using [ActuatorMotors](../msg_docs/ActuatorMotors.md) and [ActuatorServos](../msg_docs/ActuatorServos.md).
In [OffboardControlMode](../msg_docs/OffboardControlMode.md) set `direct_actuator` to _true_ and all other flags to _false_.
:::info
This bypasses the rover modules including any limits on steering rates or accelerations and the inverse kinematics step.
We recommend using [RoverSteeringSetpoint](../msg_docs/RoverSteeringSetpoint.md) and [RoverThrottleSetpoint](../msg_docs/RoverThrottleSetpoint.md) instead for low level control (see [Rover Setpoints](#rover-setpoints)).
:::
#### (Deprecated) Trajectory Setpoint
:::warning
The [Rover Setpoints](#rover-setpoints) are a replacement for the [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) and we highly recommend using those instead as they have a well defined behaviour and offer more flexibility.
:::
The rover modules support the _position_, _velocity_ and _yaw_ fields of the [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md).
However, only one of the fields is active at a time and is defined by the flags of [OffboardControlMode](../msg_docs/OffboardControlMode.md):
| Control Mode Flag | Active Trajectory Setpoint Field |
| ----------------- | -------------------------------- |
| position | position |
| velocity | velocity |
| attitude | yaw |
:::info
Ackermann rovers do not support the yaw setpoint.
:::
### Generic Vehicle
@@ -116,8 +194,10 @@ The following offboard control modes bypass all internal PX4 control loops and s
- [px4_msgs::msg::ActuatorMotors](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/ActuatorMotors.msg) + [px4_msgs::msg::ActuatorServos](https://github.com/PX4/PX4-Autopilot/blob/main/msg/versioned/ActuatorServos.msg)
- You directly control the motor outputs and/or servo outputs.
- Currently works at lower level than then `control_allocator` module. Do not publish these messages when not in offboard mode.
- All the values normalized in \[-1, 1\]. For outputs that do not support negative values, negative entries map to `NaN`.
- Currently works at lower level than then `control_allocator` module.
Do not publish these messages when not in offboard mode.
- All the values normalized in `[-1, 1]`.
For outputs that do not support negative values, negative entries map to `NaN`.
- `NaN` maps to disarmed.
## MAVLink Messages
@@ -207,41 +287,7 @@ The following MAVLink messages and their particular fields and field values are
### 탐사선
- [SET_POSITION_TARGET_LOCAL_NED](https://mavlink.io/en/messages/common.html#SET_POSITION_TARGET_LOCAL_NED)
- The following input combinations are supported (in `type_mask`): <!-- https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/FlightTasks/tasks/Offboard/FlightTaskOffboard.cpp#L166-L170 -->
- Position setpoint (only `x`, `y`, `z`)
- Specify the _type_ of the setpoint in `type_mask`:
::: info
The _setpoint type_ values below are not part of the MAVLink standard for the `type_mask` field.
::
값들은 다음과 같습니다:
- -12288 : Loiter 설정점 (설정점에 매우 가까워지면 기체는 멈춤).
- Velocity setpoint (only `vx`, `vy`, `vz`)
- PX4 supports the coordinate frames (`coordinate_frame` field): [MAV_FRAME_LOCAL_NED](https://mavlink.io/en/messages/common.html#MAV_FRAME_LOCAL_NED) and [MAV_FRAME_BODY_NED](https://mavlink.io/en/messages/common.html#MAV_FRAME_BODY_NED).
- [SET_POSITION_TARGET_GLOBAL_INT](https://mavlink.io/en/messages/common.html#SET_POSITION_TARGET_GLOBAL_INT)
- The following input combinations are supported (in `type_mask`): <!-- https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/FlightTasks/tasks/Offboard/FlightTaskOffboard.cpp#L166-L170 -->
- Position setpoint (only `lat_int`, `lon_int`, `alt`)
- Specify the _type_ of the setpoint in `type_mask` (not part of the MAVLink standard).
값들은 다음과 같습니다:
- 다음 비트가 설정되지 않으면 정상적인 동작입니다.
- -12288 : Loiter 설정점 (설정점에 매우 가까워지면 기체는 멈춤).
- PX4 supports the coordinate frames (`coordinate_frame` field): [MAV_FRAME_GLOBAL](https://mavlink.io/en/messages/common.html#MAV_FRAME_GLOBAL).
- [SET_ATTITUDE_TARGET](https://mavlink.io/en/messages/common.html#SET_ATTITUDE_TARGET)
- 다음 입력 조합이 지원됩니다.
- Attitude/orientation (`SET_ATTITUDE_TARGET.q`) with thrust setpoint (`SET_ATTITUDE_TARGET.thrust`).
::: info
Only the yaw setting is actually used/extracted.
:::
Rover does not support a MAVLink offboard API (ROS2 is supported).
## 오프보드 매개변수
+29
View File
@@ -0,0 +1,29 @@
# Apps & API
The rover modules have been tested and integrated with a subset of the available [Apps & API](../middleware/index.md) methods.
We specifically provide guides for using [ROS 2](../ros2/index.md) to interface a companion computer with PX4 via [uXRCE-DDS](../middleware/uxrce_dds.md).
| Method | 설명 |
| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [PX4 ROS 2 Interface](#px4-ros-2-interface) (Recommended) | Register a custom mode and publish [RoverSetpointTypes](../ros2/px4_ros2_control_interface.md#rover-setpoints). |
| [ROS 2 Offboard Control](#ros-2-offboard-control) | Use the PX4 internal [Offboard Mode](../flight_modes/offboard.md) and publish messages defined in [dds_topics.yaml](../middleware/dds_topics.md). |
## PX4 ROS 2 Interface
We recommend the use of the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) which allows you to register a custom drive mode and exposes [RoverSetpointTypes](../ros2/px4_ros2_control_interface.md#rover-setpoints).
By using these setpoints (instead of the PX4 internal rover setpoints), you are guaranteed to send valid control inputs to your vehicle and the control flags for the setpoints you are using are automatically set for you.
Registering a custom drive mode instead of using [ROS 2 Offboard Control](#ros-2-offboard-control) additionally provides the advantages listed [here](../concept/flight_modes.md#internal-vs-external-modes).
To get familiar with this method, read through the guide for the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) where we also provide an example app for rover.
## ROS 2 Offboard Control
[ROS 2 Offboard Control](../ros2/offboard_control.md) uses the PX4 internal [Offboard Mode](../flight_modes/offboard.md).
While you can subscribe/publish to all topics specified in [dds_topics.yaml](../middleware/dds_topics.md), not all rover modules support all of these topics (see [Supported Setpoints](../flight_modes/offboard.md#rover)).
Unlike the [RoverSetpointTypes](../ros2/px4_ros2_control_interface.md#rover-setpoints) exposed through the [PX4 ROS 2 Interface](#px4-ros-2-interface), there is no guarantee that the published setpoints lead to a valid control input.
In addition, the correct control mode flags must be set through [OffboardControlMode](../msg_docs/OffboardControlMode.md).
This requires a deeper understanding of PX4 and the structure of the rover modules.
For general information on setting up offboard mode read through [Offboard Mode](../flight_modes/offboard.md) and then consult [Supported Setpoints](../flight_modes/offboard.md#rover).
+2 -1
View File
@@ -57,8 +57,9 @@ Each wheel is driven by its own motor, and by controlling the speed and directio
## See Also
- [Drive Modes](../flight_modes_rover/index.md).
- [Drive Modes](../flight_modes_rover/index.md)
- [Configuration/Tuning](../config_rover/index.md)
- [Apps & API](../flight_modes_rover/api.md)
- [Complete Vehicles](../complete_vehicles_rover/index.md)
## 시뮬레이션
+2
View File
@@ -67,6 +67,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### uXRCE-DDS / ROS2
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [Fixed Wing lateral/longitudinal setpoint](../ros2/px4_ros2_control_interface.md#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype) (`FwLateralLongitudinalSetpointType`) and [VTOL transitions](../ros2/px4_ros2_control_interface.md#controlling-a-vtol). ([PX4-Autopilot#24056](https://github.com/PX4/PX4-Autopilot/pull/24056)).
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [ROS-based waypoint missions](../ros2/px4_ros2_waypoint_missions.md).
### MAVLink
@@ -89,6 +90,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### 탐사선
- Removed deprecated rover module ([PX4-Autopilot#25054](https://github.com/PX4/PX4-Autopilot/pull/25054)).
- Add support for [Apps & API](../flight_modes_rover/api.md) ([PX4-Autopilot#25074](https://github.com/PX4/PX4-Autopilot/pull/25074), [PX4-ROS2-Interface-Lib#140](https://github.com/Auterion/px4-ros2-interface-lib/pull/140)).
### ROS 2
+2 -2
View File
@@ -1,6 +1,6 @@
# ROS 2 오프보드 제어 예
The following C++ example shows how to do position control in [offboard mode](../flight_modes/offboard.md) from a ROS 2 node.
The following C++ example shows how to do multicopter position control in [offboard mode](../flight_modes/offboard.md) from a ROS 2 node.
The example starts sending setpoints, enters offboard mode, arms, ascends to 5 metres, and waits.
While simple, it shows the main principles of how to use offboard control and how to send vehicle commands.
@@ -22,7 +22,7 @@ To subscribe to data coming from nodes that publish in a different frame (for ex
## Trying it out
Follow the instructions in [ROS 2 User Guide](../ros2/user_guide.md) to install PX and run the simulator, install ROS 2, and start the XRCE-DDS Agent.
Follow the instructions in [ROS 2 User Guide](../ros2/user_guide.md) to install PX and run the multicopter simulator, install ROS 2, and start the XRCE-DDS Agent.
After that we can follow a similar set of steps to those in [ROS 2 User Guide > Build ROS 2 Workspace](../ros2/user_guide.md#build-ros-2-workspace) to run the example.
@@ -347,6 +347,7 @@ The following sections provide a list of supported setpoint types:
- [MulticopterGotoSetpointType](#go-to-setpoint-multicoptergotosetpointtype): <Badge type="warning" text="MC only" /> Smooth position and (optionally) heading control
- [FwLateralLongitudinalSetpointType](#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype): <Badge type="warning" text="FW only" /> <Badge type="tip" text="main (planned for: PX4 v1.17)" /> Direct control of lateral and longitudinal fixed wing dynamics
- [DirectActuatorsSetpointType](#direct-actuator-control-setpoint-directactuatorssetpointtype): Direct control of motors and flight surface servo setpoints
- [Rover Setpoints](#rover-setpoints): <Badge type="tip" text="main (planned for: PX4 v1.17)" /> Direct access to rover control setpoints (Position, Speed, Attitude, Rate, Throttle and Steering).
:::tip
The other setpoint types are currently experimental, and can be found in: [px4_ros2/control/setpoint_types/experimental](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/px4_ros2_cpp/include/px4_ros2/control/setpoint_types/experimental).
@@ -358,6 +359,8 @@ You can add your own setpoint types by adding a class that inherits from `px4_ro
<Badge type="warning" text="MC only" />
<Badge type="warning" text="Multicopter only" />
:::info
This setpoint type is currently only supported for multicopters.
:::
@@ -551,6 +554,40 @@ For example to control a quadrotor, you need to set the first 4 motors according
If you want to control an actuator that does not control the vehicle's motion, but for example a payload servo, see [below](#controlling-an-independent-actuator-servo).
:::
#### Rover Setpoints
<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />
The rover modules use a hierarchical structure to propagate setpoints:
![Rover Control Structure](../../assets/middleware/ros2/px4_ros2_interface_lib/rover_control_structure.svg)
:::info
The "highest" setpoint that is provided will be used within the PX4 rover modules to generate the setpoints that are below it (Overriding them!).
With this hierarchy there are clear rules for providing a valid control input:
- Provide a position setpoint, **or**
- One of the setpoints on the "left" (speed **or** throttle) **and** one of the setpoints on the "right" (attitude, rate **or** steering). All combinations of "left" and "right" setpoints are valid.
For ease of use we expose these valid combinations as new SetpointTypes.
:::
The RoverSetpointTypes exposed through the control interface are combinations of these setpoints that lead to a valid control input:
| SetpointType | Position | Speed | 스로틀 | Attitude | 주파수 | Steering | Control Flags |
| ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------------ |
| [RoverPosition](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverPositionSetpointType.html#details) | &check; | (&check;) | (&check;) | (&check;) | (&check;) | (&check;) | Position, Velocity, Attitude, Rate, Control Allocation |
| [RoverSpeedAttitude](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverSpeedAttitudeSetpointType.html) | | &check; | (&check;) | &check; | (&check;) | (&check;) | Velocity, Attitude, Rate, Control Allocation |
| [RoverSpeedRate](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverSpeedRateSetpointType.html) | | &check; | (&check;) | | &check; | (&check;) | Velocity, Rate, Control Allocation |
| [RoverSpeedSteering](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverSpeedSteeringSetpointType.html) | | &check; | (&check;) | | | &check; | Velocity, Control Allocation |
| [RoverThrottleAttitude](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverThrottleAttitudeSetpointType.html) | | | &check; | &check; | (&check;) | (&check;) | Attitude, Rate, Control Allocation |
| [RoverThrottleRate](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverThrottleRateSetpointType.html) | | | &check; | | &check; | (&check;) | Rate, Control Allocation |
| [RoverThrottleSteering](https://auterion.github.io/px4-ros2-interface-lib/classpx4__ros2_1_1RoverThrottleSteeringSetpointType.html) | | | &check; | | | &check; | Control Allocation |
&check; are the setpoints we publish, and (&check;) are generated internally by the PX4 rover modules according to the hierarchy above.
An example for a rover specific drive mode using the `RoverSpeedAttitudeSetpointType` is provided [here](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/cpp/modes/rover_velocity).
### Controlling a VTOL
<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />
+2 -5
View File
@@ -9,15 +9,12 @@ At the time of writing, parts of the PX4 ROS 2 Interface Library are experimenta
The [PX4 ROS 2 Interface Library](https://github.com/Auterion/px4-ros2-interface-lib) is a C++ library that simplifies controlling and interacting with PX4 from ROS 2.
The library provides two high-level interfaces for developers:
The library provides three high-level interfaces for developers:
1. The [Control Interface](./px4_ros2_control_interface.md) allows developers to create and dynamically register modes written using ROS 2.
It provides classes for sending different types of setpoints, ranging from high-level navigation tasks all the way down to direct actuator controls.
2. The [Navigation Interface](./px4_ros2_navigation_interface.md) enables sending vehicle position estimates to PX4 from ROS 2 applications, such as a VIO system.
<!--
## Overview
-->
3. [Waypoint Missions](./px4_ros2_waypoint_missions.md) allows waypoint missions to run entirely in ROS 2.
## Installation in a ROS 2 Workspace
+190
View File
@@ -0,0 +1,190 @@
# PX4 ROS 2 Waypoint Missions
<Badge type="tip" text="PX4 v1.16" /> <Badge type="tip" text="Multicopter (only)" /> <Badge type="warning" text="Experimental" />
The [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) provides a high-level interface for executing ROS-based waypoint missions in ROS 2.
The main use-case is for creating missions where a custom behavior is required, such as a pickup action within a mission.
:::warning
ROS 2 missions are not compatible with MAVLink mission definitions, plan files, or ground stations.
They completely bypass the existing PX4 mission mode and waypoint logic, and cannot be planned or displayed within a ground station.
:::
ROS 2 waypoint missions are effectively special PX4 ROS 2 custom modes that are run based on the content of a [JSON mission definition](#mission-definition).
Mission definitions can contain actions that reference existing PX4 modes, such as Takeoff mode or RTL, and can also be extended with arbitrary custom actions written in ROS.
A [mode executor](px4_ros2_control_interface.md#mode-executor) is used to schedule the modes.
Mission definitions can be hard coded in the custom mission mode (either in code or statically loaded from a JSON string), or directly generated within the application.
They can also be dynamically loaded based on modification of a particular JSON file — this allows for building a more generic mission framework with a fixed set of custom actions.
The file can then be written by any other application, for example a HTTP or MAVFTP server.
The current implementation only supports multicopters but is designed to be extendable to any other vehicle type.
## Comparison to PX4/MAVLink Missions
There are some benefits and drawbacks to using ROS-based missions, which are provided in the following paragraphs.
### Benefits
- Allows to extend mission capabilities by registering custom actions.
- More control over how the mission is executed.
A custom trajectory executor can be implemented, which can use any of the existing PX4 setpoint types to track the trajectory.
- Reduced complexity on the flight controller side by running non-safety-critical and non-real-time code on a more high-level companion computer.
- It can be extended to support other trajectory types, like Bezier or Dubin curves.
### Drawbacks
- QGroundControl currently does not display the mission or progress during execution, and cannot upload or download a mission.
Therefore you will need another mechanism to provide a mission, such as from a web server, a custom GCS, or by generating it directly inside the application.
- The current implementation only supports multicopters (it uses the [GotoSetpointType](../ros2/px4_ros2_control_interface.md#go-to-setpoint-gotosetpointtype), which only works for multicopters, and VTOL in MC mode).
It is designed to be extendable to any other vehicle type.
## 개요
This diagram provides a conceptual overview of the main classes and their interactions:
![Waypoint missions overview diagram](../../assets/middleware/ros2/px4_ros2_interface_lib/waypoint_missions.svg)
<!-- Source: https://drive.google.com/file/d/1BXx4fegVE71eq0kDMMuRnhcLnJeDawWe/view?usp=sharing -->
Missions can be defined in [JSON](#mission-definition), either as a file, or directly inside the application.
There is a file change monitor (`MissionFileMonitor`), that can be used to automatically load a mission from a specific file whenever it is created by another application (e.g. upload via MAVFTP or a cloud service).
The **`MissionExecutor`** class contains the state machine to progress the mission index, and is at the core of the implementation:
- Internally, it builds on top of the [Modes and Mode Executors](px4_ros2_control_interface.md#overview) and registers itself through a custom mode and executor with PX4.
- It handles switching in and out of missions: it gets activated when the user switches to the custom mode that represents the mission and the vehicle is armed.
The mode name can be customized (`My Mission` in the example below).
The mission can be paused, which makes the vehicle switch into _Hold mode_.
To resume the mission, the custom mode has to be selected again.
- When an action switches into another mode (for example Takeoff), QGroundControl will display this mode until it is completed.
The mission executor will then automatically continue.
- Custom actions can be registered.
- The mission can be set.
It then checks that all the actions which the mission defines are available and can be run.
- The state can be stored persistently by providing a file name, allowing for battery swapping.
The **`ActionInterface`** is an interface class for custom actions.
They are identified by a name, and any number of these can be registered with the `MissionExecutor`.
A custom action is then run whenever a mission item with matching name is executed, and any extra arguments from the JSON definition are passed as arguments (for example an altitude for a takeoff action).
Actions can call other actions, run any mode (PX4 or external by its ID), run a trajectory, or run any other external action before deciding when to continue the mission.
There is a set of default actions, for example for RTL, Land, etc.
These simply trigger the corresponding PX4 mode.
They can be disabled or replaced with custom implementations.
There are also some special actions (which can be replaced as well):
- `OnFailure`: this is called in case of a failure, e.g. a mode switch failed, a non-existing action is called (by another action) or by an explicit call to `MissionExecutor::abort()`.
The default is to run RTL, with fallback to Land.
- `OnResume`: this is called when resuming a mission (either from the ground or in-air).
It handles a number of cases:
- when called with an argument `action="storeState"`: this can be used to store the current position when the mission is deactivated, so it can be resumed from the same position.
Currently it does not store anything.
- otherwise, when called without a valid mission index or 0, it directly continues.
- otherwise, when called while in-air, it also directly continues.
- otherwise, if landed and if the current mission item is an action that supports resuming from landed, it continues to let the action handle the resuming.
- otherwise, if landed, it finds the takeoff action from the mission, runs it, and then flies to the previous waypoint from the current index to continue the mission.
- `ChangeSettings`: this can be used to change the mission settings, such as the velocity.
The settings are applied to all following items in the mission.
The **`TrajectoryExecutorInterface`** is an interface class to execute segments of a trajectory.
It can use any setpoint that PX4 and the current vehicle supports for tracking the trajectory.
This class is vehicle-type specific.
The current default implementation (`multicopter::WaypointTrajectoryExecutor`) uses a Goto setpoint (and thus is limited to multicopters).
The default can be replaced with a custom implementation.
## 사용법
The following provides a small example.
It defines a custom action and a mission that uses it.
```c++
class CustomAction : public px4_ros2::ActionInterface {
public:
CustomAction(px4_ros2::ModeBase & mode) : _node(mode.node()) { }
std::string name() const override {return "customAction";}
void run(
const std::shared_ptr<px4_ros2::ActionHandler> & handler,
const px4_ros2::ActionArguments & arguments,
const std::function<void()> & on_completed) override
{
RCLCPP_INFO(_node.get_logger(), "Running custom action");
// Do something...
on_completed();
}
private:
rclcpp::Node & _node;
};
class MyMission {
public:
MyMission(const std::shared_ptr<rclcpp::Node> & node) : _node(node)
{
const auto mission = px4_ros2::Mission(nlohmann::json::parse(R"(
{
"version": 1,
"mission": {
"items": [
{
"type": "takeoff"
},
{
"type": "navigation",
"navigationType": "waypoint",
"x": 47.3977419,
"y": 8.5455939,
"z": 500,
"frame": "global"
},
{
"type": "navigation",
"navigationType": "waypoint",
"x": 47.39791657,
"y": 8.54595214,
"z": 500,
"frame": "global"
},
{
"type": "customAction"
},
{
"type": "rtl"
}
]
}
}
)"));
_mission_executor = std::make_unique<px4_ros2::MissionExecutor>("My Mission",
px4_ros2::MissionExecutor::Configuration().addCustomAction<CustomAction>(), *node);
if (!_mission_executor->doRegister()) {
throw std::runtime_error("Failed to register mission executor");
}
_mission_executor->setMission(mission);
_mission_executor->onProgressUpdate([&](int current_index) {
RCLCPP_INFO(_node->get_logger(), "Current mission index: %i", current_index);
});
_mission_executor->onCompleted([&] {
RCLCPP_INFO(_node->get_logger(), "Mission completed callback");
});
}
private:
std::shared_ptr<rclcpp::Node> _node;
std::unique_ptr<px4_ros2::MissionExecutor> _mission_executor;
};
```
A full example with a few custom actions can be found under [github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/cpp/modes/mission/include](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/cpp/modes/mission/include).
## Mission Definition
The mission JSON file can contain mission defaults and a list of mission items, including user-defined types with custom arguments.
Waypoint coordinates currently need to be defined in global frame, and other frame types might be added in future.
The schema can be found under [github.com/Auterion/px4-ros2-interface-lib/blob/main/mission/schema.yaml](https://github.com/Auterion/px4-ros2-interface-lib/blob/main/mission/schema.yaml).
It provides more details and can be used to validate a JSON file.
+35 -33
View File
@@ -20,6 +20,8 @@ See [Simulation](../simulation/index.md) for general information about simulator
Gazebo Harmonic is installed by default on Ubuntu 22.04 as part of the normal [development environment setup](../dev_setup/dev_env_linux_ubuntu.md#simulation-and-nuttx-pixhawk-targets).
Gazebo versions Harmonic, Ionic, and Jetty are supported on Ubuntu 24.04. The latest installed Gazebo release is used by default.
:::info
The PX4 installation scripts are based on the instructions: [Binary Installation on Ubuntu](https://gazebosim.org/docs/harmonic/install_ubuntu/) (gazebosim.org).
:::
@@ -316,33 +318,33 @@ Here are some examples of the different scenarios covered above.
1. **Start simulator + default world + spawn vehicle at default pose**
```sh
PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
2. **Start simulator + default world + spawn vehicle at custom pose (y=2m)**
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_POSE="0,2" PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_POSE="0,2" PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
3. **Start simulator + default world + link to existing vehicle**
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_NAME=x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=4001 PX4_GZ_MODEL_NAME=x500 ./build/px4_sitl_default/bin/px4
```
4. **Start simulator in standalone mode + connect to Gazebo instance running default world**
```sh
PX4_GZ_STANDALONE=1 PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
```sh
PX4_GZ_STANDALONE=1 PX4_SYS_AUTOSTART=4001 PX4_SIM_MODEL=gz_x500 ./build/px4_sitl_default/bin/px4
```
In a separate terminal run:
In a separate terminal run:
```sh
python /path/to/simulation-gazebo
```
```sh
python /path/to/simulation-gazebo
```
## Adding New Worlds and Models
@@ -358,38 +360,38 @@ To add a new model:
2. Define the default parameters for Gazebo in the airframe configuration file (this example is from [x500 quadcopter](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/airframes/4001_gz_x500)):
```ini
PX4_SIMULATOR=${PX4_SIMULATOR:=gz}
PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}
PX4_SIM_MODEL=${PX4_SIM_MODEL:=<your model name>}
```
```ini
PX4_SIMULATOR=${PX4_SIMULATOR:=gz}
PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}
PX4_SIM_MODEL=${PX4_SIM_MODEL:=<your model name>}
```
- `PX4_SIMULATOR=${PX4_SIMULATOR:=gz}` sets the default simulator (Gz) for that specific airframe.
- `PX4_SIMULATOR=${PX4_SIMULATOR:=gz}` sets the default simulator (Gz) for that specific airframe.
- `PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}` sets the [default world](https://github.com/PX4/PX4-gazebo-models/blob/main/worlds/default.sdf) for that specific airframe.
- `PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}` sets the [default world](https://github.com/PX4/PX4-gazebo-models/blob/main/worlds/default.sdf) for that specific airframe.
- Setting the default value of `PX4_SIM_MODEL` lets you start the simulation with just:
- Setting the default value of `PX4_SIM_MODEL` lets you start the simulation with just:
```sh
PX4_SYS_AUTOSTART=<your new airframe id> ./build/px4_sitl_default/bin/px4
```
```sh
PX4_SYS_AUTOSTART=<your new airframe id> ./build/px4_sitl_default/bin/px4
```
3. Add CMake Target for the [airframe](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/airframes/CMakeLists.txt).
- If you plan to use "regular" mode, add your model SDF to `Tools/simulation/gz/models/`.
- If you plan to use _standalone_ mode, add your model SDF to `~/.simulation-gazebo/models/`
- If you plan to use "regular" mode, add your model SDF to `Tools/simulation/gz/models/`.
- If you plan to use _standalone_ mode, add your model SDF to `~/.simulation-gazebo/models/`
You can of course also use both.
You can of course also use both.
### Adding a World
To add a new world:
1. Add your world to the list of worlds found in the [`CMakeLists.txt` here](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/simulation/gz_bridge/CMakeLists.txt).
This is required in order to allow `CMake` to generate correct targets.
This is required in order to allow `CMake` to generate correct targets.
- If you plan to use "normal" mode, add your world sdf to `Tools/simulation/gz/worlds/`.
- If you plan to use _standalone_ mode, add your world SDF to `~/.simulation-gazebo/worlds/`
- If you plan to use "normal" mode, add your world sdf to `Tools/simulation/gz/worlds/`.
- If you plan to use _standalone_ mode, add your world SDF to `~/.simulation-gazebo/worlds/`
:::info
As long as the world file and the model file are in the Gazebo search path (`GZ_SIM_RESOURCE_PATH`) it is not necessary to add them to the PX4 world and model directories.
+23 -22
View File
@@ -1,34 +1,35 @@
# Vehicle odometry data. Fits ROS REP 147 for aerial vehicles
# Vehicle odometry data
#
# Fits ROS REP 147 for aerial vehicles
uint32 MESSAGE_VERSION = 0
uint64 timestamp # time since system start (microseconds)
uint64 timestamp_sample
uint64 timestamp # [us] Time since system start
uint64 timestamp_sample # [us] Timestamp sample
uint8 POSE_FRAME_UNKNOWN = 0
uint8 POSE_FRAME_NED = 1 # NED earth-fixed frame
uint8 POSE_FRAME_FRD = 2 # FRD world-fixed frame, arbitrary heading reference
uint8 pose_frame # Position and orientation frame of reference
uint8 pose_frame # [@enum POSE_FRAME] Position and orientation frame of reference
uint8 POSE_FRAME_UNKNOWN = 0 # Unknown frame
uint8 POSE_FRAME_NED = 1 # North-East-Down (NED) navigation frame. Aligned with True North.
uint8 POSE_FRAME_FRD = 2 # Forward-Right-Down (FRD) frame. Constant arbitrary heading offset from True North. Z is down.
float32[3] position # Position in meters. Frame of reference defined by local_frame. NaN if invalid/unknown
float32[4] q # Quaternion rotation from FRD body frame to reference frame. First value NaN if invalid/unknown
float32[3] position # [m] [@frame local frame] [@invalid NaN If invalid/unknown] Position. Origin is position of GC at startup.
float32[4] q # [-] [@invalid NaN First value if invalid/unknown] Attitude (expressed as a quaternion) relative to pose reference frame at current location. Follows the Hamiltonian convention (w, x, y, z, right-handed, passive rotations from body to world)
uint8 VELOCITY_FRAME_UNKNOWN = 0
uint8 VELOCITY_FRAME_NED = 1 # NED earth-fixed frame
uint8 VELOCITY_FRAME_FRD = 2 # FRD world-fixed frame, arbitrary heading reference
uint8 VELOCITY_FRAME_BODY_FRD = 3 # FRD body-fixed frame
uint8 velocity_frame # Reference frame of the velocity data
uint8 velocity_frame # [@enum VELOCITY_FRAME] Reference frame of the velocity data
uint8 VELOCITY_FRAME_UNKNOWN = 0 # Unknown frame
uint8 VELOCITY_FRAME_NED = 1 # NED navigation frame at current position.
uint8 VELOCITY_FRAME_FRD = 2 # FRD navigation frame at current position. Constant arbitrary heading offset from True North. Z is down.
uint8 VELOCITY_FRAME_BODY_FRD = 3 # FRD body-fixed frame
float32[3] velocity # Velocity in meters/sec. Frame of reference defined by velocity_frame variable. NaN if invalid/unknown
float32[3] velocity # [m/s] [@frame @velocity_frame] [@invalid NaN If invalid/unknown] Velocity.
float32[3] angular_velocity # [rad/s] [@frame @VELOCITY_FRAME_BODY_FRD] [@invalid NaN If invalid/unknown] Angular velocity in body-fixed frame
float32[3] angular_velocity # Angular velocity in body-fixed frame (rad/s). NaN if invalid/unknown
float32[3] position_variance # [m^2] Variance of position error
float32[3] orientation_variance # [rad^2] Variance of orientation/attitude error (expressed in body frame)
float32[3] velocity_variance # [m^2/s^2] Variance of velocity error
float32[3] position_variance
float32[3] orientation_variance
float32[3] velocity_variance
uint8 reset_counter
int8 quality
uint8 reset_counter # [-] Reset counter. Counts reset events on attitude, velocity and position.
int8 quality # [-] [@invalid 0] Quality. Unused.
# TOPICS vehicle_odometry vehicle_mocap_odometry vehicle_visual_odometry
# TOPICS estimator_odometry
@@ -78,7 +78,6 @@
#define LEDC_LSCH0_DUTY_REG (DR_REG_LEDC_BASE + 0x00A8)
#define LEDC_CONF_REG (DR_REG_LEDC_BASE + 0x0190)
#define LEDC_SIG_OUT_EN_LSCH0 1 << 2
#define LEDC_PARA_UP_LSCH0 1 << 4
#define DPORT_LEDC_CLK_EN 1 << 11
@@ -129,7 +128,8 @@ void get_optimal_timer_setup(uint32_t desired_freq)
uint32_t shifted = 1;
timer_rate = desired_freq;
reload = (20480000000 / desired_freq + LEDC_CLKDIV_MAX) / LEDC_CLKDIV_MAX;
uint64_t pwm_clk = 80000000;
reload = (pwm_clk * 256 / desired_freq + LEDC_CLKDIV_MAX) / LEDC_CLKDIV_MAX;
if (reload == 0) {
reload = 1;
@@ -148,7 +148,7 @@ void get_optimal_timer_setup(uint32_t desired_freq)
}
shift = shifted;
prescaler = (20480000000 / reload) / desired_freq;
prescaler = (pwm_clk * 256 / reload) / desired_freq;
}
int up_pwm_servo_set(unsigned channel, uint16_t value)
@@ -157,10 +157,23 @@ int up_pwm_servo_set(unsigned channel, uint16_t value)
uint32_t regval = b16toi(duty * reload + b16HALF);
irqstate_t flags;
flags = px4_enter_critical_section();
SET_CHAN_REG(channel, LEDC_LSCH0_CONF0_REG, 0);
SET_CHAN_REG(channel, LEDC_LSCH0_CONF1_REG, 0);
/* Set pulse phase 0 */
SET_CHAN_REG(channel, LEDC_LSCH0_HPOINT_REG, 0);
SET_CHAN_REG(channel, LEDC_LSCH0_DUTY_REG, regval << 4);
SET_CHAN_BITS(channel, LEDC_LSCH0_CONF0_REG, LEDC_SIG_OUT_EN_LSCH0);
/* Start Duty counter */
SET_CHAN_BITS(channel, LEDC_LSCH0_CONF1_REG, LEDC_DUTY_START_LSCH0);
/* Update duty and phase to hardware */
SET_CHAN_BITS(channel, LEDC_LSCH0_CONF0_REG, LEDC_PARA_UP_LSCH0);
px4_leave_critical_section(flags);
return OK;
@@ -100,9 +100,33 @@ void Ekf::controlRangeHaglFusion(const imuSample &imu_sample)
if (rng_data_ready && _range_sensor.getSampleAddress()) {
updateRangeHagl(aid_src);
const float measurement = math::max(_range_sensor.getDistBottom(), _params.ekf2_min_rng);
const float measurement_variance = getRngVar();
float innovation_variance;
sym::ComputeHaglInnovVar(P, measurement_variance, &innovation_variance);
const float innov_gate = math::max(_params.ekf2_rng_gate, 1.f);
updateAidSourceStatus(aid_src,
_range_sensor.getSampleAddress()->time_us, // sample timestamp
measurement, // observation
measurement_variance, // observation variance
getHagl() - measurement, // innovation
innovation_variance, // innovation variance
innov_gate); // innovation gate
const bool measurement_valid = PX4_ISFINITE(aid_src.observation) && PX4_ISFINITE(aid_src.observation_variance);
// z special case if there is bad vertical acceleration data, then don't reject measurement,
// but limit innovation to prevent spikes that could destabilise the filter
if (_fault_status.flags.bad_acc_vertical && aid_src.innovation_rejected
&& measurement_valid && _range_sensor.isDataHealthy()
) {
const float innov_limit = innov_gate * sqrtf(aid_src.innovation_variance);
aid_src.innovation = math::constrain(aid_src.innovation, -innov_limit, innov_limit);
aid_src.innovation_rejected = false;
}
const bool continuing_conditions_passing = ((_params.ekf2_rng_ctrl == static_cast<int32_t>(RngCtrl::ENABLED))
|| (_params.ekf2_rng_ctrl == static_cast<int32_t>(RngCtrl::CONDITIONAL)))
&& _control_status.flags.tilt_align
@@ -158,11 +182,12 @@ void Ekf::controlRangeHaglFusion(const imuSample &imu_sample)
}
} else {
if ((do_conditional_range_aid || do_range_aid)) {
if (do_conditional_range_aid || do_range_aid) {
ECL_INFO("starting %s height fusion", HGT_SRC_NAME);
_control_status.flags.rng_hgt = true;
if (!_control_status.flags.opt_flow_terrain && aid_src.innovation_rejected) {
ECL_INFO("starting %s height fusion, resetting terrain", HGT_SRC_NAME);
resetTerrainToRng(aid_src);
resetAidSourceStatusZeroInnovation(aid_src);
}
@@ -173,6 +198,13 @@ void Ekf::controlRangeHaglFusion(const imuSample &imu_sample)
if (_control_status.flags.rng_hgt || _control_status.flags.rng_terrain) {
if (continuing_conditions_passing) {
if (do_conditional_range_aid) {
_height_sensor_ref = HeightSensor::RANGE;
} else if (_height_sensor_ref == HeightSensor::RANGE) {
_height_sensor_ref = HeightSensor::UNKNOWN;
}
if (_range_sensor.isDataHealthy()
&& _control_status.flags.rng_kin_consistent
) {
@@ -247,32 +279,6 @@ void Ekf::controlRangeHaglFusion(const imuSample &imu_sample)
}
}
void Ekf::updateRangeHagl(estimator_aid_source1d_s &aid_src)
{
const float measurement = math::max(_range_sensor.getDistBottom(), _params.ekf2_min_rng);
const float measurement_variance = getRngVar();
float innovation_variance;
sym::ComputeHaglInnovVar(P, measurement_variance, &innovation_variance);
const float innov_gate = math::max(_params.ekf2_rng_gate, 1.f);
updateAidSourceStatus(aid_src,
_range_sensor.getSampleAddress()->time_us, // sample timestamp
measurement, // observation
measurement_variance, // observation variance
getHagl() - measurement, // innovation
innovation_variance, // innovation variance
innov_gate); // innovation gate
// z special case if there is bad vertical acceleration data, then don't reject measurement,
// but limit innovation to prevent spikes that could destabilise the filter
if (_fault_status.flags.bad_acc_vertical && aid_src.innovation_rejected) {
const float innov_limit = innov_gate * sqrtf(aid_src.innovation_variance);
aid_src.innovation = math::constrain(aid_src.innovation, -innov_limit, innov_limit);
aid_src.innovation_rejected = false;
}
}
float Ekf::getRngVar() const
{
return fmaxf(
-1
View File
@@ -765,7 +765,6 @@ private:
# if defined(CONFIG_EKF2_RANGE_FINDER)
// update the terrain vertical position estimate using a height above ground measurement from the range finder
bool fuseHaglRng(estimator_aid_source1d_s &aid_src, bool update_height, bool update_terrain);
void updateRangeHagl(estimator_aid_source1d_s &aid_src);
void resetTerrainToRng(estimator_aid_source1d_s &aid_src);
float getRngVar() const;
# endif // CONFIG_EKF2_RANGE_FINDER
+3 -1
View File
@@ -112,8 +112,10 @@ void Ekf::checkHeightSensorRefFallback()
|| ((fallback_list[i] == HeightSensor::GNSS) && _control_status.flags.gps_hgt)
|| ((fallback_list[i] == HeightSensor::RANGE) && _control_status.flags.rng_hgt)
|| ((fallback_list[i] == HeightSensor::EV) && _control_status.flags.ev_hgt)) {
ECL_INFO("fallback to secondary height reference");
_height_sensor_ref = fallback_list[i];
ECL_WARN("fallback to secondary height reference %d", (int)_height_sensor_ref);
break;
}
}