mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-05-26 12:40:04 +08:00
Compare commits
93 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| febbb176bd | |||
| 2b6f09cd0f | |||
| 1386ec2436 | |||
| 66770812bf | |||
| 079e0a8c3f | |||
| 96c02a262f | |||
| 6bc4b03205 | |||
| fa9bfebd17 | |||
| 5e6c36a424 | |||
| aa00bdcd5d | |||
| 7cfea9915b | |||
| 564b517225 | |||
| 30636495c7 | |||
| 9cd8db9680 | |||
| 6b16b8f906 | |||
| 46157114b7 | |||
| 57dd9eb599 | |||
| 844ab9d423 | |||
| 79e60c343a | |||
| d686936979 | |||
| 18527d1bc0 | |||
| c2a4e61c3f | |||
| e441f3d53c | |||
| 160ae487ff | |||
| 256b329aab | |||
| 95119027a9 | |||
| 9e90fd193f | |||
| 832a90e07f | |||
| 2e6fd9dd72 | |||
| 94dc757363 | |||
| 5cfa0d548c | |||
| fa9f8734d0 | |||
| 3d5cb891a6 | |||
| afbaa71bfc | |||
| 873aa89022 | |||
| 1b3c6f7fd2 | |||
| 6604c52c98 | |||
| ef252481a8 | |||
| f35b92a487 | |||
| 3e8f054a1c | |||
| eed966a1c6 | |||
| 5a430f0ba6 | |||
| 4a5c00d0e4 | |||
| 778f80ca59 | |||
| 339e0f9691 | |||
| 7687e6e33f | |||
| 001efc1c0b | |||
| eccfb18b51 | |||
| 1d86ede6c6 | |||
| 84ce7d2fc6 | |||
| a18453d632 | |||
| 3ec684153a | |||
| 2237bfa9a9 | |||
| 7895976a17 | |||
| d7ab21b8d6 | |||
| 59710b15ae | |||
| 0180ad3a63 | |||
| e0663cd6ad | |||
| a6863f0930 | |||
| 34d4eb7b9e | |||
| efc3e64c00 | |||
| 0369abd556 | |||
| 75e4047f2a | |||
| 310cbbedb1 | |||
| 6f81998e27 | |||
| edda54b26b | |||
| e29771cd97 | |||
| ac74a02d7c | |||
| d13692ca46 | |||
| 77d854b045 | |||
| fae563b35e | |||
| 4c130769bd | |||
| 599ea7545d | |||
| 9fd126194b | |||
| 6d15019717 | |||
| 6b2b20bd6e | |||
| e6e42fa043 | |||
| 3b35676afe | |||
| b0d48ce786 | |||
| f014bea723 | |||
| a9e67d4142 | |||
| 46f3e2ea71 | |||
| dd1b435460 | |||
| 9e07813005 | |||
| 80b1f5532b | |||
| 3de41e1847 | |||
| 828b6f5232 | |||
| 2cec05e44a | |||
| f56e6b0bda | |||
| bd17df8c29 | |||
| a19d6e4f6e | |||
| 71e553c67e | |||
| 359d58effd |
@@ -27,7 +27,7 @@ jobs:
|
||||
"failsafe_web",
|
||||
]
|
||||
container:
|
||||
image: px4io/px4-dev:v1.16.0-ondemand
|
||||
image: px4io/px4-dev:v1.16.0-rc1-258-g0369abd556
|
||||
options: --privileged --ulimit core=-1 --security-opt seccomp=unconfined
|
||||
steps:
|
||||
- name: Install Node v20.18.0
|
||||
|
||||
@@ -28,7 +28,7 @@ jobs:
|
||||
name: Analyzing ${{ matrix.target }}
|
||||
runs-on: [runs-on,runner=8cpu-linux-x64,image=ubuntu24-full-x64,"run-id=${{ github.run_id }}",spot=false]
|
||||
container:
|
||||
image: px4io/px4-dev:v1.16.0-ondemand
|
||||
image: px4io/px4-dev:v1.16.0-rc1-258-g0369abd556
|
||||
strategy:
|
||||
matrix:
|
||||
target: [px4_fmu-v5x, px4_fmu-v6x]
|
||||
|
||||
@@ -22,7 +22,7 @@ jobs:
|
||||
name: Checking ${{ matrix.target }}
|
||||
runs-on: [runs-on,runner=8cpu-linux-x64,image=ubuntu24-full-x64,"run-id=${{ github.run_id }}",spot=false]
|
||||
container:
|
||||
image: px4io/px4-dev:v1.16.0-ondemand
|
||||
image: px4io/px4-dev:v1.16.0-rc1-258-g0369abd556
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
|
||||
@@ -31,7 +31,7 @@ jobs:
|
||||
- name: Build PX4 and Run Test [${{ matrix.config }}]
|
||||
uses: addnab/docker-run-action@v3
|
||||
with:
|
||||
image: px4io/px4-dev:v1.16.0-ondemand
|
||||
image: px4io/px4-dev:v1.16.0-rc1-258-g0369abd556
|
||||
options: -v ${{ github.workspace }}:/workspace
|
||||
run: |
|
||||
cd /workspace
|
||||
|
||||
@@ -11,13 +11,11 @@ on:
|
||||
- 'main'
|
||||
paths-ignore:
|
||||
- 'docs/**'
|
||||
- '.github/**'
|
||||
pull_request:
|
||||
branches:
|
||||
- '*'
|
||||
- '**'
|
||||
paths-ignore:
|
||||
- 'docs/**'
|
||||
- '.github/**'
|
||||
|
||||
jobs:
|
||||
build:
|
||||
@@ -33,6 +31,12 @@ jobs:
|
||||
- name: Git Ownership Workaround
|
||||
run: git config --system --add safe.directory '*'
|
||||
|
||||
- name: Update ROS Keys
|
||||
run: |
|
||||
sudo rm /etc/apt/sources.list.d/ros2.list && \
|
||||
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg && \
|
||||
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null
|
||||
|
||||
- name: Install gazebo
|
||||
run: |
|
||||
apt update && apt install -y gazebo11 libgazebo11-dev gstreamer1.0-plugins-bad gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly libgstreamer-plugins-base1.0-dev
|
||||
|
||||
Vendored
+10
@@ -6,6 +6,11 @@ CONFIG:
|
||||
buildType: RelWithDebInfo
|
||||
settings:
|
||||
CONFIG: px4_sitl_default
|
||||
px4_sitl_spacecraft:
|
||||
short: px4_sitl_spacecraft
|
||||
buildType: RelWithDebInfo
|
||||
settings:
|
||||
CONFIG: px4_sitl_spacecraft
|
||||
px4_sitl_nolockstep:
|
||||
short: px4_sitl_nolockstep
|
||||
buildType: RelWithDebInfo
|
||||
@@ -301,6 +306,11 @@ CONFIG:
|
||||
buildType: MinSizeRel
|
||||
settings:
|
||||
CONFIG: holybro_durandal-v1_default
|
||||
holybro_kakuteh7-wing_default:
|
||||
short: holybro_kakuteh7-wing
|
||||
buildType: MinSizeRel
|
||||
settings:
|
||||
CONFIG: holybro_kakuteh7-wing_default
|
||||
holybro_kakuteh7dualimu_default:
|
||||
short: holybro_kakuteh7dualimu
|
||||
buildType: MinSizeRel
|
||||
|
||||
+23
-2
@@ -216,12 +216,33 @@ foreach(board_extra_file ${OPTIONAL_BOARD_EXTRAS})
|
||||
if(CONFIG_SYSTEMCMDS_BL_UPDATE)
|
||||
# generate rc.board_bootloader_upgrade
|
||||
set(BOARD_FIRMWARE_BIN "${PX4_BOARD_VENDOR}_${PX4_BOARD_MODEL}_bootloader.bin")
|
||||
configure_file(${PX4_SOURCE_DIR}/platforms/nuttx/init/rc.board_bootloader_upgrade.in ${romfs_gen_root_dir}/init.d/rc.board_bootloader_upgrade @ONLY)
|
||||
message(STATUS "ROMFS: Adding platforms/nuttx/init/rc.board_bootloader_upgrade -> /etc/init.d/rc.board_bootloader_upgrade")
|
||||
|
||||
# Generate the file using configure_file at configure time to a temporary location
|
||||
set(bootloader_upgrade_tmp ${CMAKE_CURRENT_BINARY_DIR}/rc.board_bootloader_upgrade.tmp)
|
||||
configure_file(${PX4_SOURCE_DIR}/platforms/nuttx/init/rc.board_bootloader_upgrade.in ${bootloader_upgrade_tmp} @ONLY)
|
||||
|
||||
# Then copy it at build time with proper dependencies
|
||||
add_custom_command(
|
||||
OUTPUT
|
||||
${romfs_gen_root_dir}/init.d/rc.board_bootloader_upgrade
|
||||
rc.board_bootloader_upgrade.stamp
|
||||
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${bootloader_upgrade_tmp} ${romfs_gen_root_dir}/init.d/rc.board_bootloader_upgrade
|
||||
COMMAND ${CMAKE_COMMAND} -E touch rc.board_bootloader_upgrade.stamp
|
||||
DEPENDS
|
||||
${bootloader_upgrade_tmp}
|
||||
${PX4_SOURCE_DIR}/platforms/nuttx/init/rc.board_bootloader_upgrade.in
|
||||
romfs_copy.stamp
|
||||
COMMENT "ROMFS: copying rc.board_bootloader_upgrade"
|
||||
)
|
||||
|
||||
list(APPEND extras_dependencies
|
||||
rc.board_bootloader_upgrade.stamp
|
||||
)
|
||||
else()
|
||||
# remove bootloader from extras
|
||||
list(REMOVE_ITEM OPTIONAL_BOARD_EXTRAS ${board_extra_file})
|
||||
endif()
|
||||
|
||||
endif()
|
||||
endforeach()
|
||||
|
||||
|
||||
@@ -15,7 +15,6 @@ param set-default NAV_ACC_RAD 0.5
|
||||
|
||||
# Differential Parameters
|
||||
param set-default RD_WHEEL_TRACK 0.3
|
||||
param set-default RD_MAX_THR_YAW_R 1.5
|
||||
param set-default RD_TRANS_DRV_TRN 0.349066
|
||||
param set-default RD_TRANS_TRN_DRV 0.174533
|
||||
|
||||
@@ -31,14 +30,16 @@ param set-default RO_YAW_RATE_P 0.25
|
||||
param set-default RO_YAW_RATE_LIM 180
|
||||
param set-default RO_YAW_ACCEL_LIM 120
|
||||
param set-default RO_YAW_DECEL_LIM 1000
|
||||
param set-default RO_YAW_RATE_CORR 1.43
|
||||
|
||||
# Rover Attitude Control Parameters
|
||||
param set-default RO_YAW_P 5
|
||||
|
||||
# Rover Position Control Parameters
|
||||
# Rover Velocity Control Parameters
|
||||
param set-default RO_SPEED_LIM 2
|
||||
param set-default RO_SPEED_I 0.01
|
||||
param set-default RO_SPEED_P 0.1
|
||||
param set-defatul RO_SPEED_RED 1
|
||||
|
||||
# Pure Pursuit parameters
|
||||
param set-default PP_LOOKAHD_GAIN 1
|
||||
|
||||
@@ -1,51 +1,68 @@
|
||||
#!/bin/sh
|
||||
# @name Gazebo lawnmower
|
||||
# @name Gazebo - Zero Turn Lawnmower
|
||||
# @type Rover
|
||||
# @class Rover
|
||||
|
||||
. ${R}etc/init.d/rc.rover_differential_defaults
|
||||
|
||||
PX4_SIMULATOR=${PX4_SIMULATOR:=gz}
|
||||
PX4_GZ_WORLD=${PX4_GZ_WORLD:=default}
|
||||
PX4_GZ_WORLD=${PX4_GZ_WORLD:=lawn}
|
||||
PX4_SIM_MODEL=${PX4_SIM_MODEL:=lawnmower}
|
||||
|
||||
param set-default SIM_GZ_EN 1 # Gazebo bridge
|
||||
|
||||
param set-default NAV_ACC_RAD 0.5
|
||||
|
||||
# We can arm and drive in manual mode when it slides and GPS check fails:
|
||||
param set-default COM_ARM_WO_GPS 1
|
||||
|
||||
# Rover parameters
|
||||
# Differential Parameters
|
||||
param set-default RD_WHEEL_TRACK 0.9
|
||||
param set-default RD_YAW_RATE_I 0.1
|
||||
param set-default RD_YAW_RATE_P 5
|
||||
param set-default RD_MAX_ACCEL 1
|
||||
param set-default RD_MAX_JERK 3
|
||||
param set-default RD_MAX_SPEED 8
|
||||
param set-default RD_YAW_P 5
|
||||
param set-default RD_YAW_I 0.1
|
||||
param set-default RD_MAX_YAW_RATE 30
|
||||
param set-default RD_TRANS_DRV_TRN 0.349066
|
||||
param set-default RD_TRANS_TRN_DRV 0.174533
|
||||
|
||||
# Rover Control Parameters
|
||||
param set-default RO_ACCEL_LIM 1.5
|
||||
param set-default RO_DECEL_LIM 5
|
||||
param set-default RO_JERK_LIM 15
|
||||
param set-default RO_MAX_THR_SPEED 2.7
|
||||
|
||||
# Rover Rate Control Parameters
|
||||
param set-default RO_YAW_RATE_I 0.2
|
||||
param set-default RO_YAW_RATE_P 1.0
|
||||
param set-default RO_YAW_RATE_LIM 60
|
||||
param set-default RO_YAW_ACCEL_LIM 50
|
||||
param set-default RO_YAW_DECEL_LIM 1000
|
||||
param set-default RO_YAW_RATE_CORR 1.0
|
||||
|
||||
# Rover Attitude Control Parameters
|
||||
param set-default RO_YAW_P 5
|
||||
|
||||
# Rover Velocity Control Parameters
|
||||
param set-default RO_SPEED_LIM 2.1
|
||||
param set-default RO_SPEED_I 0.01
|
||||
param set-default RO_SPEED_P 0.1
|
||||
param set-defatul RO_SPEED_RED 1.0
|
||||
|
||||
# Pure pursuit parameters
|
||||
param set-default PP_LOOKAHD_MAX 30
|
||||
param set-default PP_LOOKAHD_MIN 2
|
||||
param set-default PP_LOOKAHD_GAIN 1
|
||||
param set-default PP_LOOKAHD_MAX 10
|
||||
param set-default PP_LOOKAHD_MIN 1
|
||||
|
||||
# Actuator mapping - set SITL motors/servos output parameters:
|
||||
|
||||
# "Motors" - motor channels 0 (Right) and 1 (Left) - via Wheels GZ bridge:
|
||||
param set-default SIM_GZ_WH_FUNC1 101 # right wheel
|
||||
#param set-default SIM_GZ_WH_MIN1 0
|
||||
#param set-default SIM_GZ_WH_MAX1 200
|
||||
#param set-default SIM_GZ_WH_DIS1 100
|
||||
#param set-default SIM_GZ_WH_FAIL1 100
|
||||
param set-default SIM_GZ_WH_MIN1 87
|
||||
param set-default SIM_GZ_WH_MAX1 113
|
||||
param set-default SIM_GZ_WH_DIS1 100
|
||||
param set-default SIM_GZ_WH_FAIL1 100
|
||||
|
||||
param set-default SIM_GZ_WH_FUNC2 102 # left wheel
|
||||
#param set-default SIM_GZ_WH_MIN2 0
|
||||
#param set-default SIM_GZ_WH_MAX2 200
|
||||
#param set-default SIM_GZ_WH_DIS2 100
|
||||
#param set-default SIM_GZ_WH_FAIL2 100
|
||||
param set-default SIM_GZ_WH_MIN2 87
|
||||
param set-default SIM_GZ_WH_MAX2 113
|
||||
param set-default SIM_GZ_WH_DIS2 100
|
||||
param set-default SIM_GZ_WH_FAIL2 100
|
||||
|
||||
param set-default SIM_GZ_WH_REV 0 # no need to reverse any wheels
|
||||
|
||||
|
||||
@@ -30,14 +30,16 @@ param set-default RO_MAX_THR_SPEED 3.1
|
||||
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
|
||||
|
||||
# Rover Position Control Parameters
|
||||
# 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
|
||||
|
||||
# Pure Pursuit parameters
|
||||
param set-default PP_LOOKAHD_GAIN 1
|
||||
|
||||
@@ -15,8 +15,6 @@ param set-default NAV_ACC_RAD 0.5
|
||||
|
||||
# Mecanum Parameters
|
||||
param set-default RM_WHEEL_TRACK 0.3
|
||||
param set-default RM_MAX_THR_YAW_R 1.2
|
||||
param set-default RM_MISS_SPD_GAIN 1
|
||||
|
||||
# Rover Control Parameters
|
||||
param set-default RO_ACCEL_LIM 3
|
||||
@@ -30,14 +28,16 @@ param set-default RO_YAW_RATE_P 0.1
|
||||
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
|
||||
|
||||
# Rover Attitude Control Parameters
|
||||
param set-default RO_YAW_P 5
|
||||
|
||||
# Rover Position Control Parameters
|
||||
# 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
|
||||
|
||||
@@ -8,3 +8,6 @@
|
||||
PX4_SIM_MODEL=${PX4_SIM_MODEL:=x500_lidar_down}
|
||||
|
||||
. ${R}etc/init.d-posix/airframes/4001_gz_x500
|
||||
|
||||
param set-default EKF2_RNG_POS_Z -0.177
|
||||
param set-default EKF2_MIN_RNG 0
|
||||
|
||||
@@ -1,155 +0,0 @@
|
||||
#!/bin/sh
|
||||
#
|
||||
# @name 6DoF Spacecraft Model
|
||||
#
|
||||
# @type Freeflyer with 8 thrusters
|
||||
#
|
||||
# @maintainer Pedro Roque <padr@kth.se>
|
||||
#
|
||||
|
||||
. ${R}etc/init.d/rc.sc_defaults
|
||||
|
||||
param set-default CA_AIRFRAME 15
|
||||
param set-default MAV_TYPE 99
|
||||
|
||||
param set-default CA_THRUSTER_CNT 12
|
||||
param set-default CA_R_REV 0
|
||||
|
||||
# param set-default FW_ARSP_MODE 1
|
||||
|
||||
# Auto to be provided by Custom Airframe
|
||||
param set-default CA_METHOD 0
|
||||
|
||||
# disable attitude failure detection
|
||||
param set-default FD_FAIL_P 0
|
||||
param set-default FD_FAIL_R 0
|
||||
|
||||
# Set proper failsafes
|
||||
param set-default COM_ACT_FAIL_ACT 0
|
||||
param set-default COM_LOW_BAT_ACT 0
|
||||
param set-default NAV_DLL_ACT 0
|
||||
param set-default GF_ACTION 1
|
||||
param set-default NAV_RCL_ACT 1
|
||||
param set-default COM_POSCTL_NAVL 2
|
||||
|
||||
# Set thrusters
|
||||
param set-default CA_THRUSTER0_PX -0.50
|
||||
param set-default CA_THRUSTER0_PY 0.50
|
||||
param set-default CA_THRUSTER0_PZ 0.0
|
||||
param set-default CA_THRUSTER0_CT 0.237
|
||||
param set-default CA_THRUSTER0_AX 0.0
|
||||
param set-default CA_THRUSTER0_AY -1.0
|
||||
param set-default CA_THRUSTER0_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER1_PX 0.50
|
||||
param set-default CA_THRUSTER1_PY 0.50
|
||||
param set-default CA_THRUSTER1_PZ 0.0
|
||||
param set-default CA_THRUSTER1_CT 0.237
|
||||
param set-default CA_THRUSTER1_AX 0.0
|
||||
param set-default CA_THRUSTER1_AY -1.0
|
||||
param set-default CA_THRUSTER1_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER2_PX 0.50
|
||||
param set-default CA_THRUSTER2_PY -0.50
|
||||
param set-default CA_THRUSTER2_PZ 0.0
|
||||
param set-default CA_THRUSTER2_CT 0.237
|
||||
param set-default CA_THRUSTER2_AX 0.0
|
||||
param set-default CA_THRUSTER2_AY 1.0
|
||||
param set-default CA_THRUSTER2_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER3_PX -0.50
|
||||
param set-default CA_THRUSTER3_PY -0.50
|
||||
param set-default CA_THRUSTER3_PZ 0.0
|
||||
param set-default CA_THRUSTER3_CT 0.237
|
||||
param set-default CA_THRUSTER3_AX 0.0
|
||||
param set-default CA_THRUSTER3_AY 1.0
|
||||
param set-default CA_THRUSTER3_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER4_PX -0.50
|
||||
param set-default CA_THRUSTER4_PY 0.0
|
||||
param set-default CA_THRUSTER4_PZ -0.50
|
||||
param set-default CA_THRUSTER4_CT 0.237
|
||||
param set-default CA_THRUSTER4_AX 1.0
|
||||
param set-default CA_THRUSTER4_AY 0.0
|
||||
param set-default CA_THRUSTER4_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER5_PX 0.50
|
||||
param set-default CA_THRUSTER5_PY 0.0
|
||||
param set-default CA_THRUSTER5_PZ -0.50
|
||||
param set-default CA_THRUSTER5_CT 0.237
|
||||
param set-default CA_THRUSTER5_AX -1.0
|
||||
param set-default CA_THRUSTER5_AY 0.0
|
||||
param set-default CA_THRUSTER5_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER6_PX 0.50
|
||||
param set-default CA_THRUSTER6_PY 0.0
|
||||
param set-default CA_THRUSTER6_PZ 0.50
|
||||
param set-default CA_THRUSTER6_CT 0.237
|
||||
param set-default CA_THRUSTER6_AX -1.0
|
||||
param set-default CA_THRUSTER6_AY 0.0
|
||||
param set-default CA_THRUSTER6_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER7_PX -0.50
|
||||
param set-default CA_THRUSTER7_PY 0.0
|
||||
param set-default CA_THRUSTER7_PZ 0.50
|
||||
param set-default CA_THRUSTER7_CT 0.237
|
||||
param set-default CA_THRUSTER7_AX 1.0
|
||||
param set-default CA_THRUSTER7_AY 0.0
|
||||
param set-default CA_THRUSTER7_AZ 0.0
|
||||
|
||||
param set-default CA_THRUSTER8_PX 0.0
|
||||
param set-default CA_THRUSTER8_PY -0.50
|
||||
param set-default CA_THRUSTER8_PZ -0.50
|
||||
param set-default CA_THRUSTER8_CT 0.237
|
||||
param set-default CA_THRUSTER8_AX 0.0
|
||||
param set-default CA_THRUSTER8_AY 0.0
|
||||
param set-default CA_THRUSTER8_AZ 1.0
|
||||
|
||||
param set-default CA_THRUSTER9_PX 0.0
|
||||
param set-default CA_THRUSTER9_PY 0.50
|
||||
param set-default CA_THRUSTER9_PZ -0.50
|
||||
param set-default CA_THRUSTER9_CT 0.237
|
||||
param set-default CA_THRUSTER9_AX 0.0
|
||||
param set-default CA_THRUSTER9_AY 0.0
|
||||
param set-default CA_THRUSTER9_AZ 1.0
|
||||
|
||||
param set-default CA_THRUSTER10_PX 0.0
|
||||
param set-default CA_THRUSTER10_PY 0.50
|
||||
param set-default CA_THRUSTER10_PZ 0.50
|
||||
param set-default CA_THRUSTER10_CT 0.237
|
||||
param set-default CA_THRUSTER10_AX 0.0
|
||||
param set-default CA_THRUSTER10_AY 0.0
|
||||
param set-default CA_THRUSTER10_AZ -1.0
|
||||
|
||||
param set-default CA_THRUSTER11_PX 0.0
|
||||
param set-default CA_THRUSTER11_PY -0.50
|
||||
param set-default CA_THRUSTER11_PZ 0.50
|
||||
param set-default CA_THRUSTER11_CT 0.237
|
||||
param set-default CA_THRUSTER11_AX 0.0
|
||||
param set-default CA_THRUSTER11_AY 0.0
|
||||
param set-default CA_THRUSTER11_AZ -1.0
|
||||
|
||||
param set-default PWM_MAIN_FUNC1 101
|
||||
param set-default PWM_MAIN_FUNC2 102
|
||||
param set-default PWM_MAIN_FUNC3 103
|
||||
param set-default PWM_MAIN_FUNC4 104
|
||||
param set-default PWM_MAIN_FUNC5 105
|
||||
param set-default PWM_MAIN_FUNC6 106
|
||||
param set-default PWM_MAIN_FUNC7 107
|
||||
param set-default PWM_MAIN_FUNC8 108
|
||||
param set-default PWM_MAIN_FUNC9 109
|
||||
param set-default PWM_MAIN_FUNC10 110
|
||||
param set-default PWM_MAIN_FUNC11 111
|
||||
param set-default PWM_MAIN_FUNC12 112
|
||||
|
||||
# PWM Simulation
|
||||
param set PWM_SIM_PWM_MAX 10000
|
||||
param set PWM_SIM_PWM_MIN 0
|
||||
|
||||
# Controller Tunings
|
||||
param set-default SC_ROLLRATE_P 0.14
|
||||
param set-default SC_PITCHRATE_P 0.14
|
||||
param set-default SC_ROLLRATE_I 0.3
|
||||
param set-default SC_PITCHRATE_I 0.3
|
||||
param set-default SC_ROLLRATE_D 0.004
|
||||
param set-default SC_PITCHRATE_D 0.004
|
||||
@@ -20,7 +20,7 @@ param set-default COM_ARM_CHK_ESCS 0 # We don't have ESCs
|
||||
param set-default FD_ESCS_EN 0 # We don't have ESCs - but maybe we need this later?
|
||||
|
||||
param set-default CA_AIRFRAME 14
|
||||
param set-default MAV_TYPE 99
|
||||
param set-default MAV_TYPE 45
|
||||
|
||||
param set-default CA_THRUSTER_CNT 8
|
||||
param set-default CA_R_REV 0
|
||||
|
||||
@@ -114,7 +114,6 @@ px4_add_romfs_files(
|
||||
17001_flightgear_tf-g1
|
||||
17002_flightgear_tf-g2
|
||||
|
||||
71001_gazebo-classic_spacecraft_dart
|
||||
71002_gz_spacecraft_2d
|
||||
|
||||
# [22000, 22999] Reserve for custom models
|
||||
|
||||
@@ -26,7 +26,6 @@ param set-default NAV_ACC_RAD 0.5
|
||||
|
||||
# Differential Parameters
|
||||
param set-default RD_WHEEL_TRACK 0.3
|
||||
param set-default RD_MAX_THR_YAW_R 0.7
|
||||
param set-default RD_TRANS_DRV_TRN 0.785398
|
||||
param set-default RD_TRANS_TRN_DRV 0.139626
|
||||
|
||||
@@ -42,14 +41,16 @@ param set-default RO_YAW_RATE_P 0.1
|
||||
param set-default RO_YAW_RATE_LIM 250
|
||||
param set-default RO_YAW_ACCEL_LIM 600
|
||||
param set-default RO_YAW_DECEL_LIM 600
|
||||
param set-default RO_YAW_RATE_CORR 2.7
|
||||
|
||||
# Rover Attitude Control Parameters
|
||||
param set-default RO_YAW_P 2.5
|
||||
|
||||
# Rover Position Control Parameters
|
||||
# Rover Velocity Control Parameters
|
||||
param set-default RO_SPEED_LIM 1.6
|
||||
param set-default RO_SPEED_I 0.01
|
||||
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
|
||||
|
||||
@@ -33,14 +33,16 @@ param set-default RO_MAX_THR_SPEED 2.8
|
||||
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 120
|
||||
param set-default RO_YAW_RATE_CORR 1
|
||||
|
||||
# Rover Attitude Control Parameters
|
||||
param set-default RO_YAW_P 2.5
|
||||
|
||||
# Rover Position Control Parameters
|
||||
# Rover Velocity Control Parameters
|
||||
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 1
|
||||
|
||||
# Pure pursuit parameters
|
||||
param set-default PP_LOOKAHD_GAIN 1
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
. ${R}etc/init.d/rc.sc_defaults
|
||||
|
||||
param set-default CA_AIRFRAME 14
|
||||
param set-default MAV_TYPE 99
|
||||
param set-default MAV_TYPE 45
|
||||
|
||||
param set-default CA_THRUSTER_CNT 8
|
||||
param set-default CA_R_REV 0
|
||||
|
||||
@@ -3,10 +3,10 @@
|
||||
# NOTE: Script variables are declared/initialized/unset in the rcS script.
|
||||
#
|
||||
|
||||
set VEHICLE_TYPE sc
|
||||
set VEHICLE_TYPE spacecraft
|
||||
|
||||
# MAV_TYPE_QUADROTOR 2
|
||||
#param set-default MAV_TYPE 12
|
||||
# MAV_TYPE_SPACECRAFT_ORBITTER
|
||||
param set-default MAV_TYPE 45
|
||||
|
||||
# Set micro-dds-client to use ethernet and IP-address 192.168.0.1
|
||||
param set-default UXRCE_DDS_AG_IP -1062731775
|
||||
|
||||
@@ -68,6 +68,15 @@ then
|
||||
. ${R}etc/init.d/rc.vtol_apps
|
||||
fi
|
||||
|
||||
#
|
||||
# Spapcecraft setup.
|
||||
#
|
||||
if [ $VEHICLE_TYPE = spacecraft ]
|
||||
then
|
||||
# Start standard multicopter apps.
|
||||
. ${R}etc/init.d/rc.sc_apps
|
||||
fi
|
||||
|
||||
#
|
||||
# Airship setup.
|
||||
#
|
||||
|
||||
@@ -280,6 +280,14 @@ else
|
||||
#
|
||||
send_event start
|
||||
|
||||
#
|
||||
# Start the hardfault streamer.
|
||||
#
|
||||
if param compare -s SYS_HF_MAV 1
|
||||
then
|
||||
hardfault_stream start
|
||||
fi
|
||||
|
||||
#
|
||||
# Start the resource load monitor.
|
||||
#
|
||||
|
||||
@@ -35,6 +35,7 @@ if args.filter:
|
||||
for board in args.filter.split(','):
|
||||
board_filter.append(board)
|
||||
|
||||
default_container = 'ghcr.io/px4/px4-dev:v1.16.0-rc1-258-g0369abd556'
|
||||
build_configs = []
|
||||
grouped_targets = {}
|
||||
excluded_boards = ['modalai_voxl2', 'px4_ros2'] # TODO: fix and enable
|
||||
@@ -86,7 +87,7 @@ def process_target(px4board_file, target_name):
|
||||
assert platform, f"PLATFORM not found in {px4board_file}"
|
||||
|
||||
if platform not in excluded_platforms:
|
||||
container = 'ghcr.io/px4/px4-dev:v1.16.0-ondemand'
|
||||
container = default_container
|
||||
if platform == 'posix':
|
||||
group = 'base'
|
||||
if toolchain:
|
||||
@@ -120,7 +121,7 @@ if(verbose):
|
||||
# - Events
|
||||
metadata_targets = ['airframe_metadata', 'parameters_metadata', 'extract_events']
|
||||
grouped_targets['base'] = {}
|
||||
grouped_targets['base']['container'] = 'ghcr.io/px4/px4-dev:v1.16.0-ondemand'
|
||||
grouped_targets['base']['container'] = default_container
|
||||
grouped_targets['base']['manufacturers'] = {}
|
||||
grouped_targets['base']['manufacturers']['px4'] = []
|
||||
grouped_targets['base']['manufacturers']['px4'] += metadata_targets
|
||||
|
||||
+1
-1
@@ -15,7 +15,7 @@ fi
|
||||
|
||||
# otherwise default to nuttx
|
||||
if [ -z ${PX4_DOCKER_REPO+x} ]; then
|
||||
PX4_DOCKER_REPO="px4io/px4-dev:v1.16.0-ondemand"
|
||||
PX4_DOCKER_REPO="px4io/px4-dev:v1.16.0-rc1-258-g0369abd556"
|
||||
fi
|
||||
|
||||
echo "PX4_DOCKER_REPO: $PX4_DOCKER_REPO";
|
||||
|
||||
@@ -27,3 +27,4 @@ six>=1.12.0
|
||||
toml>=0.9
|
||||
sympy>=1.10.1
|
||||
pycryptodome
|
||||
lark
|
||||
|
||||
@@ -62,6 +62,7 @@ CONFIG_MODULES_FW_RATE_CONTROL=y
|
||||
CONFIG_MODULES_GIMBAL=y
|
||||
CONFIG_MODULES_GYRO_CALIBRATION=y
|
||||
CONFIG_MODULES_GYRO_FFT=y
|
||||
CONFIG_MODULES_HARDFAULT_STREAM=y
|
||||
CONFIG_MODULES_LAND_DETECTOR=y
|
||||
CONFIG_MODULES_LANDING_TARGET_ESTIMATOR=y
|
||||
CONFIG_MODULES_LOAD_MON=y
|
||||
|
||||
@@ -43,6 +43,7 @@ CONFIG_FIGURE_OF_EIGHT=y
|
||||
CONFIG_MODULES_FW_RATE_CONTROL=y
|
||||
CONFIG_MODULES_GIMBAL=y
|
||||
CONFIG_MODULES_GYRO_CALIBRATION=y
|
||||
CONFIG_MODULES_HARDFAULT_STREAM=y
|
||||
CONFIG_MODULES_LAND_DETECTOR=y
|
||||
CONFIG_MODULES_LANDING_TARGET_ESTIMATOR=y
|
||||
CONFIG_MODULES_LOAD_MON=y
|
||||
|
||||
@@ -20,6 +20,7 @@ CONFIG_DRIVERS_GPS=y
|
||||
CONFIG_DRIVERS_IMU_BOSCH_BMI088=y
|
||||
CONFIG_DRIVERS_IMU_INVENSENSE_ICM20948=y
|
||||
CONFIG_DRIVERS_IMU_INVENSENSE_IIM42652=y
|
||||
CONFIG_DRIVERS_IMU_INVENSENSE_IIM42653=y
|
||||
CONFIG_COMMON_INS=y
|
||||
CONFIG_COMMON_LIGHT=y
|
||||
CONFIG_COMMON_MAGNETOMETER=y
|
||||
@@ -42,8 +43,8 @@ CONFIG_MODULES_EVENTS=y
|
||||
CONFIG_MODULES_FLIGHT_MODE_MANAGER=y
|
||||
CONFIG_MODULES_FW_ATT_CONTROL=y
|
||||
CONFIG_MODULES_FW_AUTOTUNE_ATTITUDE_CONTROL=y
|
||||
CONFIG_MODULES_FW_MODE_MANAGER=y
|
||||
CONFIG_MODULES_FW_LATERAL_LONGITUDINAL_CONTROL=y
|
||||
CONFIG_MODULES_FW_MODE_MANAGER=y
|
||||
CONFIG_MODULES_FW_RATE_CONTROL=y
|
||||
CONFIG_MODULES_GIMBAL=y
|
||||
CONFIG_MODULES_GYRO_CALIBRATION=y
|
||||
|
||||
@@ -12,10 +12,17 @@ else
|
||||
fi
|
||||
|
||||
iim42652 -s -R 22 start
|
||||
bmi088 -A -R 29 -s start
|
||||
bmi088 -G -R 29 -s start
|
||||
|
||||
ist8310 -I -R 18 start
|
||||
bmi088 -A -R 29 -s start
|
||||
if ! bmi088 -G -R 29 -s start
|
||||
then
|
||||
iim42653 -s -b 2 -R 22 start
|
||||
fi
|
||||
|
||||
if ! ist8310 -I -R 18 start
|
||||
then
|
||||
iis2mdc -I -R 37 start
|
||||
fi
|
||||
|
||||
bmp581 -s start
|
||||
icp201xx -I start
|
||||
|
||||
@@ -42,6 +42,7 @@ constexpr px4_spi_bus_t px4_spi_buses[SPI_BUS_MAX_BUS_ITEMS] = {
|
||||
initSPIBus(SPI::Bus::SPI2, {
|
||||
initSPIDevice(DRV_GYR_DEVTYPE_BMI088, SPI::CS{GPIO::PortG, GPIO::Pin2}, SPI::DRDY{GPIO::PortG, GPIO::Pin3}),
|
||||
initSPIDevice(DRV_ACC_DEVTYPE_BMI088, SPI::CS{GPIO::PortH, GPIO::Pin5}, SPI::DRDY{GPIO::PortA, GPIO::Pin10}),
|
||||
initSPIDevice(DRV_IMU_DEVTYPE_IIM42653, SPI::CS{GPIO::PortD, GPIO::Pin12}, SPI::DRDY{GPIO::PortA, GPIO::Pin10}),
|
||||
}, {GPIO::PortI, GPIO::Pin11}),
|
||||
// initSPIBus(SPI::Bus::SPI3,{
|
||||
// // no devices
|
||||
|
||||
@@ -5,6 +5,7 @@ CONFIG_BOARD_SERIAL_GPS2="/dev/ttyS1"
|
||||
CONFIG_BOARD_SERIAL_TEL1="/dev/ttyS2"
|
||||
CONFIG_BOARD_SERIAL_TEL2="/dev/ttyS3"
|
||||
CONFIG_BOARD_SERIAL_TEL3="/dev/ttyS5"
|
||||
CONFIG_BOARD_SERIAL_RC="/dev/ttyS4"
|
||||
CONFIG_DRIVERS_ADC_BOARD_ADC=y
|
||||
CONFIG_DRIVERS_BAROMETER_BMP280=y
|
||||
CONFIG_DRIVERS_BAROMETER_GOERTEK_SPA06=y
|
||||
|
||||
Binary file not shown.
@@ -74,7 +74,7 @@
|
||||
#define BOARD_TYPE 1105
|
||||
#define BOARD_FLASH_SECTORS (14)
|
||||
#define BOARD_FLASH_SIZE (16 * 128 * 1024)
|
||||
#define APP_RESERVATION_SIZE (1 * 128 * 1024)
|
||||
#define APP_RESERVATION_SIZE (2 * 128 * 1024)
|
||||
|
||||
#define OSC_FREQ 16
|
||||
|
||||
|
||||
@@ -64,6 +64,7 @@ CONFIG_MODULES_FW_LATERAL_LONGITUDINAL_CONTROL=y
|
||||
CONFIG_MODULES_FW_RATE_CONTROL=y
|
||||
CONFIG_MODULES_GIMBAL=y
|
||||
CONFIG_MODULES_GYRO_CALIBRATION=y
|
||||
CONFIG_MODULES_HARDFAULT_STREAM=y
|
||||
CONFIG_MODULES_LAND_DETECTOR=y
|
||||
CONFIG_MODULES_LANDING_TARGET_ESTIMATOR=y
|
||||
CONFIG_MODULES_LOAD_MON=y
|
||||
|
||||
@@ -62,6 +62,7 @@ CONFIG_MODULES_FW_LATERAL_LONGITUDINAL_CONTROL=y
|
||||
CONFIG_MODULES_FW_RATE_CONTROL=y
|
||||
CONFIG_MODULES_GIMBAL=y
|
||||
CONFIG_MODULES_GYRO_CALIBRATION=y
|
||||
CONFIG_MODULES_HARDFAULT_STREAM=y
|
||||
CONFIG_MODULES_LAND_DETECTOR=y
|
||||
CONFIG_MODULES_LANDING_TARGET_ESTIMATOR=y
|
||||
CONFIG_MODULES_LOAD_MON=y
|
||||
|
||||
@@ -63,6 +63,7 @@ CONFIG_MODULES_FW_RATE_CONTROL=y
|
||||
CONFIG_MODULES_GIMBAL=y
|
||||
CONFIG_MODULES_GYRO_CALIBRATION=y
|
||||
CONFIG_MODULES_GYRO_FFT=y
|
||||
CONFIG_MODULES_HARDFAULT_STREAM=y
|
||||
CONFIG_MODULES_LAND_DETECTOR=y
|
||||
CONFIG_MODULES_LANDING_TARGET_ESTIMATOR=y
|
||||
CONFIG_MODULES_LOAD_MON=y
|
||||
|
||||
@@ -9,11 +9,45 @@ This topic explains how to build the PX4 bootloader, and several methods for fla
|
||||
|
||||
::: info
|
||||
|
||||
- Most boards will need to use the [Debug Probe](#debug-probe-bootloader-update) to update the bootloader.
|
||||
- You can use [QGC Bootloader Update](#qgc-bootloader-update-sys-bl-update) with firmware that includes the [`bl-update` module](../modules/modules_command.md#bl-update).
|
||||
This is the easiest way to update the bootloader, provided the board is able to load firmware.
|
||||
- You can also use the [Debug Probe](#debug-probe-bootloader-update) to update the bootloader.
|
||||
This is useful for updating/fixing the bootloader when the board is bricked.
|
||||
- On [FMUv6X-RT](../flight_controller/pixhawk6x-rt.md) you can [install bootloader/unbrick boards via USB](bootloader_update_v6xrt.md).
|
||||
This is useful if you don't have a debug probe.
|
||||
- On FMUv2 and some custom firmware (only) you can use [QGC Bootloader Update](#qgc-bootloader-update).
|
||||
:::
|
||||
|
||||
:::
|
||||
|
||||
## QGC Bootloader Update (`SYS_BL_UPDATE`)
|
||||
|
||||
The easiest way to update the bootloader is to first use _QGroundControl_ to install firmware that contains the desired/latest bootloader.
|
||||
You can then initiate bootloader update on next restart by setting the parameter: [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE).
|
||||
|
||||
This approach can be used if the [`bl-update` module](../modules/modules_command.md#bl-update) is present in the firmware.
|
||||
The easiest way to check this is just to see if the [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE) parameter is [found in QGroundControl](../advanced_config/parameters.md#finding-a-parameter).
|
||||
|
||||
:::warning
|
||||
Boards that include the module will have the line `CONFIG_SYSTEMCMDS_BL_UPDATE=y` in their `default.px4board` file (for examples [see this search](https://github.com/search?q=repo%3APX4%2FPX4-Autopilot+path%3A**%2Fdefault.px4board+CONFIG_SYSTEMCMDS_BL_UPDATE%3Dy&type=code)).
|
||||
You can enable this key in your own custom firmware if needed.
|
||||
:::
|
||||
|
||||
The steps are:
|
||||
|
||||
1. Insert an SD card (enables boot logging to debug any problems).
|
||||
1. [Update the Firmware](../config/firmware.md#custom) with an image containing the new/desired bootloader.
|
||||
|
||||
::: info
|
||||
The updated bootloader might be included the default firmware for your board or supplied in custom firmware.
|
||||
:::
|
||||
|
||||
1. Wait for the vehicle to reboot.
|
||||
1. [Find and enable](../advanced_config/parameters.md) the parameter [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE).
|
||||
1. Reboot (disconnect/reconnect the board).
|
||||
The bootloader update will only take a few seconds.
|
||||
|
||||
Generally at this point you may then want to [update the firmware](../config/firmware.md) again using the correct/newly installed bootloader.
|
||||
|
||||
An specific example of this process for updating the [FMUv2 bootloader](#fmuv2-bootloader-update) is given below.
|
||||
|
||||
## Building the PX4 Bootloader
|
||||
|
||||
@@ -49,11 +83,9 @@ The instructions in the repo README explain how to use it.
|
||||
The following steps explain how you can "manually" update the bootloader using a [compatible Debug Probe](../debug/swd_debug.md#debug-probes-for-px4-hardware):
|
||||
|
||||
1. Get a binary containing the bootloader (either from dev team or [build it yourself](#building-the-px4-bootloader)).
|
||||
|
||||
1. Get a [Debug Probe](../debug/swd_debug.md#debug-probes-for-px4-hardware).
|
||||
2. Get a [Debug Probe](../debug/swd_debug.md#debug-probes-for-px4-hardware).
|
||||
Connect the probe your PC via USB and setup the `gdbserver`.
|
||||
|
||||
1. Go into the directory containing the binary and run the command for your target bootloader in the terminal:
|
||||
3. Go into the directory containing the binary and run the command for your target bootloader in the terminal:
|
||||
|
||||
- FMUv6X
|
||||
|
||||
@@ -78,7 +110,7 @@ The following steps explain how you can "manually" update the bootloader using a
|
||||
Bootloaders from [PX4/PX4-Bootloader](https://github.com/PX4/PX4-Bootloader) are named with the pattern `*_bl.elf`.
|
||||
:::
|
||||
|
||||
1. The _gdb terminal_ appears and it should display the following output:
|
||||
4. The _gdb terminal_ appears and it should display the following output:
|
||||
|
||||
```sh
|
||||
GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
|
||||
@@ -98,28 +130,27 @@ The following steps explain how you can "manually" update the bootloader using a
|
||||
Reading symbols from px4fmuv5_bl.elf...done.
|
||||
```
|
||||
|
||||
1. Find your `<dronecode-probe-id>` by running an `ls` command in the **/dev/serial/by-id** directory.
|
||||
|
||||
1. Now connect to the debug probe with the following command:
|
||||
5. Find your `<dronecode-probe-id>` by running an `ls` command in the **/dev/serial/by-id** directory.
|
||||
6. Now connect to the debug probe with the following command:
|
||||
|
||||
```sh
|
||||
tar ext /dev/serial/by-id/<dronecode-probe-id>
|
||||
```
|
||||
|
||||
1. Power on the Pixhawk with another USB cable and connect the probe to the `FMU-DEBUG` port.
|
||||
7. Power on the Pixhawk with another USB cable and connect the probe to the `FMU-DEBUG` port.
|
||||
|
||||
::: info
|
||||
If using a Dronecode probe you may need to remove the case in order to connect to the `FMU-DEBUG` port (e.g. on Pixhawk 4 you would do this using a T6 Torx screwdriver).
|
||||
:::
|
||||
|
||||
1. Use the following command to scan for the Pixhawk`s SWD and connect to it:
|
||||
8. Use the following command to scan for the Pixhawk`s SWD and connect to it:
|
||||
|
||||
```sh
|
||||
(gdb) mon swdp_scan
|
||||
(gdb) attach 1
|
||||
```
|
||||
|
||||
1. Load the binary into the Pixhawk:
|
||||
9. Load the binary into the Pixhawk:
|
||||
|
||||
```sh
|
||||
(gdb) load
|
||||
@@ -127,38 +158,10 @@ The following steps explain how you can "manually" update the bootloader using a
|
||||
|
||||
After the bootloader has updated you can [Load PX4 Firmware](../config/firmware.md) using _QGroundControl_.
|
||||
|
||||
## QGC Bootloader Update
|
||||
|
||||
The easiest approach is to first use _QGroundControl_ to install firmware that contains the desired/latest bootloader.
|
||||
You can then initiate bootloader update on next restart by setting the parameter: [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE).
|
||||
|
||||
This approach can only be used if [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE) is present in firmware.
|
||||
|
||||
:::warning
|
||||
Currently only FMUv2 and some custom firmware includes the desired bootloader.
|
||||
:::
|
||||
|
||||
The steps are:
|
||||
|
||||
1. Insert an SD card (enables boot logging to debug any problems).
|
||||
1. [Update the Firmware](../config/firmware.md#custom) with an image containing the new/desired bootloader.
|
||||
|
||||
::: info
|
||||
The updated bootloader might be supplied in custom firmware (i.e. from the dev team), or it or may be included in the latest main branch.
|
||||
:::
|
||||
|
||||
1. Wait for the vehicle to reboot.
|
||||
1. [Find and enable](../advanced_config/parameters.md) the parameter [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE).
|
||||
1. Reboot (disconnect/reconnect the board).
|
||||
The bootloader update will only take a few seconds.
|
||||
|
||||
Generally at this point you may then want to [update the firmware](../config/firmware.md) again using the correct/newly installed bootloader.
|
||||
|
||||
An specific example of this process for updating the FMUv2 bootloader is given below.
|
||||
|
||||
### FMUv2 Bootloader Update
|
||||
## FMUv2 Bootloader Update
|
||||
|
||||
If _QGroundControl_ installs the FMUv2 target (see console during installation), and you have a newer board, you may need to update the bootloader in order to access all the memory on your flight controller.
|
||||
This example explains how you can use [QGC Bootloader Update](qgc-bootloader-update-sys-bl-update) to update the bootloader.
|
||||
|
||||
::: info
|
||||
Early FMUv2 [Pixhawk-series](../flight_controller/pixhawk_series.md#fmu_versions) flight controllers had a [hardware issue](../flight_controller/silicon_errata.md#fmuv2-pixhawk-silicon-errata) that restricted them to using 1MB of flash memory.
|
||||
@@ -168,17 +171,17 @@ The problem is fixed on newer boards, but you may need to update the factory-pro
|
||||
To update the bootloader:
|
||||
|
||||
1. Insert an SD card (enables boot logging to debug any problems).
|
||||
1. [Update the Firmware](../config/firmware.md) to PX4 _master_ version (when updating the firmware, check **Advanced settings** and then select **Developer Build (master)** from the dropdown list).
|
||||
2. [Update the Firmware](../config/firmware.md) to PX4 _master_ version (when updating the firmware, check **Advanced settings** and then select **Developer Build (master)** from the dropdown list).
|
||||
_QGroundControl_ will automatically detect that the hardware supports FMUv2 and install the appropriate Firmware.
|
||||
|
||||

|
||||
|
||||
Wait for the vehicle to reboot.
|
||||
|
||||
1. [Find and enable](../advanced_config/parameters.md) the parameter [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE).
|
||||
1. Reboot (disconnect/reconnect the board).
|
||||
3. [Find and enable](../advanced_config/parameters.md) the parameter [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE).
|
||||
4. Reboot (disconnect/reconnect the board).
|
||||
The bootloader update will only take a few seconds.
|
||||
1. Then [Update the Firmware](../config/firmware.md) again.
|
||||
5. Then [Update the Firmware](../config/firmware.md) again.
|
||||
This time _QGroundControl_ should autodetect the hardware as FMUv3 and update the Firmware appropriately.
|
||||
|
||||

|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
_Collision Prevention_ may be used to automatically slow and stop a vehicle before it can crash into an obstacle.
|
||||
It can be enabled for multicopter vehicles when using acceleration-based [Position mode](../flight_modes_mc/position.md) (or VTOL vehicles in MC mode).
|
||||
|
||||
It can be enabled for multicopter vehicles in [Position mode](../flight_modes_mc/position.md), and can use sensor data from an offboard companion computer, offboard rangefinders over MAVLink, a rangefinder attached to the flight controller, or any combination of the above.
|
||||
It can be enabled for multicopter vehicles in [Position mode](../flight_modes_mc/position.md) (with [MPC_POS_MODE](#MPC_POS_MODE) set to `Acceleration based`), and can use sensor data from an offboard companion computer, offboard rangefinders over MAVLink, a rangefinder attached to the flight controller, or any combination of the above.
|
||||
|
||||
Collision prevention may restrict vehicle maximum speed if the sensor range isn't large enough!
|
||||
It also prevents motion in directions where no sensor data is available (i.e. if you have no rear-sensor data, you will not be able to fly backwards).
|
||||
@@ -26,15 +26,14 @@ Users are notified through _QGroundControl_ while _Collision Prevention_ is acti
|
||||
|
||||
PX4 software setup is covered in the next section.
|
||||
If you are using a distance sensor attached to your flight controller for collision prevention, it will need to be attached and configured as described in [PX4 Distance Sensor](#rangefinder).
|
||||
If you are using a companion computer to provide obstacle information see [companion setup](#companion
|
||||
If you are using a companion computer to provide obstacle information see [companion setup](#companion) below.
|
||||
|
||||
## Supported Rangefinders {#rangefinder}
|
||||
## Supported Rangefinders {#rangefinder}
|
||||
|
||||
### Lanbao PSK-CM8JL65-CC5 [Discontinued]
|
||||
|
||||
At time of writing PX4 allows you to use the [Lanbao PSK-CM8JL65-CC5](../sensor/cm8jl65_ir_distance_sensor.md) IR distance sensor for collision prevention “out of the box”, with minimal additional configuration:
|
||||
|
||||
|
||||
- First [attach and configure the sensor](../sensor/cm8jl65_ir_distance_sensor.md), and enable collision prevention (as described above, using [CP_DIST](#CP_DIST)).
|
||||
- Set the sensor orientation using [SENS_CM8JL65_R_0](../advanced_config/parameter_reference.md#SENS_CM8JL65_R_0).
|
||||
|
||||
@@ -51,7 +50,6 @@ Other sensors may be enabled, but this requires modification of driver code to s
|
||||
This should be done by mimicking the `SENS_CM8JL65_R_0` parameter (though you might also hard-code the orientation in the sensor _module.yaml_ file to something like `sf0x start -d ${SERIAL_DEV} -R 25` - where 25 is equivalent to `ROTATION_DOWNWARD_FACING`).
|
||||
- Modify the driver to set the _field of view_ in the distance sensor UORB topic (`distance_sensor_s.h_fov`).
|
||||
|
||||
|
||||
## PX4 (Software) Setup
|
||||
|
||||
Configure collision prevention by [setting the following parameters](../advanced_config/parameters.md) in _QGroundControl_:
|
||||
@@ -62,7 +60,7 @@ Configure collision prevention by [setting the following parameters](../advanced
|
||||
| <a id="CP_DELAY"></a>[CP_DELAY](../advanced_config/parameter_reference.md#CP_DELAY) | Set the sensor and velocity setpoint tracking delay. See [Delay Tuning](#delay_tuning) below. |
|
||||
| <a id="CP_GUIDE_ANG"></a>[CP_GUIDE_ANG](../advanced_config/parameter_reference.md#CP_GUIDE_ANG) | Set the angle (to both sides of the commanded direction) within which the vehicle may deviate if it finds fewer obstacles in that direction. See [Guidance Tuning](#angle_change_tuning) below. |
|
||||
| <a id="CP_GO_NO_DATA"></a>[CP_GO_NO_DATA](../advanced_config/parameter_reference.md#CP_GO_NO_DATA) | Set to 1 to allow the vehicle to move in directions where there is no sensor coverage (default is 0/`False`). |
|
||||
| <a id="MPC_POS_MODE"></a>[MPC_POS_MODE](../advanced_config/parameter_reference.md#MPC_POS_MODE) | Set to `Direct velocity` or `Smoothed velocity` to enable Collision Prevention in Position Mode (default is `Acceleration based`). |
|
||||
| <a id="MPC_POS_MODE"></a>[MPC_POS_MODE](../advanced_config/parameter_reference.md#MPC_POS_MODE) | Must be set to `Acceleration based`. |
|
||||
|
||||
## Algorithm Description
|
||||
|
||||
@@ -131,7 +129,6 @@ The guidance feature will never direct the vehicle in a direction without sensor
|
||||
If the vehicle feels stuck with only a single distance sensor pointing forwards, this is probably because the guidance cannot safely adapt the direction due to lack of information.
|
||||
:::
|
||||
|
||||
|
||||
## Algorithm Description
|
||||
|
||||
The data from all sensors are fused into an internal representation of 72 sectors around the vehicle, each containing either the sensor data and information about when it was last observed, or an indication that no data for the sector was available.
|
||||
@@ -212,7 +209,7 @@ The steps are:
|
||||
type: px4_msgs::msg::ObstacleDistance
|
||||
```
|
||||
|
||||
For more information see [DDS Topics YAML](../middleware/uxrce_dds.md#dds-topics-yaml) in [uXRCE-DDS](../middleware/uxrce_dds.md) (PX4-ROS 2/DDS Bridge)_.
|
||||
For more information see [DDS Topics YAML](../middleware/uxrce_dds.md#dds-topics-yaml) in [uXRCE-DDS](../middleware/uxrce_dds.md) (PX4-ROS 2/DDS Bridge)\_.
|
||||
|
||||
3. Open PlotJuggler and navigate to the **Tools > Reactive Script Editor** section.
|
||||
In the **Script Editor** tab, add following scripts in the appropriate sections:
|
||||
|
||||
+14
-224
@@ -1,35 +1,11 @@
|
||||
# uORB Messaging
|
||||
|
||||
The Micro Object Request Broker (uORB) is PX4s low-latency asynchronous `publish()` / `subscribe()` messaging API for inter-thread/inter-process communication.
|
||||
It allows the different modules of the system to communicate effectively, while still being loosely coupled, and hence easily replaced.
|
||||
|
||||
## Introduction
|
||||
|
||||
PX4 modules communicate using uORB _topics_.
|
||||
A topic represents a communication channel for sending _messages_ between a publisher module and one or more subscriber modules.
|
||||
A module that is interested in receiving messages can subscribe to a topic and use it to check for, and read, new messages.
|
||||
A module that wants to send messages to a particular topic (and hence all subscribers) must _advertise_ that it is going to do so, and can then _publish_ messages when it has new data.
|
||||
|
||||
A topic behaves like a queue to which publishers write, and from which subscribers read.
|
||||
By default he queue can only buffer a single message, which may be overwritten if the publisher writes new message data before subscribers can read it.
|
||||
The [queue size may be increased](#uorb-buffer-length-orb-queue-length) in the rare cases when subscribers really need to receive every message.
|
||||
|
||||
A message is a discrete sample of data that can be published/subscribed via a topic.
|
||||
The message fields, the constants that can be used with those fields, and the topic(s) to which the message can be published/subscribed are defined in a uORB message definition file.
|
||||
|
||||
By default a single topic is automatically created for each message definition file, which is created by `underscore_snake_casing` the (CamelCase) message definition file name.
|
||||
For example, topic `battery_status` is automatically created for the `BatteryStatus.msg`.
|
||||
This is generally what you want if the message is always about the same kind of data (batteries in this case) and so all the subscribers will be interested in the same messages.
|
||||
|
||||
Sometimes the same message structure can be used to represent data from different kinds of sources, which will have different sets of interested publishers and subscribers.
|
||||
In this case the topics need to be explicitly declared.
|
||||
For example the [VehicleGlobalPosition.msg](../msg_docs/VehicleGlobalPosition.md) can be used for sending messages about global position from an estimator, GNSS, or an external source: the fields are the same, but the source and subscribers of the data may be different.
|
||||
|
||||
uORB also provides a mechanism to publish multiple independent instances of the same topic.
|
||||
This is useful, for example, if the system has several sensors of the same type.
|
||||
The uORB is an asynchronous `publish()` / `subscribe()` messaging API used for inter-thread/inter-process communication.
|
||||
|
||||
uORB is implemented in the [`uorb` module](../modules/modules_communication.md#uorb).
|
||||
The module is started automatically (with `uorb start`) early in the PX4 boot sequence, as many applications depend on it.
|
||||
It is started automatically (with `uorb start`) early in the PX4 boot sequence, as many applications depend on it.
|
||||
Unit tests can be started with `uorb_tests`.
|
||||
|
||||
This document explains how to add uORB message definitions and their corresponding topic(s), how to use reference a topic in code, and how to view topics as they change in PX4.
|
||||
@@ -66,20 +42,20 @@ In code you refer to the topic using its id, which in this example would be: `OR
|
||||
|
||||
## Message Definitions
|
||||
|
||||
Every message should start with a [message description](#message-description) that outlines its purpose (a comment starts with the `#` symbol and goes to the end of the line).
|
||||
The message definition should start with a descriptive _comment_ that outlines its purpose (a comment starts with the `#` symbol and goes to the end of the line).
|
||||
The message will then define one or more fields, which are defined with a _type_, such as `bool`, `uint8`, and `float32`, followed by a _name_.
|
||||
By convention, each field is followed by a descriptive _comment_, which is any text from the `#` symbol to the end of the line.
|
||||
|
||||
::: info
|
||||
All _versioned_ messages definitions must include the `uint32 MESSAGE_VERSION` field.
|
||||
For more information, refer to the [Message Versioning](#message-versioning) section.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
All message definitions **must** include the `uint64_t timestamp` field, and this should be filled in when publishing the associated topic(s).
|
||||
This field is needed in order for the logger to be able to record UORB topics.
|
||||
:::
|
||||
|
||||
::: info
|
||||
All _versioned_ messages definitions must include the `uint32 MESSAGE_VERSION` field.
|
||||
For more information, refer to the [Message Versioning](#message-versioning) section.
|
||||
:::
|
||||
|
||||
For example the [VelocityLimits](../msg_docs/VelocityLimits.md) message definition shown below has a descriptive comment, followed by a number of fields, which each have a comment.
|
||||
|
||||
```text
|
||||
@@ -98,202 +74,16 @@ By default this message definition will be compiled to a single topic with an id
|
||||
This is the simplest form of a message.
|
||||
See the existing [`msg`](../msg_docs/index.md) files for other examples of how messages are defined.
|
||||
|
||||
#### Message Description
|
||||
|
||||
Every message should start with a [comment](#comments) block that describes the message (one or more of lines that all start with `#`).
|
||||
The first comment line is mandatory and provides the short description.
|
||||
This may be followed by an empty comment line and then a optional long description.
|
||||
|
||||
```text
|
||||
# Short description
|
||||
#
|
||||
# Long(er) description for the message
|
||||
# that can be multiline
|
||||
```
|
||||
|
||||
The short description should provide a succinct explanation for the purpose of the message.
|
||||
Minimally it may just mirror the message name.
|
||||
For example, [`BatteryStatus`](../msg_docs/BatteryStatus.md) has the short description `Battery status`.
|
||||
|
||||
The long description should provide any additional context required to understand what how the message is used.
|
||||
It might explain who are the publishers and who are the expected consumers, such as MAVLink or the logging system.
|
||||
It might also cover whether the message is only used for a particular frame type or mode.
|
||||
|
||||
Both short and long descriptions may be multi-line.
|
||||
The long description may also include empty comment lines (the short description cannot, because the first empty comment delineates the short and long description).
|
||||
A terminating full stop can be omitted from single line comments and from the final line.
|
||||
|
||||
The block ends at the first non-comment line, such as an empty line, field, or constant.
|
||||
Any subsequent comment lines are considered "internal comments".
|
||||
|
||||
### Comments
|
||||
|
||||
Comments are text provided for explanation or documentation purposes.
|
||||
Any text after a `#` character is a comment (with the exception of lines that [start with `# TOPIC`](#multi-topic-message)).
|
||||
|
||||
PX4 uses structured comments for message, field, and constant descriptions.
|
||||
Other comments are internal.
|
||||
|
||||
### Fields
|
||||
|
||||
Messages define one or more fields, which are the variables that are written and read by publishers and subscribers, respectively.
|
||||
|
||||
A typical field might look like this:
|
||||
|
||||
```sh
|
||||
float64 lat # [deg] Latitude (WGS84).
|
||||
```
|
||||
|
||||
Each field has a _type_ followed by a _name_, and should also have a _comment_
|
||||
The format is as shown:
|
||||
|
||||
```sh
|
||||
<type> <name> # [metadata] <description>
|
||||
```
|
||||
|
||||
- `type`:
|
||||
- A primitive data type: `bool`, `char`, `uint8`, `uint32`, `uint64`, `int8`, `int16`, `int32`, `float32` and `float64`.
|
||||
- Another UORB message name, when creating complex types using [nested messages](#nested-messages).
|
||||
- `name`
|
||||
- Any message-unique string.
|
||||
By convention use lower case `underline_snake_case`.
|
||||
|
||||
The comment must all be on the same line as the field, and should consist of optional metadata and a description:
|
||||
|
||||
- `metadata` (Optional)
|
||||
- Information about the field units and allowed values:
|
||||
- `[<unit>]`
|
||||
- The unit of measurement inside square brackets (note, no `@` delineator indicates a unit).
|
||||
For example `[m]` or `[deg]`.
|
||||
Typical units include: `m`, `deg`, `m/s`, `rad`, `rad/s`, and so on.
|
||||
- `[@enum <enum_name>]`
|
||||
- The `enum_name` gives the prefix of constant values in the message that can be assigned to the field.
|
||||
Note that in UORB "enums" are a naming convention: they are not explicitly declared.
|
||||
Multiple enum names indicate a possible error in the field design.
|
||||
- `[@range <lower_value>, <upper_value>]`
|
||||
- The allowed range of the field, specified as a `lower_value` and/or an `upper_value`.
|
||||
Either value can be omitted to indicate an unbounded upper or lower value.
|
||||
For example `[@range 0, 3]`, `[@range 5.3, ]`, `[@range , 3]`.
|
||||
- `[@invalid <value> <description>]`
|
||||
- The `value` to set the field to indicate that the field doesn't contain valid data.
|
||||
The `description` is optional, and might be used to indicate the conditions under which data is invalid.
|
||||
- `description`
|
||||
- A concise description of the purpose of the field and allowed values, and including any important information that can't be inferred from the name!
|
||||
Use a capital first letter, and omit the full stop if the description is a single sentence.
|
||||
Multiple sentences may also omit the final full stop.
|
||||
|
||||
#### Array Fields
|
||||
|
||||
A array field defines multiple variables in an array, where all values have the same type.
|
||||
The number of elements are given using square brackets after the type.
|
||||
Array fields are otherwise defined (and documented) in the same way as other fields.
|
||||
|
||||
For example:
|
||||
|
||||
```sh
|
||||
int32[12] raw_data # ADC channel raw value, accept negative value.
|
||||
```
|
||||
|
||||
#### Mandatory Fields
|
||||
|
||||
All message definitions **must** include following fields:
|
||||
|
||||
- `uint64_t timestamp`
|
||||
- This should be filled in when publishing the associated topic(s).
|
||||
It is needed in order for the logger to be able to record UORB topics.
|
||||
- The comment should be `# [us] Time since system start`.
|
||||
|
||||
### Constants
|
||||
|
||||
Constants specify a mapping between a name and a value.
|
||||
|
||||
These are mainly used to predefine useful values that you might need to use for a particular field, such as a state or flag values.
|
||||
Often these are grouped together as [enums](#enums).
|
||||
There are also a small number of [metadata constants](#metadata-constants) that are used by the build infrastructure.
|
||||
|
||||
For example, here are a number of constants for indicating battery warnings.
|
||||
|
||||
```sh
|
||||
uint8 WARNING_NONE = 0 # No battery low voltage warning active
|
||||
uint8 WARNING_LOW = 1 # Low voltage warning
|
||||
```
|
||||
|
||||
Constants are specified as a field assigned with a value.
|
||||
The field part has a _type_, which must match the type of the field they are to be used with, followed by a _name_.
|
||||
They should also have a _comment_ with a description.
|
||||
By convention they are defined immediately below the field with which they can used.
|
||||
|
||||
The format is as shown:
|
||||
|
||||
```sh
|
||||
<type> <name> = <value> # <description>
|
||||
```
|
||||
|
||||
- `type`:
|
||||
- Must match the `type` of the field with which it is to be used.
|
||||
- `name`
|
||||
- The name of the constant.
|
||||
This must be message-unique and is by convention `ALL_UPPER_CASE_UNDERLINE_SNAKE_CASE`
|
||||
- Constant names that can be used with a field should share the same prefix and should indicate the value's purpose.
|
||||
|
||||
The comment must all be on the same line as the field.
|
||||
Note that this is much like the field description (but there is no metadata):
|
||||
|
||||
- `description`
|
||||
- A terse description of the purpose of the constant.
|
||||
Use a capital first letter, and omit the full stop if the description is a single sentence.
|
||||
Multiple sentences may also omit the final full stop.
|
||||
|
||||
#### Enums
|
||||
|
||||
Enums are groups/sets of enumerated constants that can be used as values for a particular field.
|
||||
|
||||
UORB does not define a formal syntax for enums.
|
||||
Instead we use a prefix naming convention to indicate all the constants that are part of the same enum.
|
||||
The constants in the enum should be declared immediately after the field in which they are used, and for parsing convenience, the prefix is listed in the field using `@enum` metadata.
|
||||
|
||||
For example, here is the definition of the `warning` field and some of the `WARNING` enum values that can be used with it:
|
||||
|
||||
```sh
|
||||
uint8 warning # [@enum WARNING] Current battery warning
|
||||
uint8 WARNING_NONE = 0 # No battery low voltage warning active
|
||||
uint8 WARNING_LOW = 1 # Low voltage warning
|
||||
uint8 WARNING_CRITICAL = 2 # Critical voltage, return / abort immediately
|
||||
...
|
||||
```
|
||||
|
||||
#### Metadata Constants
|
||||
|
||||
A number of constants provide information that is used by the PX4 build system to configure how the message may be used, such as the version and length of the message.
|
||||
If relevant, these should appear near the top of the file, immediately after the [Message Description](#message-description).
|
||||
|
||||
The allowed constants are:
|
||||
|
||||
- `ORB_QUEUE_LENGTH` - Sets the [uORB Buffer Length](#uorb-buffer-length-orb-queue-length), which is used in rare cases where a subscriber needs all values that are set for a field, rather than just the most recent sample.
|
||||
- `MESSAGE_VERSION` - Sets the version number of a versioned message.
|
||||
This is used as part of the infrastructure to maintain compatibility between PX4 and ROS 2 versions compiled against different message definitions.
|
||||
For more information see [Message Versioning](#message-versioning)
|
||||
|
||||
#### Multi-Topic Messages (`# TOPICS`) {#multi-topic-messages}
|
||||
|
||||
By default a single topic is automatically created for each message definition file, which is created by `underscore_snake_casing` the (CamelCase) message definition file name.
|
||||
For example, topic `battery_status` is automatically created for the `BatteryStatus.msg`.
|
||||
This is generally what you want if the message is always about the same kind of data (batteries in this case) and so all the subscribers will be interested in the same messages.
|
||||
### Multi-Topic Messages
|
||||
|
||||
Sometimes it is useful to use the same message definition for multiple topics.
|
||||
In this case the topics need to be explicitly declared.
|
||||
You can do this by adding one or more lines to the end of the message prefixed with `# TOPICS`, followed by space-separated topic ids.
|
||||
|
||||
For example, the [VehicleGlobalPosition.msg](../msg_docs/VehicleGlobalPosition.md) message definition is used to define the topic ids as shown:
|
||||
This can be specified at the end of the message using a line prefixed with `# TOPICS `, followed by space-separated topic ids.
|
||||
For example, the [ActuatorOutputs](../msg_docs/ActuatorOutputs.md) message definition is used to define the topic ids as shown:
|
||||
|
||||
```text
|
||||
# TOPICS vehicle_global_position vehicle_global_position_groundtruth external_ins_global_position
|
||||
# TOPICS estimator_global_position
|
||||
# TOPICS aux_global_position
|
||||
# TOPICS actuator_outputs actuator_outputs_sim actuator_outputs_debug
|
||||
```
|
||||
|
||||
Note that multiple topics are useful in this case because the likely subscribers for the different sources of global position are likely to be different.
|
||||
|
||||
### Nested Messages
|
||||
|
||||
Message definitions can be nested within other messages to create complex data structures.
|
||||
@@ -305,7 +95,7 @@ To nest a message, simply include the nested message type in the parent message
|
||||
#
|
||||
# This are the three next waypoints (or just the next two or one).
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp # [us] Time since system start.
|
||||
|
||||
PositionSetpoint previous
|
||||
PositionSetpoint current
|
||||
@@ -343,7 +133,7 @@ As there are external tools using uORB messages from log files, such as [Flight
|
||||
This is to ensure that removed fields (or messages) are not re-added in future.
|
||||
- In case of a semantic change (e.g. the unit changes from degrees to radians), the field must be renamed as well and the previous one marked as deprecated as above.
|
||||
|
||||
## Message Versioning (MESSAGE_VERSION) {#message-versioning}
|
||||
## Message Versioning
|
||||
|
||||
<Badge type="tip" text="PX4 v1.16" />
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ Remove propellers before changing ESC configuration parameters!
|
||||
|
||||
Enable DShot for your required outputs in the [Actuator Configuration](../config/actuators.md).
|
||||
|
||||
DShot comes with different speed options: _DShot150_, _DShot300_, _DShot600_ and _DShot1200_, where the number indicates the speed in kilo-bits/second.
|
||||
DShot comes with different speed options: _DShot150_, _DShot300_, and _DShot600_ where the number indicates the speed in kilo-bits/second.
|
||||
You should set the parameter to the highest speed supported by your ESC (according to its datasheet).
|
||||
|
||||
Then connect the battery and arm the vehicle.
|
||||
@@ -110,18 +110,19 @@ The most important ones are:
|
||||
|
||||
:::
|
||||
|
||||
## Telemetry
|
||||
|
||||
Some ESCs are capable of sending telemetry back to the flight controller, including:
|
||||
|
||||
- temperature
|
||||
- voltage
|
||||
- current
|
||||
- accumulated current consumption
|
||||
- RPM values
|
||||
## ESC Telemetry
|
||||
|
||||
Some ESCs are capable of sending telemetry back to the flight controller through a UART RX port.
|
||||
These DShot ESCs will have an additional telemetry wire.
|
||||
|
||||
The provided telemetry includes:
|
||||
|
||||
- Temperature
|
||||
- Voltage
|
||||
- Current
|
||||
- Accumulated current consumption
|
||||
- RPM values
|
||||
|
||||
To enable this feature (on ESCs that support it):
|
||||
|
||||
1. Join all the telemetry wires from all the ESCs together, and then connect them to one of the RX pins on an unused flight controller serial port.
|
||||
@@ -147,3 +148,40 @@ ERROR [dshot] No data received. If telemetry is setup correctly, try again.
|
||||
|
||||
Check manufacturer documentation for confirmation/details.
|
||||
:::
|
||||
|
||||
## Bidirectional DShot (Telemetry)
|
||||
|
||||
<Badge type="tip" text="PX4 v1.16" />
|
||||
|
||||
Bidirectional DShot is a protocol that can provide telemetry including: high rate ESC RPM data, voltage, current, and temperature with a single wire.
|
||||
|
||||
The PX4 implementation currently enables only ESC RPM (eRPM) data collection from each ESC at high frequencies.
|
||||
This telemetry significantly improves the performance of [Dynamic Notch Filters](../config_mc/filter_tuning.md#dynamic-notch-filters) and enables more precise vehicle tuning.
|
||||
|
||||
::: info
|
||||
The [ESC Telemetry](#esc-telemetry) described above is currently still necessary if you want voltage, current, or temperature information.
|
||||
It's setup and use is independent of bidirectional DShot.
|
||||
:::
|
||||
|
||||
### Hardware Setup
|
||||
|
||||
The ESC must be connected to FMU outputs only.
|
||||
These will be labeled `MAIN` on flight controllers that only have one PWM bus, and `AUX` on controllers that have both `MAIN` and `AUX` ports (i.e. FCs that have an IO board).
|
||||
|
||||
:::warning **Limited hardware support**
|
||||
This feature is only supported on flight controllers with the following processors:
|
||||
|
||||
- STM32H7: First four FMU outputs
|
||||
- Must be connected to the first 4 FMU outputs, and these outputs must also be mapped to the same timer.
|
||||
- [KakuteH7](../flight_controller/kakuteh7v2.md) is not supported because the outputs are not mapped to the same timer.
|
||||
- [i.MXRT](../flight_controller/nxp_mr_vmu_rt1176.md) (V6X-RT & Tropic): 8 FMU outputs.
|
||||
|
||||
No other boards are supported.
|
||||
:::
|
||||
|
||||
### Configuration {#bidirectional-dshot-configuration}
|
||||
|
||||
To enable bidirectional DShot, set the [DSHOT_BIDIR_EN](../advanced_config/parameter_reference.md#DSHOT_BIDIR_EN) parameter.
|
||||
|
||||
The system calculates actual motor RPM from the received eRPM data using the [MOT_POLE_COUNT](../advanced_config/parameter_reference.md#MOT_POLE_COUNT) parameter.
|
||||
This parameter must be set correctly for accurate RPM reporting.
|
||||
|
||||
@@ -40,7 +40,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
|
||||
|
||||
### Common
|
||||
|
||||
- TBD
|
||||
- [QGroundControl Bootloader Update](../advanced_config/bootloader_update.md#qgc-bootloader-update-sys-bl-update) via the [SYS_BL_UPDATE](../advanced_config/parameter_reference.md#SYS_BL_UPDATE) parameter has been re-enabled after being broken for a number of releases. ([PX4-Autopilot#25032: build: romf: fix generation of rc.board_bootloader_upgrade](https://github.com/PX4/PX4-Autopilot/pull/25032)).
|
||||
|
||||
### Control
|
||||
|
||||
|
||||
@@ -4,15 +4,15 @@
|
||||
|
||||
It is recommended for:
|
||||
|
||||
* Connecting offboard components that require low bandwidth and low latency communication, e.g. [rangefinders](../sensor/rangefinders.md), [magnetometers](../gps_compass/magnetometer.md), [airspeed sensors](../sensor/airspeed.md) and [tachometers](../sensor/tachometers.md) .
|
||||
* Connecting offboard components that require low bandwidth and low latency communication, e.g. [rangefinders](../sensor/rangefinders.md), [magnetometers](../gps_compass/magnetometer.md), [airspeed sensors](../sensor/airspeed.md) and [tachometers](../sensor/tachometers.md).
|
||||
* Compatibility with peripheral devices that only support I2C.
|
||||
* Allowing multiple devices to attach to a single bus, which is useful for conserving ports.
|
||||
|
||||
I2C allows multiple master devices to connect to multiple slave devices using only 2 wires per connection (SDA, SCL).
|
||||
in theory a bus can support 128 devices, each accessed via its unique address.
|
||||
in theory, a bus can support 128 devices, each accessed via its unique address.
|
||||
|
||||
::: info
|
||||
UAVCAN would normally be preferred where higher data rates are required, and on larger vehicles where sensors are be mounted further from the flight controller.
|
||||
UAVCAN would normally be preferred where higher data rates are required, and on larger vehicles where sensors are mounted further from the flight controller.
|
||||
:::
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ UAVCAN would normally be preferred where higher data rates are required, and on
|
||||
|
||||
I2C uses a pair of wires: SDA (serial data) and SCL (serial clock).
|
||||
The bus is of open-drain type, meaning that devices ground the data line.
|
||||
It uses a pullup resistor to push it to `log.1` (idle state) - every wire has it usually located on the bus terminating devices.
|
||||
It uses a pull-up resistor to push it to `log.1` (idle state) - every wire has it usually located on the bus terminating devices.
|
||||
One bus can connect to multiple I2C devices.
|
||||
The individual devices are connected without any crossing.
|
||||
|
||||
@@ -52,41 +52,44 @@ If two I2C devices on a bus have the same ID there will be a clash, and neither
|
||||
This usually occurs because a user needs to attach two sensors of the same type to the bus, but may also happen if devices use duplicate addresses by default.
|
||||
|
||||
Particular I2C devices may allow you to select a new address for one of the devices to avoid the clash.
|
||||
Some devices do not support this option, or do not have broad options for the addresses that can be used (i.e. cannot be used to avoid a clash).
|
||||
Some devices do not support this option or do not have broad options for the addresses that can be used (i.e. cannot be used to avoid a clash).
|
||||
|
||||
If you can't change the addresses, one option is to use an [I2C Address Translator](#i2c-address-translators).
|
||||
|
||||
### Insufficient Transfer Capacity
|
||||
|
||||
The bandwidth available for each individual device generally decreases as more devices are added. The exact decrease depends on the bandwidth used by each individual device. Therefore it is possible to connect many low bandwidth devices, like [tachometers](../sensor/tachometers.md).
|
||||
The bandwidth available for each device generally decreases as more devices are added. The exact decrease depends on the bandwidth used by each individual device. Therefore it is possible to connect many low-bandwidth devices, like [tachometers](../sensor/tachometers.md).
|
||||
If too many devices are added, it can cause transmission errors and network unreliability.
|
||||
|
||||
There are several ways to reduce the problem:
|
||||
* Dividing the devices into groups, each with approximately the same number of devices and connecting each group to one autopilot port
|
||||
* Dividing the devices into groups, each with approximately the same number of devices, and connecting each group to one autopilot port
|
||||
* Increase bus speed limit (usually set to 100kHz for external I2C bus)
|
||||
|
||||
### Excessive Wiring Capacitance
|
||||
|
||||
The electrical capacity of bus wiring increases as more devices/wires are added. The exact decrease depends on total length of bus wiring and wiring specific capacitance.
|
||||
The electrical capacity of bus wiring increases as more devices/wires are added. The exact decrease depends on the total length of bus wiring and wiring-specific capacitance.
|
||||
The problem can be analyzed using an oscilloscope, where we see that the edges of SDA/SCL signals are no longer sharp.
|
||||
|
||||
There are several ways to reduce the problem:
|
||||
* Dividing the devices into groups, each with approximately the same number of devices and connecting each group to one autopilot port
|
||||
* Using the shortest and the highest quality I2C cables possible
|
||||
* Separating the devices with a weak open-drain driver to smaller bus with lower capacitance
|
||||
* [I2C Bus Accelerators](#i2c-bus-accelerators)
|
||||
* Dividing the devices into groups, each with approximately the same number of devices, and connecting each group to one autopilot port
|
||||
* Using the shorter and higher quality I2C cables, see the [cable wiring page](../assembly/cable_wiring.md#i2c-cables) for details
|
||||
* Separating the devices with a weak open-drain driver to smaller buses with lower capacitance by using [I2C Bus Accelerators](#i2c-bus-accelerators)
|
||||
|
||||
## I2C Bus Accelerators
|
||||
|
||||
I2C bus accelerators are separate circuits that can be used to support longer wiring length on an I2C bus.
|
||||
I2C bus accelerators are separate circuits that can be used to support longer wiring lengths on an I2C bus.
|
||||
They work by physically dividing an I2C network into 2 parts and using their own transistors to amplify I2C signals.
|
||||
|
||||
Available accelerators include:
|
||||
- [Thunderfly TFI2CEXT01](https://github.com/ThunderFly-aerospace/TFI2CEXT01):
|
||||
- [Thunderfly TFI2CEXT01](https://docs.thunderfly.cz/avionics/TFI2CEXT01/):
|
||||

|
||||
- This has Dronecode connectors and is hence very easy to add to a Pixhawk I2C setup.
|
||||
- The module has no settings (it works out of the box).
|
||||
|
||||
### I2C Level Converter function
|
||||
|
||||
Some I2C devices have 5V on the data lines, while the Pixhawk connector standard port expects these lines to be 3.3 V.
|
||||
You can use the TFI2CEXT01 as a level converter to connect 5V devices to a Pixhawk I2C port. This feature is possible because the SCL and SDA lines of TFI2CEXT01 are 5V tolerant.
|
||||
|
||||
## I2C Address Translators
|
||||
|
||||
@@ -96,21 +99,12 @@ The work by listening for I2C communication and transforming the address when a
|
||||
Supported I2C Address Translators include:
|
||||
|
||||
- [Thunderfly TFI2CADT01](../sensor_bus/translator_tfi2cadt.md)
|
||||
|
||||
- This has Dronecode connectors and is very easy to add to a Pixhawk I2C setup.
|
||||
|
||||
## I2C Bus Splitters
|
||||
|
||||
I2C Bus Splitters are circuit boards that split the I2C port on your flight controller into multiple ports.
|
||||
They are useful if you want to use multiple I2C peripherals on a flight controller that has only one I2C port (or too few), such as an airspeed sensor and a distance sensor.
|
||||
|
||||
You can find an appropriate board using an internet search.
|
||||
|
||||
## I2C Level Converter
|
||||
|
||||
Some I2C devices have 5V on the data lines, while the Pixhawk connector standard port expects these lines to be 3.3 V.
|
||||
You can use an I2C level converter to connect 5V devices to a Pixhawk I2C port.
|
||||
|
||||
You can find an appropriate covnerter using an internet search.
|
||||
I2C Bus Splitters are devices that split the I2C port on your flight controller into multiple connectors.
|
||||
They are useful if you want to use multiple I2C peripherals on a flight controller that has only one I2C port (or too few), such as an airspeed sensor and a distance sensor. Both devices [I2C Address Translator](../sensor_bus/translator_tfi2cadt.md) and [I2C Bus Accelerators](#i2c-bus-accelerators) could also be used as I2C splitters because they have multiple I2C connectors for connecting additional I2C devices.
|
||||
|
||||
## I2C Development
|
||||
|
||||
|
||||
@@ -1,12 +1,11 @@
|
||||
# TFI2CADT01 - I²C Address Translator
|
||||
|
||||
[TFI2CADT01](https://github.com/ThunderFly-aerospace/TFI2CADT01) is an address translator module that is compatible with Pixhawk and PX4.
|
||||
[TFI2CADT01](https://docs.thunderfly.cz/avionics/TFI2CADT01/) is an address translator module that is compatible with Pixhawk and PX4.
|
||||
|
||||
Address translation allows multiple I2C devices with the same address to coexist on an I2C network.
|
||||
The module may be needed if using several devices that have the same hard-coded address.
|
||||
|
||||
The module has an input and an output side.
|
||||
A sensor is connected to the master device on one side.
|
||||
The module has an input and an output side and a sensor is connected to the master device on one side.
|
||||
On the output side sensors, whose addresses are to be translated, can be connected.
|
||||
The module contains two pairs of connectors, each pair responsible for different translations.
|
||||
|
||||
@@ -14,7 +13,7 @@ The module contains two pairs of connectors, each pair responsible for different
|
||||
|
||||
::: info
|
||||
[TFI2CADT01](https://github.com/ThunderFly-aerospace/TFI2CADT01) is designed as open-source hardware with GPLv3 license.
|
||||
It is commercially available from [ThunderFly](https://www.thunderfly.cz/) company or from [Tindie eshop](https://www.tindie.com/products/thunderfly/tfi2cadt01-i2c-address-translator/).
|
||||
It is commercially available from [ThunderFly](https://www.thunderfly.cz/) company or from [Tindie eshop](https://www.tindie.com/products/26353/).
|
||||
:::
|
||||
|
||||
## Address Translation Method
|
||||
@@ -31,7 +30,7 @@ If you need your own value for address translation, changing the configuration r
|
||||
The tachometer sensor [TFRPM01](../sensor/thunderfly_tachometer.md) can be set to two different addresses using a solder jumper.
|
||||
If the autopilot has three buses, only 6 sensors can be connected and no bus remains free (2 available addresses * 3 I2C ports).
|
||||
In some multicopters or VTOL solutions, there is a need to measure the RPM of 8 or more elements.
|
||||
The [TFI2CADT01](https://www.tindie.com/products/thunderfly/tfi2cadt01-i2c-address-translator/) is highly recommended in this case.
|
||||
The [TFI2CADT01](https://www.tindie.com/products/26353/) is highly recommended in this case.
|
||||
|
||||

|
||||
|
||||
@@ -58,7 +57,7 @@ graph TD
|
||||
|
||||
::: info
|
||||
TFI2CADT01 does not contain any I2C buffer or accelerator.
|
||||
As it adds additional capacitance on the bus, we advise combining it with some bus booster, e.g. [TFI2CEXT01](https://github.com/ThunderFly-aerospace/TFI2CEXT01).
|
||||
As it adds additional capacitance on the bus, we advise combining it with some bus booster, e.g. [TFI2CEXT01](https://docs.thunderfly.cz/avionics/TFI2CEXT01/).
|
||||
:::
|
||||
|
||||
### Other Resources
|
||||
|
||||
@@ -733,6 +733,7 @@
|
||||
- [Protocols/Microservices](mavlink/protocols.md)
|
||||
- [Standard Modes Protocol](mavlink/standard_modes.md)
|
||||
- [uXRCE-DDS (PX4-ROS 2/DDS Bridge)](middleware/uxrce_dds.md)
|
||||
- [UORB Bridged to ROS 2](middleware/dds_topics.md)
|
||||
- [모듈과 명령어](modules/modules_main.md)
|
||||
- [자동 튜닝](modules/modules_autotune.md)
|
||||
- [명령어](modules/modules_command.md)
|
||||
|
||||
@@ -128,21 +128,21 @@ You add some "boilerplate" code to regularly listen for changes in the [uORB Top
|
||||
|
||||
- **px4_platform_common/module_params.h** to get the `DEFINE_PARAMETERS` macro:
|
||||
|
||||
```cpp
|
||||
#include <px4_platform_common/module_params.h>
|
||||
```
|
||||
```cpp
|
||||
#include <px4_platform_common/module_params.h>
|
||||
```
|
||||
|
||||
- **parameter_update.h** to access the uORB `parameter_update` message:
|
||||
|
||||
```cpp
|
||||
#include <uORB/topics/parameter_update.h>
|
||||
```
|
||||
```cpp
|
||||
#include <uORB/topics/parameter_update.h>
|
||||
```
|
||||
|
||||
- **Subscription.hpp** for the uORB C++ subscription API:
|
||||
|
||||
```cpp
|
||||
#include <uORB/Subscription.hpp>
|
||||
```
|
||||
```cpp
|
||||
#include <uORB/Subscription.hpp>
|
||||
```
|
||||
|
||||
Derive your class from `ModuleParams`, and use `DEFINE_PARAMETERS` to specify a list of parameters and their associated parameter attributes.
|
||||
매개변수의 이름은 매개변수 메타데이터 정의와 동일하여야 합니다.
|
||||
@@ -194,7 +194,7 @@ void Module::parameters_update()
|
||||
- `_parameter_update_sub.updated()` tells us if there is _any_ update to the `param_update` uORB message (but not what parameter is affected).
|
||||
- If there has been "some" parameter updated, we copy the update into a `parameter_update_s` (`param_update`), to clear the pending update.
|
||||
- Then we call `ModuleParams::updateParams()`.
|
||||
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
|
||||
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
|
||||
|
||||
The parameter attributes (`_sys_autostart` and `_att_bias_max` in this case) can then be used to represent the parameters, and will be updated whenever the parameter value changes.
|
||||
|
||||
@@ -267,12 +267,12 @@ YAML meta data is intended as a full replacement for the **.c** definitions.
|
||||
- An example of YAML definitions being used can be found in the MAVLink parameter definitions: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/module.yaml).
|
||||
- YAML 파일은 다음을 추가하여 cmake 빌드 시스템에 등록됩니다.
|
||||
|
||||
```cmake
|
||||
MODULE_CONFIG
|
||||
module.yaml
|
||||
```
|
||||
```cmake
|
||||
MODULE_CONFIG
|
||||
module.yaml
|
||||
```
|
||||
|
||||
to the `px4_add_module` section of the `CMakeLists.txt` file of that module.
|
||||
to the `px4_add_module` section of the `CMakeLists.txt` file of that module.
|
||||
|
||||
#### 다중 인스턴스(템플릿) YAML 메타 데이터
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ This guide walks through the process of setting up the board and connecting to P
|
||||
You will temporarily need the following hardware in order to log into your Jetson and get its IP address, after which you will be able to log in via SSH:
|
||||
|
||||
- External display.
|
||||
If your display doesn't have a mini HDMI connector you will also need a [Mini HDMI to HDMI converter](https://a.co/d/6N815N9) if your external display has HDMI input
|
||||
If your display doesn't have a mini HDMI connector you will also need a [Mini HDMI to HDMI converter](https://a.co/d/6N815N9) if your external display has HDMI input
|
||||
- Ethernet cable
|
||||
- Mouse and keyboard (the baseboard has 4 USB ports exposed from Jetson, two of which are USB 3.0)
|
||||
|
||||
@@ -45,11 +45,11 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- 크기
|
||||
|
||||
- 126 x 80 x 45mm (with Jetson Orin NX + Heatsink/Fan & FC Module)
|
||||
- 126 x 80 x 22.9mm (without Jetson and FC Module)
|
||||
- 126 x 80 x 45mm (with Jetson Orin NX + Heatsink/Fan & FC Module)
|
||||
- 126 x 80 x 22.9mm (without Jetson and FC Module)
|
||||
|
||||
- 중량
|
||||
- 190g (with Jetson, Heatsink, Flight Controller, M.2 SSD, M.2 Wi-Fi Module)
|
||||
- 190g (with Jetson, Heatsink, Flight Controller, M.2 SSD, M.2 Wi-Fi Module)
|
||||
|
||||
:::
|
||||
|
||||
@@ -57,67 +57,67 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- 2x Gigabit Ethernet Port
|
||||
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- Ethernet Switch powered by the same circuit as the Pixhawk
|
||||
- 8-pin JST-GH
|
||||
- RJ45
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- Ethernet Switch powered by the same circuit as the Pixhawk
|
||||
- 8-pin JST-GH
|
||||
- RJ45
|
||||
|
||||
- 2x MIPI CSI Camera Inputs
|
||||
|
||||
- 4 Lanes each
|
||||
- 22-Pin Raspberry Pi Cam FFC
|
||||
- 4 Lanes each
|
||||
- 22-Pin Raspberry Pi Cam FFC
|
||||
|
||||
- 2x USB 3.0 Host Port
|
||||
|
||||
- USB A
|
||||
- 5A Current Limit
|
||||
- USB A
|
||||
- 5A Current Limit
|
||||
|
||||
- 2x USB 2.0 Host Port
|
||||
|
||||
- 5-Pin JST-GH
|
||||
- 0A Current Limit
|
||||
- 5-Pin JST-GH
|
||||
- 0A Current Limit
|
||||
|
||||
- USB 2.0 for Programming/Debugging
|
||||
|
||||
- USB-C
|
||||
- USB-C
|
||||
|
||||
- 2 Key M 2242/2280 for NVMe SSD
|
||||
|
||||
- PCIEx4
|
||||
- PCIEx4
|
||||
|
||||
- 2 Key E 2230 for WiFi/BT
|
||||
|
||||
- PCIEx2
|
||||
- USB
|
||||
- UART
|
||||
- I2S
|
||||
- PCIEx2
|
||||
- USB
|
||||
- UART
|
||||
- I2S
|
||||
|
||||
- Mini HDMI Out
|
||||
|
||||
- 4x GPIO
|
||||
|
||||
- 6-pin JST-GH
|
||||
- 6-pin JST-GH
|
||||
|
||||
- CAN Port
|
||||
|
||||
- Connected to Autopilot's CAN2 (4 Pin JST-GH)
|
||||
- Connected to Autopilot's CAN2 (4 Pin JST-GH)
|
||||
|
||||
- SPI Port
|
||||
|
||||
- 7-Pin JST-GH
|
||||
- 7-Pin JST-GH
|
||||
|
||||
- I2C Port
|
||||
|
||||
- 4-Pin JST-GH
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- I2S Port
|
||||
|
||||
- 7-Pin JST-GH
|
||||
- 7-Pin JST-GH
|
||||
|
||||
- 2x UART Port
|
||||
|
||||
- 1 for debug
|
||||
- 1 connected to Autopilot's telem2
|
||||
- 1 for debug
|
||||
- 1 connected to Autopilot's telem2
|
||||
|
||||
- Fan Power Port
|
||||
|
||||
@@ -129,13 +129,13 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- Pixhawk Autopilot Bus Interface
|
||||
|
||||
- 100 Pin Hirose DF40
|
||||
- 50 Pin Hirose DF40
|
||||
- 100 Pin Hirose DF40
|
||||
- 50 Pin Hirose DF40
|
||||
|
||||
- Redundant Digital Power Module Inputs
|
||||
|
||||
- I2C Power Monitor Support
|
||||
- 2x 6-Pin Molex CLIK-Mate
|
||||
- I2C Power Monitor Support
|
||||
- 2x 6-Pin Molex CLIK-Mate
|
||||
|
||||
- Power Path Selector
|
||||
|
||||
@@ -143,68 +143,68 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- 정격 전압
|
||||
|
||||
- 최대 입력 전압: 6V
|
||||
- USB 전원 입력: 4.75~5.25V
|
||||
- 최대 입력 전압: 6V
|
||||
- USB 전원 입력: 4.75~5.25V
|
||||
|
||||
- Full GPS Plus Safety Switch Port
|
||||
|
||||
- 10-Pin JST-GH
|
||||
- 10-Pin JST-GH
|
||||
|
||||
- Secondary (GPS2) Port
|
||||
|
||||
- 6-Pin JST-GH
|
||||
- 6-Pin JST-GH
|
||||
|
||||
- 2x CAN Ports
|
||||
|
||||
- 4-Pin JST-GH
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- 3x Telemetry Ports with Flow Control
|
||||
|
||||
- 2x 6-Pin JST-GH
|
||||
- 1 is connected to Jetson's `UART1` Port
|
||||
- 2x 6-Pin JST-GH
|
||||
- 1 is connected to Jetson's `UART1` Port
|
||||
|
||||
- 16 PWM Outputs
|
||||
|
||||
- 2x 10-Pin JST-GH
|
||||
- 2x 10-Pin JST-GH
|
||||
|
||||
- UART4 & I2C Port
|
||||
|
||||
- 6-Pin JST-GH
|
||||
- 6-Pin JST-GH
|
||||
|
||||
- 2x Gigabit Ethernet Port
|
||||
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- 8-Pin JST-GH
|
||||
- RJ45
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- 8-Pin JST-GH
|
||||
- RJ45
|
||||
|
||||
- AD & IO
|
||||
|
||||
- 8-Pin JST-GH
|
||||
- 8-Pin JST-GH
|
||||
|
||||
- USB 2.0
|
||||
|
||||
- USB-C
|
||||
- 4-Pin JST-GH
|
||||
- USB-C
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- DSM Input
|
||||
|
||||
- 3-Pin JST-ZH 1.5mm Pitch
|
||||
- 3-Pin JST-ZH 1.5mm Pitch
|
||||
|
||||
- RC In
|
||||
|
||||
- PPM/SBUS
|
||||
- 5-Pin JST-GH
|
||||
- PPM/SBUS
|
||||
- 5-Pin JST-GH
|
||||
|
||||
- SPI Port
|
||||
|
||||
- External Sensor Bus (SPI5)
|
||||
- 11-Pin JST-GH
|
||||
- External Sensor Bus (SPI5)
|
||||
- 11-Pin JST-GH
|
||||
|
||||
- 2x Debug Port
|
||||
|
||||
- 1 for FMU
|
||||
- 1 for IO
|
||||
- 10-Pin JST-SH
|
||||
- 1 for FMU
|
||||
- 1 for IO
|
||||
- 10-Pin JST-SH
|
||||
|
||||
:::
|
||||
|
||||
@@ -218,7 +218,7 @@ The Jetson has separate input power circuitry from the Pixhawk autopilot:
|
||||
- 8V/3A Minimum (Depends on Usage and Peripherals)
|
||||
- Voltage Rating: 7-21V (3S-4S)
|
||||
- Jetson Baseboard onboard BEC is rated for 7-21V (3S-4S).
|
||||
Note that the external UBEC-12A can be used for applications above 4S
|
||||
Note that the external UBEC-12A can be used for applications above 4S
|
||||
|
||||
During development using the following wired power supply is recommended:
|
||||
|
||||
@@ -698,7 +698,7 @@ On the following screen, confirm your selected device:
|
||||
|
||||
- Choose `Pre-config` for the OEM Configuration (this will skip Ubuntu first time setup screens after reboot).
|
||||
- Choose your preferred username and password (and write them down).
|
||||
These will be used as your login credentials to Jetpack.
|
||||
These will be used as your login credentials to Jetpack.
|
||||
- Choose `NVMe` as the storage device because the board has separate SSD for storage.
|
||||
|
||||

|
||||
@@ -922,95 +922,95 @@ These instructions approximately mirror the [PX4 Ethernet setup](../advanced_con
|
||||
Next we modify the Jetson IP address to be on the same network as the Pixhawk:
|
||||
|
||||
1. Make sure `netplan` is installed.
|
||||
You can check by running the following command:
|
||||
You can check by running the following command:
|
||||
|
||||
```sh
|
||||
netplan -h
|
||||
```
|
||||
```sh
|
||||
netplan -h
|
||||
```
|
||||
|
||||
If not, install it using the commands:
|
||||
If not, install it using the commands:
|
||||
|
||||
```sh
|
||||
sudo apt update
|
||||
sudo apt install netplan.io
|
||||
```
|
||||
```sh
|
||||
sudo apt update
|
||||
sudo apt install netplan.io
|
||||
```
|
||||
|
||||
2. Check `system_networkd` is running:
|
||||
|
||||
```sh
|
||||
sudo systemctl status systemd-networkd
|
||||
```
|
||||
```sh
|
||||
sudo systemctl status systemd-networkd
|
||||
```
|
||||
|
||||
You should see output like below if it is active:
|
||||
You should see output like below if it is active:
|
||||
|
||||
```sh
|
||||
● systemd-networkd.service - Network Configuration
|
||||
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2024-09-11 23:32:44 EDT; 23min ago
|
||||
TriggeredBy: ● systemd-networkd.socket
|
||||
Docs: man:systemd-networkd.service(8)
|
||||
Main PID: 2452 (systemd-network)
|
||||
Status: "Processing requests..."
|
||||
Tasks: 1 (limit: 18457)
|
||||
Memory: 2.7M
|
||||
CPU: 157ms
|
||||
CGroup: /system.slice/systemd-networkd.service
|
||||
└─2452 /lib/systemd/systemd-networkd
|
||||
```sh
|
||||
● systemd-networkd.service - Network Configuration
|
||||
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2024-09-11 23:32:44 EDT; 23min ago
|
||||
TriggeredBy: ● systemd-networkd.socket
|
||||
Docs: man:systemd-networkd.service(8)
|
||||
Main PID: 2452 (systemd-network)
|
||||
Status: "Processing requests..."
|
||||
Tasks: 1 (limit: 18457)
|
||||
Memory: 2.7M
|
||||
CPU: 157ms
|
||||
CGroup: /system.slice/systemd-networkd.service
|
||||
└─2452 /lib/systemd/systemd-networkd
|
||||
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: lo: Gained carrier
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: eth0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: Enumeration completed
|
||||
Sep 11 23:32:44 ubuntu systemd[1]: Started Network Configuration.
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Connected WiFi access point: Verizon_7YLWWD (78:67:0e:ea:a6:0>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
```
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: lo: Gained carrier
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: eth0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: Enumeration completed
|
||||
Sep 11 23:32:44 ubuntu systemd[1]: Started Network Configuration.
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Connected WiFi access point: Verizon_7YLWWD (78:67:0e:ea:a6:0>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
```
|
||||
|
||||
If `system_networkd` is not running, it can be enabled using:
|
||||
If `system_networkd` is not running, it can be enabled using:
|
||||
|
||||
```sh
|
||||
sudo systemctl start systemd-networkd
|
||||
sudo systemctl enable systemd-networkd
|
||||
```
|
||||
```sh
|
||||
sudo systemctl start systemd-networkd
|
||||
sudo systemctl enable systemd-networkd
|
||||
```
|
||||
|
||||
3. Open the Netplan configuration file (so we can set up a static IP for the Jetson).
|
||||
|
||||
The Netplan configuration file is usually located in the `/etc/netplan/` directory and named something like `01-netcfg.yaml` (the name can vary).
|
||||
Below we use `nano` to open the file, but you can use your preferred text editor:
|
||||
The Netplan configuration file is usually located in the `/etc/netplan/` directory and named something like `01-netcfg.yaml` (the name can vary).
|
||||
Below we use `nano` to open the file, but you can use your preferred text editor:
|
||||
|
||||
```sh
|
||||
sudo nano /etc/netplan/01-netcfg.yaml
|
||||
```
|
||||
```sh
|
||||
sudo nano /etc/netplan/01-netcfg.yaml
|
||||
```
|
||||
|
||||
4. Modify the yaml configuration, by overwriting the contents with the following information and then saving:
|
||||
|
||||
```sh
|
||||
network:
|
||||
version: 2
|
||||
renderer: networkd
|
||||
ethernets:
|
||||
eth0:
|
||||
dhcp4: no
|
||||
addresses:
|
||||
- 10.41.10.1/24
|
||||
routes:
|
||||
- to: 0.0.0.0/0
|
||||
via: 10.41.10.254
|
||||
nameservers:
|
||||
addresses:
|
||||
- 10.41.10.254
|
||||
```
|
||||
```sh
|
||||
network:
|
||||
version: 2
|
||||
renderer: networkd
|
||||
ethernets:
|
||||
eth0:
|
||||
dhcp4: no
|
||||
addresses:
|
||||
- 10.41.10.1/24
|
||||
routes:
|
||||
- to: 0.0.0.0/0
|
||||
via: 10.41.10.254
|
||||
nameservers:
|
||||
addresses:
|
||||
- 10.41.10.254
|
||||
```
|
||||
|
||||
This gives the Jetson a static IP address on the Ethernet interface of `10.41.10.1` .
|
||||
This gives the Jetson a static IP address on the Ethernet interface of `10.41.10.1` .
|
||||
|
||||
5. Apply the changes using the following command:
|
||||
|
||||
```sh
|
||||
sudo netplan apply
|
||||
```
|
||||
```sh
|
||||
sudo netplan apply
|
||||
```
|
||||
|
||||
The Pixhawk Ethernet address is set to `10.41.10.2` by default, which is on the same subnet.
|
||||
We can test our changes above by pinging the Pixhawk from within the Jetson terminal:
|
||||
@@ -1221,15 +1221,15 @@ Assuming the client is set up as defined above:
|
||||
|
||||
- (Serial connection) Start the agent on `/dev/ttyTHS1`:
|
||||
|
||||
```sh
|
||||
sudo MicroXRCEAgent serial --dev /dev/ttyTHS1 -b 921600
|
||||
```
|
||||
```sh
|
||||
sudo MicroXRCEAgent serial --dev /dev/ttyTHS1 -b 921600
|
||||
```
|
||||
|
||||
- (Ethernet) Start the agent on UDP port `8888`:
|
||||
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
|
||||
If your agent and client are connected and no nodes are running, you should see output similar to this in the Agent terminal:
|
||||
|
||||
|
||||
@@ -71,42 +71,42 @@ Explanations and requirements:
|
||||
- `/* EVENT`: This tag indicates that a comment defines metadata for the following event.
|
||||
|
||||
- **event_name**: the event name (`events::ID(event_name)`).
|
||||
- must be unique within the whole source code of PX4.
|
||||
As a general convention, prefix it with the module name, or the source file for larger modules.
|
||||
- must be a valid variable name, i.e. must not contain spaces, colons, etc.
|
||||
- from that name, a 24 bit event ID is derived using a hash function.
|
||||
This means as long as the event name stays the same, so will the ID.
|
||||
- must be unique within the whole source code of PX4.
|
||||
As a general convention, prefix it with the module name, or the source file for larger modules.
|
||||
- must be a valid variable name, i.e. must not contain spaces, colons, etc.
|
||||
- from that name, a 24 bit event ID is derived using a hash function.
|
||||
This means as long as the event name stays the same, so will the ID.
|
||||
|
||||
- **Log Level**:
|
||||
|
||||
- valid log levels are the same as used in the MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY) enum.
|
||||
In order of descending importance these are:
|
||||
- valid log levels are the same as used in the MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY) enum.
|
||||
In order of descending importance these are:
|
||||
|
||||
```plain
|
||||
Emergency,
|
||||
Alert,
|
||||
Critical,
|
||||
Error,
|
||||
Warning,
|
||||
Notice,
|
||||
Info,
|
||||
Debug,
|
||||
Disabled,
|
||||
```
|
||||
```plain
|
||||
Emergency,
|
||||
Alert,
|
||||
Critical,
|
||||
Error,
|
||||
Warning,
|
||||
Notice,
|
||||
Info,
|
||||
Debug,
|
||||
Disabled,
|
||||
```
|
||||
|
||||
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
|
||||
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
|
||||
There are cases it makes sense to have two different log levels.
|
||||
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
|
||||
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
|
||||
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
|
||||
There are cases it makes sense to have two different log levels.
|
||||
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
|
||||
|
||||
- **Event Message**:
|
||||
- Single-line, short message of the event.
|
||||
It may contain template placeholders for arguments (e.g. `{1}`). For more information see below.
|
||||
- Single-line, short message of the event.
|
||||
It may contain template placeholders for arguments (e.g. `{1}`). For more information see below.
|
||||
|
||||
- **Event Description**:
|
||||
- Detailed, optional event description.
|
||||
- Can be multiple lines/paragraphs.
|
||||
- It may contain template placeholders for arguments (e.g. `{2}`) and supported tags (see below)
|
||||
- Detailed, optional event description.
|
||||
- Can be multiple lines/paragraphs.
|
||||
- It may contain template placeholders for arguments (e.g. `{2}`) and supported tags (see below)
|
||||
|
||||
#### Arguments and Enums
|
||||
|
||||
@@ -125,35 +125,35 @@ Text format for event message description:
|
||||
|
||||
- characters can be escaped with \\
|
||||
|
||||
These have to be escaped: '\\\\', '\\<', '\\{'.
|
||||
These have to be escaped: '\\\\', '\\<', '\\{'.
|
||||
|
||||
- supported tags:
|
||||
|
||||
- Profiles: `<profile name="[!]NAME">CONTENT</profile>`
|
||||
- Profiles: `<profile name="[!]NAME">CONTENT</profile>`
|
||||
|
||||
`CONTENT` will only be shown if the name matches the configured profile.
|
||||
This can be used for example to hide developer information from end-users.
|
||||
`CONTENT` will only be shown if the name matches the configured profile.
|
||||
This can be used for example to hide developer information from end-users.
|
||||
|
||||
- URLs: `<a [href="URL"]>CONTENT</a>`.
|
||||
If `href` is not set, use `CONTENT` as `URL` (i.e.`<a>https://docs.px4.io</a>` is interpreted as `<a href="https://docs.px4.io">https://docs.px4.io</a>`)
|
||||
- URLs: `<a [href="URL"]>CONTENT</a>`.
|
||||
If `href` is not set, use `CONTENT` as `URL` (i.e.`<a>https://docs.px4.io</a>` is interpreted as `<a href="https://docs.px4.io">https://docs.px4.io</a>`)
|
||||
|
||||
- Parameters: `<param>PARAM_NAME</param>`
|
||||
- Parameters: `<param>PARAM_NAME</param>`
|
||||
|
||||
- no nested tags of the same type are allowed
|
||||
- no nested tags of the same type are allowed
|
||||
|
||||
- arguments: template placeholders that follow python syntax, with 1-based indexing (instead of 0)
|
||||
|
||||
- general form: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
|
||||
- general form: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
|
||||
|
||||
UNIT:
|
||||
UNIT:
|
||||
|
||||
- m: horizontal distance in meters
|
||||
- m_v: vertical distance in meters
|
||||
- m^2: area in m^2
|
||||
- m/s: speed in m/s
|
||||
- C: temperature in degrees celsius
|
||||
- m: horizontal distance in meters
|
||||
- m_v: vertical distance in meters
|
||||
- m^2: area in m^2
|
||||
- m/s: speed in m/s
|
||||
- C: temperature in degrees celsius
|
||||
|
||||
- `NUM_DECIMAL_DIGITS` only makes sense for real number arguments.
|
||||
- `NUM_DECIMAL_DIGITS` only makes sense for real number arguments.
|
||||
|
||||
## 로깅
|
||||
|
||||
|
||||
+14
-14
@@ -38,9 +38,9 @@ A frame configuration can define everything about a vehicle, from it's geometry
|
||||
When you're bringing up a new vehicle though, the frame will usually contain a fairly minimal configuration:
|
||||
|
||||
- Frames named with "Generic" define the vehicle type, number of rotors, and "placeholder" rotor positions.
|
||||
After selecting the airframe you define the actual geometry and then configure outputs.
|
||||
After selecting the airframe you define the actual geometry and then configure outputs.
|
||||
- Frames named with model/brand will define the vehicle type, number of rotors, actual rotor positions, and motor directions.
|
||||
After selecting the airframe you usually still have to configure outputs.
|
||||
After selecting the airframe you usually still have to configure outputs.
|
||||
|
||||
:::
|
||||
|
||||
@@ -52,7 +52,7 @@ This ensures that all ESC provide exactly the same output for a given input (ide
|
||||
The final step is [Motor Configuration](../config/actuators.md#motor-configuration):
|
||||
|
||||
- [Reverse any motors](../config/actuators.md#reversing-motors) that don't match the spin direction configured in the Geometry.
|
||||
For DShot ESC you can do this through the Acuator Testing UI.
|
||||
For DShot ESC you can do this through the Acuator Testing UI.
|
||||
- PWM, OneShot, and CAN ESC, set the motor input limits for disarmed, low and high speed (not needed for DShot ESC)
|
||||
|
||||
Relevant topics:
|
||||
@@ -123,14 +123,14 @@ Tuning is the final step, carried out only after most other setup and configurat
|
||||
|
||||
- [Autotune](../config/autotune_mc.md) — Automates tuning PX4 rate and attitude controllers (recommended).
|
||||
|
||||
::: info
|
||||
Automatic tuning works on frames that have reasonable authority and dynamics around all the body axes.
|
||||
It has primarily been tested on racing quads and X500, and is expected to be less effective on tricopters with a tiltable rotor.
|
||||
::: info
|
||||
Automatic tuning works on frames that have reasonable authority and dynamics around all the body axes.
|
||||
It has primarily been tested on racing quads and X500, and is expected to be less effective on tricopters with a tiltable rotor.
|
||||
|
||||
Manual tuning using these guides are only needed if there is a problem with autotune:
|
||||
Manual tuning using these guides are only needed if there is a problem with autotune:
|
||||
|
||||
- [MC PID Tuning (Manual/Basic)](../config_mc/pid_tuning_guide_multicopter_basic.md) — Manual tuning basic how to.
|
||||
- [MC PID Tuning Guide (Manual/Detailed)](../config_mc/pid_tuning_guide_multicopter.md) — Manual tuning with detailed explanation.
|
||||
- [MC PID Tuning (Manual/Basic)](../config_mc/pid_tuning_guide_multicopter_basic.md) — Manual tuning basic how to.
|
||||
- [MC PID Tuning Guide (Manual/Detailed)](../config_mc/pid_tuning_guide_multicopter.md) — Manual tuning with detailed explanation.
|
||||
|
||||
|
||||
:::
|
||||
@@ -138,7 +138,7 @@ Tuning is the final step, carried out only after most other setup and configurat
|
||||
- [MC Filter/Control Latency Tuning](../config_mc/filter_tuning.md) — Trade off control latency and noise filtering.
|
||||
|
||||
- [MC Setpoint Tuning (Trajectory Generator)](../config_mc/mc_trajectory_tuning.md)
|
||||
- [MC Jerk-limited Type Trajectory](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
- [MC Jerk-limited Type Trajectory](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
|
||||
- [Multicopter Racer Setup](../config_mc/racer_setup.md)
|
||||
|
||||
@@ -167,7 +167,7 @@ Yes but it must be physically feasible. E.g. if you make a quadrotor where all m
|
||||
- [Flight Controller Peripherals](../peripherals/index.md) - Setup specific sensors, optional sensors, actuators, and so on.
|
||||
- [Advanced Configuration](../advanced_config/index.md) - Factory/OEM calibration, configuring advanced features, less-common configuration.
|
||||
- Vehicle-Centric Config/Tuning:
|
||||
- **Multicopter Config/Tuning**
|
||||
- [Helicopter Config/Tuning](../config_heli/index.md)
|
||||
- [Fixed Wing Config/Tuning](../config_fw/index.md)
|
||||
- [VTOL Config/Tuning](../config_vtol/index.md)
|
||||
- **Multicopter Config/Tuning**
|
||||
- [Helicopter Config/Tuning](../config_heli/index.md)
|
||||
- [Fixed Wing Config/Tuning](../config_fw/index.md)
|
||||
- [VTOL Config/Tuning](../config_vtol/index.md)
|
||||
|
||||
@@ -26,13 +26,13 @@ ARF 키트는 PX4와 호환되는 대부분의 비행 콘트롤러를 지원합
|
||||
The Holybro [X500 V2 Kit](https://holybro.com/collections/x500-kits) includes almost all the required components:
|
||||
|
||||
- X500V2 프레임 키트
|
||||
- Body - Full Carbon Fiber Top & Bottom plate (144 x 144mm, 2mm thick)
|
||||
- Arm - High strength & ultra-lightweight 16mm carbon fiber tubes
|
||||
- Landing gear - 16mm & 10mm diameter carbon fiber tubes
|
||||
- Platform board - With mounting holes for GPS & popular companion computer
|
||||
- 이중 10mm Ø 로드 x 250mm 롱 레일 마운팅 시스템
|
||||
- 2개의 배터리 스트랩이 있는 배터리 마운트
|
||||
- 설치용 수공구
|
||||
- Body - Full Carbon Fiber Top & Bottom plate (144 x 144mm, 2mm thick)
|
||||
- Arm - High strength & ultra-lightweight 16mm carbon fiber tubes
|
||||
- Landing gear - 16mm & 10mm diameter carbon fiber tubes
|
||||
- Platform board - With mounting holes for GPS & popular companion computer
|
||||
- 이중 10mm Ø 로드 x 250mm 롱 레일 마운팅 시스템
|
||||
- 2개의 배터리 스트랩이 있는 배터리 마운트
|
||||
- 설치용 수공구
|
||||
- Holybro Motors - 2216 KV880 x6 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
- Holybro BLHeli S ESC 20A x4 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
- Propellers - 1045 x4 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
@@ -93,92 +93,92 @@ Tools are included to do the assembly, however you may need:
|
||||
Estimate time to assemble is 55 min (25 minutes for frame, 30 minutes for autopilot installation/configuration)
|
||||
|
||||
1. Start by assembling the payload & battery holder.
|
||||
Push the rubbers into grippers (Do not use sharp items to push them in!).
|
||||
Next, pass the holders through the holder bars with the battery holder bases as Figure 3.
|
||||
Push the rubbers into grippers (Do not use sharp items to push them in!).
|
||||
Next, pass the holders through the holder bars with the battery holder bases as Figure 3.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 2_: Payload holder components
|
||||
_Figure 2_: Payload holder components
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 3_: Payload holder assembled
|
||||
_Figure 3_: Payload holder assembled
|
||||
|
||||
2. The next is to go for attaching the bottom plate to the payload holder.
|
||||
|
||||
You will need the parts as shown in Figure 4.
|
||||
Then mount the base for power distribution board using nylon nuts as Figure 5.
|
||||
Finally using 8 hex screws you can join the bottom plate to the payload holder (Figure 7)
|
||||
You will need the parts as shown in Figure 4.
|
||||
Then mount the base for power distribution board using nylon nuts as Figure 5.
|
||||
Finally using 8 hex screws you can join the bottom plate to the payload holder (Figure 7)
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 4_: Needed Materials
|
||||
_Figure 4_: Needed Materials
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 5_: PDB mount base
|
||||
_Figure 5_: PDB mount base
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 6_: Mounted pdb with nylon nuts
|
||||
_Figure 6_: Mounted pdb with nylon nuts
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 7_: Mounted Plate on payload holder
|
||||
_Figure 7_: Mounted Plate on payload holder
|
||||
|
||||
3. Let's gather the stuff needed for mounting landing gear as Figure 8.
|
||||
Use the hex screws to join landing gears to the bottom plate.
|
||||
You also need to open three hex screws on each of the leg stands so you can push them into carbon fiber pipes.
|
||||
Do not forget to tighten them back again.
|
||||
Use the hex screws to join landing gears to the bottom plate.
|
||||
You also need to open three hex screws on each of the leg stands so you can push them into carbon fiber pipes.
|
||||
Do not forget to tighten them back again.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 8_: Required parts for landing gear attachment
|
||||
_Figure 8_: Required parts for landing gear attachment
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 9_: Landing gear attachment to the body
|
||||
_Figure 9_: Landing gear attachment to the body
|
||||
|
||||
4. We will gather all the arms now to mount the top plate.
|
||||
Please pay attention that the motor numbers on arms are a match with the ones mentioned on the top plate.
|
||||
Fortunately, motors are mounted and ESCs have been connected in advance.
|
||||
Start by passing through all the screws as you have the arms fixed in their own places (They have a guide as shown in Figure 11 to ensure they are in place) and tighten all nylon nuts a bit.
|
||||
Then you can connect XT30 power connectors to the power board.
|
||||
Please keep in mind that the signal wires have to be passed through the top plate such that we can connect them later to Pixhawk.
|
||||
Please pay attention that the motor numbers on arms are a match with the ones mentioned on the top plate.
|
||||
Fortunately, motors are mounted and ESCs have been connected in advance.
|
||||
Start by passing through all the screws as you have the arms fixed in their own places (They have a guide as shown in Figure 11 to ensure they are in place) and tighten all nylon nuts a bit.
|
||||
Then you can connect XT30 power connectors to the power board.
|
||||
Please keep in mind that the signal wires have to be passed through the top plate such that we can connect them later to Pixhawk.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/needed_stuff_top_plate.png" width="700" title="Arms and top plate materials">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/needed_stuff_top_plate.png" width="700" title="Arms and top plate materials">
|
||||
|
||||
_Figure 10_: Connecting arms needed materials.
|
||||
_Figure 10_: Connecting arms needed materials.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/guide_for_arm_mount.png" width="700" title="Guide for the arms mount">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/guide_for_arm_mount.png" width="700" title="Guide for the arms mount">
|
||||
|
||||
_Figure 11_: Guide for the arms mount
|
||||
_Figure 11_: Guide for the arms mount
|
||||
|
||||
5. Tighten all 16 screws and nuts by using both hex wrench and nut driver.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 12_: Mounted top plate
|
||||
_Figure 12_: Mounted top plate
|
||||
|
||||
6. Next you can mount your pixhawk on the top plate by using the stickers.
|
||||
It is recommended to have the direction of your Pixhawk's arrow the same as the one mentioned on the top plate.
|
||||
It is recommended to have the direction of your Pixhawk's arrow the same as the one mentioned on the top plate.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 13_: Sticker tapes on Pixhawk
|
||||
_Figure 13_: Sticker tapes on Pixhawk
|
||||
|
||||
7. If you want to mount the GPS on the companion computer plate, you can now secure the GPS mount onto it using 4 screws and nuts.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/gps_mount_plate.png" width="400" title="Secure GPS mount onto companion plate">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/gps_mount_plate.png" width="400" title="Secure GPS mount onto companion plate">
|
||||
|
||||
_Figure 14_: Secure GPS mount onto companion plate
|
||||
_Figure 14_: Secure GPS mount onto companion plate
|
||||
|
||||
8. 테이프를 사용하여 GPS를 GPS 마스트 상단에 붙이고 GPS 마스트를 장착합니다.
|
||||
Make sure the arrow on the gps is pointing forward (Figure 15).
|
||||
Make sure the arrow on the gps is pointing forward (Figure 15).
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_holybro_pixhawk4/gps2.jpg" width="400" title="Figure 16: GPS and mast">
|
||||
<img src="../../assets/airframes/multicopter/x500_holybro_pixhawk4/gps2.jpg" width="400" title="Figure 16: GPS and mast">
|
||||
|
||||
_Figure 15_: GPS and mast
|
||||
_Figure 15_: GPS and mast
|
||||
|
||||
9. Finally, you can connect the Pixhawk interfaces such as telemetry radio to 'TELEM1' and motors signal cables accordingly.
|
||||
|
||||
@@ -204,14 +204,14 @@ First update the firmware, airframe, and actuator mappings:
|
||||
|
||||
- [Airframe](../config/airframe.md)
|
||||
|
||||
You will need to select the _Holybro X500 V2_ airframe (**Quadrotor x > Holybro 500 V2**)
|
||||
You will need to select the _Holybro X500 V2_ airframe (**Quadrotor x > Holybro 500 V2**)
|
||||
|
||||

|
||||

|
||||
|
||||
- [Actuators](../config/actuators.md)
|
||||
- You should not need to update the vehicle geometry (as this is a preconfigured airframe).
|
||||
- Assign actuator functions to outputs to match your wiring.
|
||||
- Test the configuration using the sliders.
|
||||
- You should not need to update the vehicle geometry (as this is a preconfigured airframe).
|
||||
- Assign actuator functions to outputs to match your wiring.
|
||||
- Test the configuration using the sliders.
|
||||
|
||||
그리고, 설치후에 필수적인 설정 작업과 보정 작업을 진행하여야 합니다.
|
||||
|
||||
|
||||
@@ -20,12 +20,12 @@ Key airframe features:
|
||||
- Removable V tail or conventional tail options included
|
||||
- Threaded inserts in the wings and fuselage top for external mounting
|
||||
- Numerous mounting features
|
||||
- Top antenna hole
|
||||
- Top GPS cover
|
||||
- Side "T" antenna mounts
|
||||
- Rear electronics tray
|
||||
- Front facing "action cam" cutout
|
||||
- Front facing FPV camera cutout
|
||||
- Top antenna hole
|
||||
- Top GPS cover
|
||||
- Side "T" antenna mounts
|
||||
- Rear electronics tray
|
||||
- Front facing "action cam" cutout
|
||||
- Front facing FPV camera cutout
|
||||
- Removable wings
|
||||
- Low stall speed
|
||||
- Gentle handling
|
||||
@@ -69,10 +69,10 @@ Key build features
|
||||
- [6s2p 18650 LiIon flight battery](https://www.upgradeenergytech.com/product-page/6s-22-2v-5600mah-30c-dark-lithium-liion-drone-battery) (select XT60 connector)
|
||||
|
||||
- [Custom designed 3D printed parts](https://github.com/PX4/PX4-user_guide/raw/main/assets/airframes/fw/reptile_dragon_2/rd2_3d_printed_parts.zip)
|
||||
- ARK6X carrier mount
|
||||
- Holybro Pixhawk 5x carrier mount
|
||||
- FPV pod and camera mount
|
||||
- Pitot static probe "plug" adapter
|
||||
- ARK6X carrier mount
|
||||
- Holybro Pixhawk 5x carrier mount
|
||||
- FPV pod and camera mount
|
||||
- Pitot static probe "plug" adapter
|
||||
|
||||
- [Custom designed power distribution PCB](https://github.com/PX4/PX4-user_guide/raw/main/assets/airframes/fw/reptile_dragon_2/xt30_power_distro_pcb.zip)
|
||||
|
||||
@@ -426,15 +426,15 @@ Prior to the first flight, a comprehensive preflight must be conducted.
|
||||
I recommend checking the following items:
|
||||
|
||||
- Sensor calibration (QGC)
|
||||
- Mag calibration
|
||||
- Accelerometer calibration
|
||||
- 대기속도 보정
|
||||
- Level horizon calibration
|
||||
- Mag calibration
|
||||
- Accelerometer calibration
|
||||
- 대기속도 보정
|
||||
- Level horizon calibration
|
||||
- Check control surface deflection
|
||||
- Right stick -> Right aileron goes up, left aileron goes down
|
||||
- Left stick -> Left aileron goes up, right aileron goes down
|
||||
- Stick back -> elevator goes up
|
||||
-Stick forward -> elevator goes down
|
||||
-Stick forward -> elevator goes down
|
||||
- Left rudder -> Rudder goes left
|
||||
- Right rudder -> Rudder goes right
|
||||
- Check Px4 inputs (in `stabilized mode`)
|
||||
|
||||
@@ -98,11 +98,11 @@ The mapping between flight controller outputs and specific controls/motors depen
|
||||
Assembly information is covered in several sections:
|
||||
|
||||
- [Basic Assembly](../assembly/index.md) contains topics shows the setup of core components for a number of popular [flight controllers](../flight_controller/index.md).
|
||||
가이드가 없는 비행 컨트롤러는 일반적으로 거의 같은 방법으로 설정됩니다(거의 항상 유사한 설정 가이드가 포함됨).
|
||||
가이드가 없는 비행 컨트롤러는 일반적으로 거의 같은 방법으로 설정됩니다(거의 항상 유사한 설정 가이드가 포함됨).
|
||||
- [Peripherals](../peripherals/index.md) contains information about other peripherals, including [Airspeed Sensors](../sensor/airspeed.md).
|
||||
- [Airframes Reference > VTOL](../airframes/airframe_reference.md#vtol) explains which flight controller outputs must be connected to different flight controls for each airframe configuration:
|
||||
- 정의된 기체의 구성을 선택하십시오. 이는 비행을 위하여 사전 튜닝이 충분하기 때문입니다(미세 조정만 필요할 수 있음).
|
||||
- 그렇지 않으면, 기체와 일치하는 "일반 기체"를 선택하십시오.
|
||||
- 정의된 기체의 구성을 선택하십시오. 이는 비행을 위하여 사전 튜닝이 충분하기 때문입니다(미세 조정만 필요할 수 있음).
|
||||
- 그렇지 않으면, 기체와 일치하는 "일반 기체"를 선택하십시오.
|
||||
|
||||
In addition, build logs showing how others have set up different types of vehicles are provided as sub topics.
|
||||
For example see [FunCub QuadPlane](../frames_vtol/vtol_quadplane_fun_cub_vtol_pixhawk.md).
|
||||
|
||||
@@ -0,0 +1,277 @@
|
||||
# dds_topics.yaml — PX4 Topics Exposed to ROS 2
|
||||
|
||||
:::info
|
||||
This document is [auto-generated](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/msg/generate_msg_docs.py) from the source code.
|
||||
:::
|
||||
|
||||
The [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) file specifies which uORB message definitions are compiled into the [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) module when [PX4 is built](../middleware/uxrce_dds.md#code-generation), and hence which topics are available for ROS 2 applications to subscribe or publish (by default).
|
||||
|
||||
This document shows a markdown-rendered version of [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml), listing the publications, subscriptions, and so on.
|
||||
|
||||
## Publications
|
||||
|
||||
| Topic | 형식 | Rate Limit |
|
||||
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- |
|
||||
| `/fmu/out/register_ext_component_reply` | [px4_msgs::msg::RegisterExtComponentReply](../msg_docs/RegisterExtComponentReply.md) | |
|
||||
| `/fmu/out/arming_check_request` | [px4_msgs::msg::ArmingCheckRequest](../msg_docs/ArmingCheckRequest.md) | 5.0 |
|
||||
| `/fmu/out/mode_completed` | [px4_msgs::msg::ModeCompleted](../msg_docs/ModeCompleted.md) | 50.0 |
|
||||
| `/fmu/out/battery_status` | [px4_msgs::msg::BatteryStatus](../msg_docs/BatteryStatus.md) | 1.0 |
|
||||
| `/fmu/out/collision_constraints` | [px4_msgs::msg::CollisionConstraints](../msg_docs/CollisionConstraints.md) | 50.0 |
|
||||
| `/fmu/out/estimator_status_flags` | [px4_msgs::msg::EstimatorStatusFlags](../msg_docs/EstimatorStatusFlags.md) | 5.0 |
|
||||
| `/fmu/out/failsafe_flags` | [px4_msgs::msg::FailsafeFlags](../msg_docs/FailsafeFlags.md) | 5.0 |
|
||||
| `/fmu/out/manual_control_setpoint` | [px4_msgs::msg::ManualControlSetpoint](../msg_docs/ManualControlSetpoint.md) | 25.0 |
|
||||
| `/fmu/out/message_format_response` | [px4_msgs::msg::MessageFormatResponse](../msg_docs/MessageFormatResponse.md) | |
|
||||
| `/fmu/out/position_setpoint_triplet` | [px4_msgs::msg::PositionSetpointTriplet](../msg_docs/PositionSetpointTriplet.md) | 5.0 |
|
||||
| `/fmu/out/sensor_combined` | [px4_msgs::msg::SensorCombined](../msg_docs/SensorCombined.md) | |
|
||||
| `/fmu/out/timesync_status` | [px4_msgs::msg::TimesyncStatus](../msg_docs/TimesyncStatus.md) | 10.0 |
|
||||
| `/fmu/out/vehicle_land_detected` | [px4_msgs::msg::VehicleLandDetected](../msg_docs/VehicleLandDetected.md) | 5.0 |
|
||||
| `/fmu/out/vehicle_attitude` | [px4_msgs::msg::VehicleAttitude](../msg_docs/VehicleAttitude.md) | |
|
||||
| `/fmu/out/vehicle_control_mode` | [px4_msgs::msg::VehicleControlMode](../msg_docs/VehicleControlMode.md) | 50.0 |
|
||||
| `/fmu/out/vehicle_command_ack` | [px4_msgs::msg::VehicleCommandAck](../msg_docs/VehicleCommandAck.md) | |
|
||||
| `/fmu/out/vehicle_global_position` | [px4_msgs::msg::VehicleGlobalPosition](../msg_docs/VehicleGlobalPosition.md) | 50.0 |
|
||||
| `/fmu/out/vehicle_gps_position` | [px4_msgs::msg::SensorGps](../msg_docs/SensorGps.md) | 50.0 |
|
||||
| `/fmu/out/vehicle_local_position` | [px4_msgs::msg::VehicleLocalPosition](../msg_docs/VehicleLocalPosition.md) | 50.0 |
|
||||
| `/fmu/out/vehicle_odometry` | [px4_msgs::msg::VehicleOdometry](../msg_docs/VehicleOdometry.md) | |
|
||||
| `/fmu/out/vehicle_status` | [px4_msgs::msg::VehicleStatus](../msg_docs/VehicleStatus.md) | 5.0 |
|
||||
| `/fmu/out/airspeed_validated` | [px4_msgs::msg::AirspeedValidated](../msg_docs/AirspeedValidated.md) | 50.0 |
|
||||
| `/fmu/out/vtol_vehicle_status` | [px4_msgs::msg::VtolVehicleStatus](../msg_docs/VtolVehicleStatus.md) | |
|
||||
| `/fmu/out/home_position` | [px4_msgs::msg::HomePosition](../msg_docs/HomePosition.md) | 5.0 |
|
||||
|
||||
## Subscriptions
|
||||
|
||||
| Topic | 형식 |
|
||||
| ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| /fmu/in/register_ext_component_request | [px4_msgs::msg::RegisterExtComponentRequest](../msg_docs/RegisterExtComponentRequest.md) |
|
||||
| /fmu/in/unregister_ext_component | [px4_msgs::msg::UnregisterExtComponent](../msg_docs/UnregisterExtComponent.md) |
|
||||
| /fmu/in/config_overrides_request | [px4_msgs::msg::ConfigOverrides](../msg_docs/ConfigOverrides.md) |
|
||||
| /fmu/in/arming_check_reply | [px4_msgs::msg::ArmingCheckReply](../msg_docs/ArmingCheckReply.md) |
|
||||
| /fmu/in/message_format_request | [px4_msgs::msg::MessageFormatRequest](../msg_docs/MessageFormatRequest.md) |
|
||||
| /fmu/in/mode_completed | [px4_msgs::msg::ModeCompleted](../msg_docs/ModeCompleted.md) |
|
||||
| /fmu/in/config_control_setpoints | [px4_msgs::msg::VehicleControlMode](../msg_docs/VehicleControlMode.md) |
|
||||
| /fmu/in/distance_sensor | [px4_msgs::msg::DistanceSensor](../msg_docs/DistanceSensor.md) |
|
||||
| /fmu/in/manual_control_input | [px4_msgs::msg::ManualControlSetpoint](../msg_docs/ManualControlSetpoint.md) |
|
||||
| /fmu/in/offboard_control_mode | [px4_msgs::msg::OffboardControlMode](../msg_docs/OffboardControlMode.md) |
|
||||
| /fmu/in/onboard_computer_status | [px4_msgs::msg::OnboardComputerStatus](../msg_docs/OnboardComputerStatus.md) |
|
||||
| /fmu/in/obstacle_distance | [px4_msgs::msg::ObstacleDistance](../msg_docs/ObstacleDistance.md) |
|
||||
| /fmu/in/sensor_optical_flow | [px4_msgs::msg::SensorOpticalFlow](../msg_docs/SensorOpticalFlow.md) |
|
||||
| /fmu/in/goto_setpoint | [px4_msgs::msg::GotoSetpoint](../msg_docs/GotoSetpoint.md) |
|
||||
| /fmu/in/telemetry_status | [px4_msgs::msg::TelemetryStatus](../msg_docs/TelemetryStatus.md) |
|
||||
| /fmu/in/trajectory_setpoint | [px4_msgs::msg::TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) |
|
||||
| /fmu/in/vehicle_attitude_setpoint | [px4_msgs::msg::VehicleAttitudeSetpoint](../msg_docs/VehicleAttitudeSetpoint.md) |
|
||||
| /fmu/in/vehicle_mocap_odometry | [px4_msgs::msg::VehicleOdometry](../msg_docs/VehicleOdometry.md) |
|
||||
| /fmu/in/vehicle_rates_setpoint | [px4_msgs::msg::VehicleRatesSetpoint](../msg_docs/VehicleRatesSetpoint.md) |
|
||||
| /fmu/in/vehicle_visual_odometry | [px4_msgs::msg::VehicleOdometry](../msg_docs/VehicleOdometry.md) |
|
||||
| /fmu/in/vehicle_command | [px4_msgs::msg::VehicleCommand](../msg_docs/VehicleCommand.md) |
|
||||
| /fmu/in/vehicle_command_mode_executor | [px4_msgs::msg::VehicleCommand](../msg_docs/VehicleCommand.md) |
|
||||
| /fmu/in/vehicle_thrust_setpoint | [px4_msgs::msg::VehicleThrustSetpoint](../msg_docs/VehicleThrustSetpoint.md) |
|
||||
| /fmu/in/vehicle_torque_setpoint | [px4_msgs::msg::VehicleTorqueSetpoint](../msg_docs/VehicleTorqueSetpoint.md) |
|
||||
| /fmu/in/actuator_motors | [px4_msgs::msg::ActuatorMotors](../msg_docs/ActuatorMotors.md) |
|
||||
| /fmu/in/actuator_servos | [px4_msgs::msg::ActuatorServos](../msg_docs/ActuatorServos.md) |
|
||||
| /fmu/in/aux_global_position | [px4_msgs::msg::VehicleGlobalPosition](../msg_docs/VehicleGlobalPosition.md) |
|
||||
| /fmu/in/fixed_wing_longitudinal_setpoint | [px4_msgs::msg::FixedWingLongitudinalSetpoint](../msg_docs/FixedWingLongitudinalSetpoint.md) |
|
||||
| /fmu/in/fixed_wing_lateral_setpoint | [px4_msgs::msg::FixedWingLateralSetpoint](../msg_docs/FixedWingLateralSetpoint.md) |
|
||||
| /fmu/in/longitudinal_control_configuration | [px4_msgs::msg::LongitudinalControlConfiguration](../msg_docs/LongitudinalControlConfiguration.md) |
|
||||
| /fmu/in/lateral_control_configuration | [px4_msgs::msg::LateralControlConfiguration](../msg_docs/LateralControlConfiguration.md) |
|
||||
|
||||
## Subscriptions Multi
|
||||
|
||||
None
|
||||
|
||||
## Not Exported
|
||||
|
||||
These messages are not listed in the yaml file.
|
||||
They are not build into the module, and hence are neither published or subscribed.
|
||||
|
||||
:::details
|
||||
See messages
|
||||
|
||||
- [SensorCorrection](../msg_docs/SensorCorrection.md)
|
||||
- [ActuatorOutputs](../msg_docs/ActuatorOutputs.md)
|
||||
- [FixedWingRunwayControl](../msg_docs/FixedWingRunwayControl.md)
|
||||
- [EstimatorInnovations](../msg_docs/EstimatorInnovations.md)
|
||||
- [FlightPhaseEstimation](../msg_docs/FlightPhaseEstimation.md)
|
||||
- [PurePursuitStatus](../msg_docs/PurePursuitStatus.md)
|
||||
- [Px4ioStatus](../msg_docs/Px4ioStatus.md)
|
||||
- [SatelliteInfo](../msg_docs/SatelliteInfo.md)
|
||||
- [GeofenceResult](../msg_docs/GeofenceResult.md)
|
||||
- [GimbalManagerStatus](../msg_docs/GimbalManagerStatus.md)
|
||||
- [ManualControlSwitches](../msg_docs/ManualControlSwitches.md)
|
||||
- [OpenDroneIdSelfId](../msg_docs/OpenDroneIdSelfId.md)
|
||||
- [OpenDroneIdSystem](../msg_docs/OpenDroneIdSystem.md)
|
||||
- [EventV0](../msg_docs/EventV0.md)
|
||||
- [QshellRetval](../msg_docs/QshellRetval.md)
|
||||
- [RoverThrottleSetpoint](../msg_docs/RoverThrottleSetpoint.md)
|
||||
- [AirspeedValidatedV0](../msg_docs/AirspeedValidatedV0.md)
|
||||
- [RcChannels](../msg_docs/RcChannels.md)
|
||||
- [SensorAccel](../msg_docs/SensorAccel.md)
|
||||
- [GimbalDeviceAttitudeStatus](../msg_docs/GimbalDeviceAttitudeStatus.md)
|
||||
- [EscStatus](../msg_docs/EscStatus.md)
|
||||
- [RoverAttitudeSetpoint](../msg_docs/RoverAttitudeSetpoint.md)
|
||||
- [RateCtrlStatus](../msg_docs/RateCtrlStatus.md)
|
||||
- [AirspeedWind](../msg_docs/AirspeedWind.md)
|
||||
- [InputRc](../msg_docs/InputRc.md)
|
||||
- [GpioIn](../msg_docs/GpioIn.md)
|
||||
- [LaunchDetectionStatus](../msg_docs/LaunchDetectionStatus.md)
|
||||
- [VehicleImu](../msg_docs/VehicleImu.md)
|
||||
- [Event](../msg_docs/Event.md)
|
||||
- [SensorUwb](../msg_docs/SensorUwb.md)
|
||||
- [ActuatorServosTrim](../msg_docs/ActuatorServosTrim.md)
|
||||
- [DatamanResponse](../msg_docs/DatamanResponse.md)
|
||||
- [OrbTest](../msg_docs/OrbTest.md)
|
||||
- [VehicleLocalPositionSetpoint](../msg_docs/VehicleLocalPositionSetpoint.md)
|
||||
- [VehicleAngularVelocity](../msg_docs/VehicleAngularVelocity.md)
|
||||
- [FollowTargetStatus](../msg_docs/FollowTargetStatus.md)
|
||||
- [NormalizedUnsignedSetpoint](../msg_docs/NormalizedUnsignedSetpoint.md)
|
||||
- [YawEstimatorStatus](../msg_docs/YawEstimatorStatus.md)
|
||||
- [TakeoffStatus](../msg_docs/TakeoffStatus.md)
|
||||
- [UlogStreamAck](../msg_docs/UlogStreamAck.md)
|
||||
- [OrbTestLarge](../msg_docs/OrbTestLarge.md)
|
||||
- [RoverSteeringSetpoint](../msg_docs/RoverSteeringSetpoint.md)
|
||||
- [CameraCapture](../msg_docs/CameraCapture.md)
|
||||
- [VehicleRoi](../msg_docs/VehicleRoi.md)
|
||||
- [ActuatorArmed](../msg_docs/ActuatorArmed.md)
|
||||
- [FixedWingLateralGuidanceStatus](../msg_docs/FixedWingLateralGuidanceStatus.md)
|
||||
- [ParameterSetValueResponse](../msg_docs/ParameterSetValueResponse.md)
|
||||
- [GeofenceStatus](../msg_docs/GeofenceStatus.md)
|
||||
- [VehicleAngularAccelerationSetpoint](../msg_docs/VehicleAngularAccelerationSetpoint.md)
|
||||
- [SensorGnssRelative](../msg_docs/SensorGnssRelative.md)
|
||||
- [PowerMonitor](../msg_docs/PowerMonitor.md)
|
||||
- [RoverVelocityStatus](../msg_docs/RoverVelocityStatus.md)
|
||||
- [ParameterResetRequest](../msg_docs/ParameterResetRequest.md)
|
||||
- [RoverAttitudeStatus](../msg_docs/RoverAttitudeStatus.md)
|
||||
- [TecsStatus](../msg_docs/TecsStatus.md)
|
||||
- [EstimatorSelectorStatus](../msg_docs/EstimatorSelectorStatus.md)
|
||||
- [CanInterfaceStatus](../msg_docs/CanInterfaceStatus.md)
|
||||
- [Ping](../msg_docs/Ping.md)
|
||||
- [LedControl](../msg_docs/LedControl.md)
|
||||
- [Wind](../msg_docs/Wind.md)
|
||||
- [VehicleStatusV0](../msg_docs/VehicleStatusV0.md)
|
||||
- [ActuatorTest](../msg_docs/ActuatorTest.md)
|
||||
- [IridiumsbdStatus](../msg_docs/IridiumsbdStatus.md)
|
||||
- [FailureDetectorStatus](../msg_docs/FailureDetectorStatus.md)
|
||||
- [GimbalManagerSetAttitude](../msg_docs/GimbalManagerSetAttitude.md)
|
||||
- [Gripper](../msg_docs/Gripper.md)
|
||||
- [SensorMag](../msg_docs/SensorMag.md)
|
||||
- [DebugValue](../msg_docs/DebugValue.md)
|
||||
- [SensorPreflightMag](../msg_docs/SensorPreflightMag.md)
|
||||
- [RcParameterMap](../msg_docs/RcParameterMap.md)
|
||||
- [LandingGear](../msg_docs/LandingGear.md)
|
||||
- [GimbalDeviceInformation](../msg_docs/GimbalDeviceInformation.md)
|
||||
- [VehicleOpticalFlow](../msg_docs/VehicleOpticalFlow.md)
|
||||
- [UlogStream](../msg_docs/UlogStream.md)
|
||||
- [GimbalControls](../msg_docs/GimbalControls.md)
|
||||
- [RoverRateSetpoint](../msg_docs/RoverRateSetpoint.md)
|
||||
- [LogMessage](../msg_docs/LogMessage.md)
|
||||
- [RoverVelocitySetpoint](../msg_docs/RoverVelocitySetpoint.md)
|
||||
- [GpioOut](../msg_docs/GpioOut.md)
|
||||
- [TaskStackInfo](../msg_docs/TaskStackInfo.md)
|
||||
- [VelocityLimits](../msg_docs/VelocityLimits.md)
|
||||
- [MagWorkerData](../msg_docs/MagWorkerData.md)
|
||||
- [ParameterUpdate](../msg_docs/ParameterUpdate.md)
|
||||
- [TrajectorySetpoint6dof](../msg_docs/TrajectorySetpoint6dof.md)
|
||||
- [SensorBaro](../msg_docs/SensorBaro.md)
|
||||
- [VehicleImuStatus](../msg_docs/VehicleImuStatus.md)
|
||||
- [InternalCombustionEngineStatus](../msg_docs/InternalCombustionEngineStatus.md)
|
||||
- [VehicleOpticalFlowVel](../msg_docs/VehicleOpticalFlowVel.md)
|
||||
- [GimbalManagerSetManualControl](../msg_docs/GimbalManagerSetManualControl.md)
|
||||
- [Rpm](../msg_docs/Rpm.md)
|
||||
- [MagnetometerBiasEstimate](../msg_docs/MagnetometerBiasEstimate.md)
|
||||
- [MountOrientation](../msg_docs/MountOrientation.md)
|
||||
- [ActionRequest](../msg_docs/ActionRequest.md)
|
||||
- [OpenDroneIdArmStatus](../msg_docs/OpenDroneIdArmStatus.md)
|
||||
- [SensorAccelFifo](../msg_docs/SensorAccelFifo.md)
|
||||
- [LoggerStatus](../msg_docs/LoggerStatus.md)
|
||||
- [GeneratorStatus](../msg_docs/GeneratorStatus.md)
|
||||
- [InternalCombustionEngineControl](../msg_docs/InternalCombustionEngineControl.md)
|
||||
- [Ekf2Timestamps](../msg_docs/Ekf2Timestamps.md)
|
||||
- [LandingTargetPose](../msg_docs/LandingTargetPose.md)
|
||||
- [PositionControllerLandingStatus](../msg_docs/PositionControllerLandingStatus.md)
|
||||
- [UavcanParameterValue](../msg_docs/UavcanParameterValue.md)
|
||||
- [OrbitStatus](../msg_docs/OrbitStatus.md)
|
||||
- [PositionControllerStatus](../msg_docs/PositionControllerStatus.md)
|
||||
- [EstimatorStatus](../msg_docs/EstimatorStatus.md)
|
||||
- [DatamanRequest](../msg_docs/DatamanRequest.md)
|
||||
- [HoverThrustEstimate](../msg_docs/HoverThrustEstimate.md)
|
||||
- [FixedWingLateralStatus](../msg_docs/FixedWingLateralStatus.md)
|
||||
- [NavigatorMissionItem](../msg_docs/NavigatorMissionItem.md)
|
||||
- [Cpuload](../msg_docs/Cpuload.md)
|
||||
- [EstimatorAidSource3d](../msg_docs/EstimatorAidSource3d.md)
|
||||
- [RoverRateStatus](../msg_docs/RoverRateStatus.md)
|
||||
- [EscReport](../msg_docs/EscReport.md)
|
||||
- [DebugArray](../msg_docs/DebugArray.md)
|
||||
- [ControlAllocatorStatus](../msg_docs/ControlAllocatorStatus.md)
|
||||
- [SensorHygrometer](../msg_docs/SensorHygrometer.md)
|
||||
- [EstimatorSensorBias](../msg_docs/EstimatorSensorBias.md)
|
||||
- [EstimatorBias3d](../msg_docs/EstimatorBias3d.md)
|
||||
- [GimbalManagerInformation](../msg_docs/GimbalManagerInformation.md)
|
||||
- [QshellReq](../msg_docs/QshellReq.md)
|
||||
- [CameraStatus](../msg_docs/CameraStatus.md)
|
||||
- [GpsInjectData](../msg_docs/GpsInjectData.md)
|
||||
- [FigureEightStatus](../msg_docs/FigureEightStatus.md)
|
||||
- [TransponderReport](../msg_docs/TransponderReport.md)
|
||||
- [UavcanParameterRequest](../msg_docs/UavcanParameterRequest.md)
|
||||
- [MavlinkLog](../msg_docs/MavlinkLog.md)
|
||||
- [EstimatorGpsStatus](../msg_docs/EstimatorGpsStatus.md)
|
||||
- [FuelTankStatus](../msg_docs/FuelTankStatus.md)
|
||||
- [Mission](../msg_docs/Mission.md)
|
||||
- [PositionSetpoint](../msg_docs/PositionSetpoint.md)
|
||||
- [MissionResult](../msg_docs/MissionResult.md)
|
||||
- [EstimatorEventFlags](../msg_docs/EstimatorEventFlags.md)
|
||||
- [VehicleMagnetometer](../msg_docs/VehicleMagnetometer.md)
|
||||
- [MavlinkTunnel](../msg_docs/MavlinkTunnel.md)
|
||||
- [DifferentialPressure](../msg_docs/DifferentialPressure.md)
|
||||
- [CellularStatus](../msg_docs/CellularStatus.md)
|
||||
- [GpsDump](../msg_docs/GpsDump.md)
|
||||
- [GimbalDeviceSetAttitude](../msg_docs/GimbalDeviceSetAttitude.md)
|
||||
- [ArmingCheckReplyV0](../msg_docs/ArmingCheckReplyV0.md)
|
||||
- [NavigatorStatus](../msg_docs/NavigatorStatus.md)
|
||||
- [RoverPositionSetpoint](../msg_docs/RoverPositionSetpoint.md)
|
||||
- [FollowTarget](../msg_docs/FollowTarget.md)
|
||||
- [SensorsStatusImu](../msg_docs/SensorsStatusImu.md)
|
||||
- [EstimatorStates](../msg_docs/EstimatorStates.md)
|
||||
- [SensorGyro](../msg_docs/SensorGyro.md)
|
||||
- [SensorAirflow](../msg_docs/SensorAirflow.md)
|
||||
- [ButtonEvent](../msg_docs/ButtonEvent.md)
|
||||
- [DebugKeyValue](../msg_docs/DebugKeyValue.md)
|
||||
- [GpioConfig](../msg_docs/GpioConfig.md)
|
||||
- [CameraTrigger](../msg_docs/CameraTrigger.md)
|
||||
- [LandingGearWheel](../msg_docs/LandingGearWheel.md)
|
||||
- [VehicleConstraints](../msg_docs/VehicleConstraints.md)
|
||||
- [HealthReport](../msg_docs/HealthReport.md)
|
||||
- [PowerButtonState](../msg_docs/PowerButtonState.md)
|
||||
- [RadioStatus](../msg_docs/RadioStatus.md)
|
||||
- [SensorGyroFifo](../msg_docs/SensorGyroFifo.md)
|
||||
- [EstimatorBias](../msg_docs/EstimatorBias.md)
|
||||
- [DebugVect](../msg_docs/DebugVect.md)
|
||||
- [DistanceSensorModeChangeRequest](../msg_docs/DistanceSensorModeChangeRequest.md)
|
||||
- [RtlTimeEstimate](../msg_docs/RtlTimeEstimate.md)
|
||||
- [PpsCapture](../msg_docs/PpsCapture.md)
|
||||
- [SensorSelection](../msg_docs/SensorSelection.md)
|
||||
- [SystemPower](../msg_docs/SystemPower.md)
|
||||
- [ActuatorControlsStatus](../msg_docs/ActuatorControlsStatus.md)
|
||||
- [SensorGyroFft](../msg_docs/SensorGyroFft.md)
|
||||
- [VehicleAirData](../msg_docs/VehicleAirData.md)
|
||||
- [FollowTargetEstimator](../msg_docs/FollowTargetEstimator.md)
|
||||
- [ParameterSetUsedRequest](../msg_docs/ParameterSetUsedRequest.md)
|
||||
- [GpioRequest](../msg_docs/GpioRequest.md)
|
||||
- [OpenDroneIdOperatorId](../msg_docs/OpenDroneIdOperatorId.md)
|
||||
- [RtlStatus](../msg_docs/RtlStatus.md)
|
||||
- [Airspeed](../msg_docs/Airspeed.md)
|
||||
- [VehicleAcceleration](../msg_docs/VehicleAcceleration.md)
|
||||
- [ParameterSetValueRequest](../msg_docs/ParameterSetValueRequest.md)
|
||||
- [IrlockReport](../msg_docs/IrlockReport.md)
|
||||
- [HeaterStatus](../msg_docs/HeaterStatus.md)
|
||||
- [AdcReport](../msg_docs/AdcReport.md)
|
||||
- [PwmInput](../msg_docs/PwmInput.md)
|
||||
- [TiltrotorExtraControls](../msg_docs/TiltrotorExtraControls.md)
|
||||
- [EstimatorAidSource1d](../msg_docs/EstimatorAidSource1d.md)
|
||||
- [OrbTestMedium](../msg_docs/OrbTestMedium.md)
|
||||
- [VehicleAttitudeSetpointV0](../msg_docs/VehicleAttitudeSetpointV0.md)
|
||||
- [EstimatorAidSource2d](../msg_docs/EstimatorAidSource2d.md)
|
||||
- [TuneControl](../msg_docs/TuneControl.md)
|
||||
- [WheelEncoders](../msg_docs/WheelEncoders.md)
|
||||
- [AutotuneAttitudeControlStatus](../msg_docs/AutotuneAttitudeControlStatus.md)
|
||||
- [LandingTargetInnovations](../msg_docs/LandingTargetInnovations.md)
|
||||
- [SensorsStatus](../msg_docs/SensorsStatus.md)
|
||||
|
||||
:::
|
||||
@@ -38,7 +38,7 @@ The PX4 [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) is gen
|
||||
The agent has no dependency on client code.
|
||||
It can be built standalone or in a ROS 2 workspace, or installed as a snap package on Ubuntu.
|
||||
|
||||
When PX4 is built, a code generator uses the uORB message definitions in the source tree ([PX4-Autopilot/msg](https://github.com/PX4/PX4-Autopilot/tree/main/msg)) to compile support for the subset of uORB topics in [PX4-Autopilot/src/modules/uxrce_dds_client/dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) into [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client).
|
||||
When PX4 is built, a code generator uses the uORB message definitions in the source tree ([PX4-Autopilot/msg](https://github.com/PX4/PX4-Autopilot/tree/main/msg)) to compile support for the subset of uORB topics in [/src/modules/uxrce_dds_client/dds_topics.yaml](../middleware/dds_topics.md) into [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client).
|
||||
|
||||
PX4 main or release builds automatically export the set of uORB messages definitions in the build to an associated branch in [PX4/px4_msgs](https://github.com/PX4/px4_msgs).
|
||||
|
||||
@@ -326,13 +326,11 @@ ROS_DOMAIN_ID=3 PX4_UXRCE_DDS_PORT=9999 PX4_UXRCE_DDS_NS=drone make px4_sitl gz_
|
||||
|
||||
## Supported uORB Messages
|
||||
|
||||
The set of [PX4 uORB topics](../msg_docs/index.md) that are exposed through the client are set in [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml).
|
||||
The set of [PX4 uORB topics](../msg_docs/index.md) that are exposed through the client are set in [dds_topics.yaml](../middleware/dds_topics.md).
|
||||
|
||||
The topics are release specific (support is compiled into [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) at build time).
|
||||
While most releases should support a very similar set of messages, to be certain you would need to check the yaml file for your particular release.
|
||||
|
||||
<!-- Jublish the set we use?: https://github.com/PX4/px4_msgs/issues/22 -->
|
||||
|
||||
Note that ROS 2/DDS needs to have the _same_ message definitions that were used to create the uXRCE-DDS client module in the PX4 Firmware in order to interpret the messages.
|
||||
The message definitions are stored in the ROS 2 interface package [PX4/px4_msgs](https://github.com/PX4/px4_msgs), and they are automatically synchronized by CI on the `main` and release branches.
|
||||
Note that all the messages from PX4 source code are present in the repository, but only those listed in `dds_topics.yaml` will be available as ROS 2 topics.
|
||||
@@ -349,21 +347,21 @@ Therefore,
|
||||
```
|
||||
|
||||
::: info
|
||||
Technically, [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) completely defines the relationship between PX4 uORB topics and ROS 2 messages.
|
||||
Technically, [dds_topics.yaml](../middleware/dds_topics.md) completely defines the relationship between PX4 uORB topics and ROS 2 messages.
|
||||
For more information see [DDS Topics YAML](#dds-topics-yaml) below.
|
||||
|
||||
:::
|
||||
|
||||
## Customizing the Namespace
|
||||
|
||||
Custom topic and service namespaces can be applied at build time (changing [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml)) or at runtime (which is useful for multi vehicle operations):
|
||||
Custom topic and service namespaces can be applied at build time (changing [dds_topics.yaml](../middleware/dds_topics.md)) or at runtime (which is useful for multi vehicle operations):
|
||||
|
||||
- One possibility is to use the `-n` option when starting the [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) from command line.
|
||||
This technique can be used both in simulation and real vehicles.
|
||||
- A custom namespace can be provided for simulations (only) by setting the environment variable `PX4_UXRCE_DDS_NS` before starting the simulation.
|
||||
|
||||
:::info
|
||||
Changing the namespace at runtime will append the desired namespace as a prefix to all `topic` fields in [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) and all [service servers](#dds-ros-2-services).
|
||||
Changing the namespace at runtime will append the desired namespace as a prefix to all `topic` fields in [dds_topics.yaml](../middleware/dds_topics.md) and all [service servers](#dds-ros-2-services).
|
||||
Therefore, commands like:
|
||||
|
||||
```sh
|
||||
@@ -420,7 +418,7 @@ Deadline, lifespan, and lease durations are also all set to "default".
|
||||
|
||||
## DDS Topics YAML
|
||||
|
||||
The PX4 yaml file [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) defines the set of PX4 uORB topics that are built into firmware and published.
|
||||
The PX4 [dds_topics.yaml](../middleware/dds_topics.md) file defines the set of PX4 uORB topics that are built into firmware and published.
|
||||
More precisely, it completely defines the relationship/pairing between PX4 uORB and ROS 2 messages.
|
||||
|
||||
The file is structured as follows:
|
||||
@@ -549,7 +547,7 @@ Take a look at the [client startup section](#starting-the-client) to learn how t
|
||||
|
||||
#### New file for setting which topics are published
|
||||
|
||||
The list of topics that are published and subscribed for a particular firmware is now managed by the [dds_topic.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) configuration file, which replaces [urtps_bridge_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/release/1.13/msg/tools/urtps_bridge_topics.yaml)
|
||||
The list of topics that are published and subscribed for a particular firmware is now managed by the [dds_topics.yaml](../middleware/dds_topics.md) configuration file, which replaces [urtps_bridge_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/release/1.13/msg/tools/urtps_bridge_topics.yaml)
|
||||
|
||||
See [Supported uORB Messages](#supported-uorb-messages) and [DDS Topics YAML](#dds-topics-yaml) sections for more information.
|
||||
|
||||
|
||||
+119
-119
@@ -29,151 +29,151 @@ This consists of a single _C_ file and a _cmake_ definition (which tells the too
|
||||
|
||||
2. Create a new C file in that directory named **px4_simple_app.c**:
|
||||
|
||||
- 기본 헤더를 페이지 상단에 복사합니다.
|
||||
이것은 기여한 모든 파일에 첨부하여야 합니다.
|
||||
- 기본 헤더를 페이지 상단에 복사합니다.
|
||||
이것은 기여한 모든 파일에 첨부하여야 합니다.
|
||||
|
||||
```c
|
||||
/****************************************************************************
|
||||
*
|
||||
* Copyright (c) 2012-2022 PX4 Development Team. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
*
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in
|
||||
* the documentation and/or other materials provided with the
|
||||
* distribution.
|
||||
* 3. Neither the name PX4 nor the names of its contributors may be
|
||||
* used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
* POSSIBILITY OF SUCH DAMAGE.
|
||||
*
|
||||
****************************************************************************/
|
||||
```
|
||||
```c
|
||||
/****************************************************************************
|
||||
*
|
||||
* Copyright (c) 2012-2022 PX4 Development Team. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
*
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in
|
||||
* the documentation and/or other materials provided with the
|
||||
* distribution.
|
||||
* 3. Neither the name PX4 nor the names of its contributors may be
|
||||
* used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
* POSSIBILITY OF SUCH DAMAGE.
|
||||
*
|
||||
****************************************************************************/
|
||||
```
|
||||
|
||||
- 기본 헤더 아래에 다음 코드를 복사합니다.
|
||||
이것은 기여한 모든 파일에 첨부하여야 합니다.
|
||||
- 기본 헤더 아래에 다음 코드를 복사합니다.
|
||||
이것은 기여한 모든 파일에 첨부하여야 합니다.
|
||||
|
||||
```c
|
||||
/**
|
||||
* @file px4_simple_app.c
|
||||
* Minimal application example for PX4 autopilot
|
||||
*
|
||||
* @author Example User <mail@example.com>
|
||||
*/
|
||||
```c
|
||||
/**
|
||||
* @file px4_simple_app.c
|
||||
* Minimal application example for PX4 autopilot
|
||||
*
|
||||
* @author Example User <mail@example.com>
|
||||
*/
|
||||
|
||||
#include <px4_platform_common/log.h>
|
||||
#include <px4_platform_common/log.h>
|
||||
|
||||
__EXPORT int px4_simple_app_main(int argc, char *argv[]);
|
||||
__EXPORT int px4_simple_app_main(int argc, char *argv[]);
|
||||
|
||||
int px4_simple_app_main(int argc, char *argv[])
|
||||
{
|
||||
PX4_INFO("Hello Sky!");
|
||||
return OK;
|
||||
}
|
||||
```
|
||||
int px4_simple_app_main(int argc, char *argv[])
|
||||
{
|
||||
PX4_INFO("Hello Sky!");
|
||||
return OK;
|
||||
}
|
||||
```
|
||||
|
||||
:::tip
|
||||
The main function must be named `<module_name>_main` and exported from the module as shown.
|
||||
:::tip
|
||||
The main function must be named `<module_name>_main` and exported from the module as shown.
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
`PX4_INFO` is the equivalent of `printf` for the PX4 shell (included from **px4_platform_common/log.h**).
|
||||
There are different log levels: `PX4_INFO`, `PX4_WARN`, `PX4_ERR`, `PX4_DEBUG`.
|
||||
Warnings and errors are additionally added to the [ULog](../dev_log/ulog_file_format.md) and shown on [Flight Review](https://logs.px4.io/).
|
||||
:::tip
|
||||
`PX4_INFO` is the equivalent of `printf` for the PX4 shell (included from **px4_platform_common/log.h**).
|
||||
There are different log levels: `PX4_INFO`, `PX4_WARN`, `PX4_ERR`, `PX4_DEBUG`.
|
||||
Warnings and errors are additionally added to the [ULog](../dev_log/ulog_file_format.md) and shown on [Flight Review](https://logs.px4.io/).
|
||||
|
||||
:::
|
||||
|
||||
3. Create and open a new _cmake_ definition file named **CMakeLists.txt**.
|
||||
아래 텍스트를 복사하십시오.
|
||||
아래 텍스트를 복사하십시오.
|
||||
|
||||
```cmake
|
||||
############################################################################
|
||||
#
|
||||
# Copyright (c) 2015 PX4 Development Team. All rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or without
|
||||
# modification, are permitted provided that the following conditions
|
||||
# are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above copyright
|
||||
# notice, this list of conditions and the following disclaimer in
|
||||
# the documentation and/or other materials provided with the
|
||||
# distribution.
|
||||
# 3. Neither the name PX4 nor the names of its contributors may be
|
||||
# used to endorse or promote products derived from this software
|
||||
# without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
# POSSIBILITY OF SUCH DAMAGE.
|
||||
#
|
||||
############################################################################
|
||||
px4_add_module(
|
||||
MODULE examples__px4_simple_app
|
||||
MAIN px4_simple_app
|
||||
STACK_MAIN 2000
|
||||
SRCS
|
||||
px4_simple_app.c
|
||||
DEPENDS
|
||||
)
|
||||
```
|
||||
```cmake
|
||||
############################################################################
|
||||
#
|
||||
# Copyright (c) 2015 PX4 Development Team. All rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or without
|
||||
# modification, are permitted provided that the following conditions
|
||||
# are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above copyright
|
||||
# notice, this list of conditions and the following disclaimer in
|
||||
# the documentation and/or other materials provided with the
|
||||
# distribution.
|
||||
# 3. Neither the name PX4 nor the names of its contributors may be
|
||||
# used to endorse or promote products derived from this software
|
||||
# without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
# POSSIBILITY OF SUCH DAMAGE.
|
||||
#
|
||||
############################################################################
|
||||
px4_add_module(
|
||||
MODULE examples__px4_simple_app
|
||||
MAIN px4_simple_app
|
||||
STACK_MAIN 2000
|
||||
SRCS
|
||||
px4_simple_app.c
|
||||
DEPENDS
|
||||
)
|
||||
```
|
||||
|
||||
The `px4_add_module()` method builds a static library from a module description.
|
||||
The `px4_add_module()` method builds a static library from a module description.
|
||||
|
||||
- The `MODULE` block is the Firmware-unique name of the module (by convention the module name is prefixed by parent directories back to `src`).
|
||||
- The `MAIN` block lists the entry point of the module, which registers the command with NuttX so that it can be called from the PX4 shell or SITL console.
|
||||
- The `MODULE` block is the Firmware-unique name of the module (by convention the module name is prefixed by parent directories back to `src`).
|
||||
- The `MAIN` block lists the entry point of the module, which registers the command with NuttX so that it can be called from the PX4 shell or SITL console.
|
||||
|
||||
:::tip
|
||||
The `px4_add_module()` format is documented in [PX4-Autopilot/cmake/px4_add_module.cmake](https://github.com/PX4/PX4-Autopilot/blob/main/cmake/px4_add_module.cmake). <!-- NEED px4_version -->
|
||||
:::tip
|
||||
The `px4_add_module()` format is documented in [PX4-Autopilot/cmake/px4_add_module.cmake](https://github.com/PX4/PX4-Autopilot/blob/main/cmake/px4_add_module.cmake). <!-- NEED px4_version -->
|
||||
|
||||
:::
|
||||
|
||||
::: info
|
||||
If you specify `DYNAMIC` as an option to `px4_add_module`, a _shared library_ is created instead of a static library on POSIX platforms (these can be loaded without having to recompile PX4, and shared to others as binaries rather than source code).
|
||||
Your app will not become a builtin command, but ends up in a separate file called `examples__px4_simple_app.px4mod`.
|
||||
You can then run your command by loading the file at runtime using the `dyn` command: `dyn ./examples__px4_simple_app.px4mod`
|
||||
::: info
|
||||
If you specify `DYNAMIC` as an option to `px4_add_module`, a _shared library_ is created instead of a static library on POSIX platforms (these can be loaded without having to recompile PX4, and shared to others as binaries rather than source code).
|
||||
Your app will not become a builtin command, but ends up in a separate file called `examples__px4_simple_app.px4mod`.
|
||||
You can then run your command by loading the file at runtime using the `dyn` command: `dyn ./examples__px4_simple_app.px4mod`
|
||||
|
||||
:::
|
||||
|
||||
4. Create and open a new _Kconfig_ definition file named **Kconfig** and define your symbol for naming (see [Kconfig naming convention](../hardware/porting_guide_config.md#px4-kconfig-symbol-naming-convention)).
|
||||
아래 텍스트를 복사하십시오.
|
||||
아래 텍스트를 복사하십시오.
|
||||
|
||||
```
|
||||
menuconfig EXAMPLES_PX4_SIMPLE_APP
|
||||
bool "px4_simple_app"
|
||||
default n
|
||||
---help---
|
||||
Enable support for px4_simple_app
|
||||
```
|
||||
```
|
||||
menuconfig EXAMPLES_PX4_SIMPLE_APP
|
||||
bool "px4_simple_app"
|
||||
default n
|
||||
---help---
|
||||
Enable support for px4_simple_app
|
||||
```
|
||||
|
||||
## 애플리케이션/펌웨어 빌드
|
||||
|
||||
|
||||
@@ -347,7 +347,7 @@ CONFIG_DRIVERS_RPM_CAPTURE=y
|
||||
Additionally, to enable the module:
|
||||
|
||||
- Set [ICE_EN](../advanced_config/parameter_reference.md#ICE_EN)
|
||||
to true and adjust the other `ICE_` module parameters according to your needs.
|
||||
to true and adjust the other `ICE_` module parameters according to your needs.
|
||||
- Set [RPM_CAP_ENABLE](../advanced_config/parameter_reference.md#RPM_CAP_ENABLE) to true.
|
||||
|
||||
The module outputs control signals for ignition, throttle, and choke,
|
||||
@@ -367,8 +367,8 @@ The state machine:
|
||||
|
||||
- Checks if [Rpm.msg](../msg_docs/Rpm.md) is updated to know if the engine is running
|
||||
- Allows for user inputs from:
|
||||
- AUX{N}
|
||||
- Arming state in [VehicleStatus.msg](../msg_docs/VehicleStatus.md)
|
||||
- AUX{N}
|
||||
- Arming state in [VehicleStatus.msg](../msg_docs/VehicleStatus.md)
|
||||
|
||||
The module publishes [InternalCombustionEngineControl.msg](../msg_docs/InternalCombustionEngineControl.md).
|
||||
|
||||
@@ -484,7 +484,7 @@ The normal log is always a superset of the mission log.
|
||||
The implementation uses two threads:
|
||||
|
||||
- The main thread, running at a fixed rate (or polling on a topic if started with -p) and checking for
|
||||
data updates
|
||||
data updates
|
||||
- The writer thread, writing data to the file
|
||||
|
||||
In between there is a write buffer with configurable size (and another fixed-size buffer for
|
||||
@@ -688,9 +688,9 @@ There are 2 environment variables used for configuration: `replay`, which must b
|
||||
the log file to be replayed. The second is the mode, specified via `replay_mode`:
|
||||
|
||||
- `replay_mode=ekf2`: specific EKF2 replay mode. It can only be used with the ekf2 module, but allows the replay
|
||||
to run as fast as possible.
|
||||
to run as fast as possible.
|
||||
- Generic otherwise: this can be used to replay any module(s), but the replay will be done with the same speed as the
|
||||
log was recorded.
|
||||
log was recorded.
|
||||
|
||||
The module is typically used together with uORB publisher rules, to specify which messages should be replayed.
|
||||
The replay module will just publish all messages that are found in the log. It also applies the parameters from
|
||||
@@ -842,12 +842,12 @@ it into a more usable form, and publishes it for the rest of the system.
|
||||
The provided functionality includes:
|
||||
|
||||
- Read the output from the sensor drivers (`SensorGyro`, etc.).
|
||||
If there are multiple of the same type, do voting and failover handling.
|
||||
Then apply the board rotation and temperature calibration (if enabled). And finally publish the data; one of the
|
||||
topics is `SensorCombined`, used by many parts of the system.
|
||||
If there are multiple of the same type, do voting and failover handling.
|
||||
Then apply the board rotation and temperature calibration (if enabled). And finally publish the data; one of the
|
||||
topics is `SensorCombined`, used by many parts of the system.
|
||||
- Make sure the sensor drivers get the updated calibration parameters (scale & offset) when the parameters change or
|
||||
on startup. The sensor drivers use the ioctl interface for parameter updates. For this to work properly, the
|
||||
sensor drivers must already be running when `sensors` is started.
|
||||
on startup. The sensor drivers use the ioctl interface for parameter updates. For this to work properly, the
|
||||
sensor drivers must already be running when `sensors` is started.
|
||||
- Do sensor consistency checks and publish the `SensorsStatusImu` topic.
|
||||
|
||||
### 구현
|
||||
|
||||
@@ -25,38 +25,38 @@ Other examples in Python can be found here: [integrationtests/python_src/px4_it/
|
||||
|
||||
1. Open the terminal and go to `~/catkin_ws/src` directory
|
||||
|
||||
```sh
|
||||
roscd # Should cd into ~/catkin_ws/devel
|
||||
cd ..
|
||||
cd src
|
||||
```
|
||||
```sh
|
||||
roscd # Should cd into ~/catkin_ws/devel
|
||||
cd ..
|
||||
cd src
|
||||
```
|
||||
|
||||
2. In the `~/catkin_ws/src` directory create a new package named `offboard_py` (in this case) with the `rospy` dependency:
|
||||
|
||||
```sh
|
||||
catkin_create_pkg offboard_py rospy
|
||||
```
|
||||
```sh
|
||||
catkin_create_pkg offboard_py rospy
|
||||
```
|
||||
|
||||
3. Build the new package in the `~/catkin_ws/` directory:
|
||||
|
||||
```sh
|
||||
cd .. # Assuming previous directory to be ~/catkin_ws/src
|
||||
catkin build
|
||||
source devel/setup.bash
|
||||
```
|
||||
```sh
|
||||
cd .. # Assuming previous directory to be ~/catkin_ws/src
|
||||
catkin build
|
||||
source devel/setup.bash
|
||||
```
|
||||
|
||||
4. You should now be able to cd into the package by using:
|
||||
|
||||
```sh
|
||||
roscd offboard_py
|
||||
```
|
||||
```sh
|
||||
roscd offboard_py
|
||||
```
|
||||
|
||||
5. To store your Python files, create a new folder called `/scripts` on the package:
|
||||
|
||||
```sh
|
||||
mkdir scripts
|
||||
cd scripts
|
||||
```
|
||||
```sh
|
||||
mkdir scripts
|
||||
cd scripts
|
||||
```
|
||||
|
||||
## 코드
|
||||
|
||||
|
||||
@@ -37,63 +37,63 @@ To build and run the example:
|
||||
|
||||
2. Create and navigate into a new colcon workspace directory using:
|
||||
|
||||
```sh
|
||||
mkdir -p ~/ws_offboard_control/src/
|
||||
cd ~/ws_offboard_control/src/
|
||||
```
|
||||
```sh
|
||||
mkdir -p ~/ws_offboard_control/src/
|
||||
cd ~/ws_offboard_control/src/
|
||||
```
|
||||
|
||||
3. Clone the [px4_msgs](https://github.com/PX4/px4_msgs) repo to the `/src` directory (this repo is needed in every ROS 2 PX4 workspace!):
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
# checkout the matching release branch if not using PX4 main.
|
||||
```
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
# checkout the matching release branch if not using PX4 main.
|
||||
```
|
||||
|
||||
4. Clone the example repository [px4_ros_com](https://github.com/PX4/px4_ros_com) to the `/src` directory:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
|
||||
5. Source the ROS 2 development environment into the current terminal and compile the workspace using `colcon`:
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
::: tab humble
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
::: tab foxy
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
6. Source the `local_setup.bash`:
|
||||
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
|
||||
7. Launch the example.
|
||||
|
||||
```
|
||||
ros2 run px4_ros_com offboard_control
|
||||
```
|
||||
```
|
||||
ros2 run px4_ros_com offboard_control
|
||||
```
|
||||
|
||||
The vehicle should arm, ascend 5 metres, and then wait (perpetually).
|
||||
|
||||
|
||||
+140
-140
@@ -28,7 +28,7 @@ The agent acts as a proxy for the client to publish and subscribe to topics in t
|
||||
|
||||
The PX4 [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) is generated at build time and included in PX4 firmware by default.
|
||||
It includes both the "generic" micro XRCE-DDS client code, and PX4-specific translation code that it uses to publish to/from uORB topics.
|
||||
The subset of uORB messages that are generated into the client are listed in [PX4-Autopilot/src/modules/uxrce_dds_client/dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml).
|
||||
The subset of uORB messages that are generated into the client are specified in [dds_topics.yaml](../middleware/dds_topics.md).
|
||||
The generator uses the uORB message definitions in the source tree: [PX4-Autopilot/msg](https://github.com/PX4/PX4-Autopilot/tree/main/msg) to create the code for sending ROS 2 messages.
|
||||
|
||||
ROS 2 applications need to be built in a workspace that has the _same_ message definitions that were used to create the uXRCE-DDS client module in the PX4 Firmware.
|
||||
@@ -97,48 +97,48 @@ To install ROS 2 and its dependencies:
|
||||
|
||||
1. Install ROS 2.
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
To install ROS 2 "Humble" on Ubuntu 22.04:
|
||||
::: tab humble
|
||||
To install ROS 2 "Humble" on Ubuntu 22.04:
|
||||
|
||||
```sh
|
||||
sudo apt update && sudo apt install locales
|
||||
sudo locale-gen en_US en_US.UTF-8
|
||||
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
|
||||
export LANG=en_US.UTF-8
|
||||
sudo apt install software-properties-common
|
||||
sudo add-apt-repository universe
|
||||
sudo apt update && sudo apt install curl -y
|
||||
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg
|
||||
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null
|
||||
sudo apt update && sudo apt upgrade -y
|
||||
sudo apt install ros-humble-desktop
|
||||
sudo apt install ros-dev-tools
|
||||
source /opt/ros/humble/setup.bash && echo "source /opt/ros/humble/setup.bash" >> .bashrc
|
||||
```
|
||||
```sh
|
||||
sudo apt update && sudo apt install locales
|
||||
sudo locale-gen en_US en_US.UTF-8
|
||||
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
|
||||
export LANG=en_US.UTF-8
|
||||
sudo apt install software-properties-common
|
||||
sudo add-apt-repository universe
|
||||
sudo apt update && sudo apt install curl -y
|
||||
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg
|
||||
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null
|
||||
sudo apt update && sudo apt upgrade -y
|
||||
sudo apt install ros-humble-desktop
|
||||
sudo apt install ros-dev-tools
|
||||
source /opt/ros/humble/setup.bash && echo "source /opt/ros/humble/setup.bash" >> .bashrc
|
||||
```
|
||||
|
||||
The instructions above are reproduced from the official installation guide: [Install ROS 2 Humble](https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians.html).
|
||||
You can install _either_ the desktop (`ros-humble-desktop`) _or_ bare-bones versions (`ros-humble-ros-base`), _and_ the development tools (`ros-dev-tools`).
|
||||
The instructions above are reproduced from the official installation guide: [Install ROS 2 Humble](https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians.html).
|
||||
You can install _either_ the desktop (`ros-humble-desktop`) _or_ bare-bones versions (`ros-humble-ros-base`), _and_ the development tools (`ros-dev-tools`).
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
To install ROS 2 "Foxy" on Ubuntu 20.04:
|
||||
::: tab foxy
|
||||
To install ROS 2 "Foxy" on Ubuntu 20.04:
|
||||
|
||||
- Follow the official installation guide: [Install ROS 2 Foxy](https://docs.ros.org/en/foxy/Installation/Ubuntu-Install-Debians.html).
|
||||
- Follow the official installation guide: [Install ROS 2 Foxy](https://docs.ros.org/en/foxy/Installation/Ubuntu-Install-Debians.html).
|
||||
|
||||
You can install _either_ the desktop (`ros-foxy-desktop`) _or_ bare-bones versions (`ros-foxy-ros-base`), _and_ the development tools (`ros-dev-tools`).
|
||||
You can install _either_ the desktop (`ros-foxy-desktop`) _or_ bare-bones versions (`ros-foxy-ros-base`), _and_ the development tools (`ros-dev-tools`).
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
2. Some Python dependencies must also be installed (using **`pip`** or **`apt`**):
|
||||
|
||||
```sh
|
||||
pip install --user -U empy==3.3.4 pyros-genmsg setuptools
|
||||
```
|
||||
```sh
|
||||
pip install --user -U empy==3.3.4 pyros-genmsg setuptools
|
||||
```
|
||||
|
||||
### Setup Micro XRCE-DDS Agent & Client
|
||||
|
||||
@@ -155,22 +155,22 @@ To setup and start the agent:
|
||||
|
||||
2. Enter the following commands to fetch and build the agent from source:
|
||||
|
||||
```sh
|
||||
git clone -b v2.4.2 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
|
||||
cd Micro-XRCE-DDS-Agent
|
||||
mkdir build
|
||||
cd build
|
||||
cmake ..
|
||||
make
|
||||
sudo make install
|
||||
sudo ldconfig /usr/local/lib/
|
||||
```
|
||||
```sh
|
||||
git clone -b v2.4.2 https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
|
||||
cd Micro-XRCE-DDS-Agent
|
||||
mkdir build
|
||||
cd build
|
||||
cmake ..
|
||||
make
|
||||
sudo make install
|
||||
sudo ldconfig /usr/local/lib/
|
||||
```
|
||||
|
||||
3. Start the agent with settings for connecting to the uXRCE-DDS client running on the simulator:
|
||||
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
|
||||
The agent is now running, but you won't see much until we start PX4 (in the next step).
|
||||
|
||||
@@ -187,31 +187,31 @@ To start the simulator (and client):
|
||||
|
||||
1. Open a new terminal in the root of the **PX4 Autopilot** repo that was installed above.
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
::: tab humble
|
||||
|
||||
- Start a PX4 [Gazebo](../sim_gazebo_gz/index.md) simulation using:
|
||||
- Start a PX4 [Gazebo](../sim_gazebo_gz/index.md) simulation using:
|
||||
|
||||
```sh
|
||||
make px4_sitl gz_x500
|
||||
```
|
||||
```sh
|
||||
make px4_sitl gz_x500
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
::: tab foxy
|
||||
|
||||
- Start a PX4 [Gazebo Classic](../sim_gazebo_classic/index.md) simulation using:
|
||||
- Start a PX4 [Gazebo Classic](../sim_gazebo_classic/index.md) simulation using:
|
||||
|
||||
```sh
|
||||
make px4_sitl gazebo-classic
|
||||
```
|
||||
```sh
|
||||
make px4_sitl gazebo-classic
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
The agent and client are now running they should connect.
|
||||
|
||||
@@ -261,52 +261,52 @@ To create and build the workspace:
|
||||
|
||||
2. Create and navigate into a new workspace directory using:
|
||||
|
||||
```sh
|
||||
mkdir -p ~/ws_sensor_combined/src/
|
||||
cd ~/ws_sensor_combined/src/
|
||||
```
|
||||
```sh
|
||||
mkdir -p ~/ws_sensor_combined/src/
|
||||
cd ~/ws_sensor_combined/src/
|
||||
```
|
||||
|
||||
::: info
|
||||
A naming convention for workspace folders can make it easier to manage workspaces.
|
||||
::: info
|
||||
A naming convention for workspace folders can make it easier to manage workspaces.
|
||||
|
||||
:::
|
||||
|
||||
3. Clone the example repository and [px4_msgs](https://github.com/PX4/px4_msgs) to the `/src` directory (the `main` branch is cloned by default, which corresponds to the version of PX4 we are running):
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
|
||||
4. Source the ROS 2 development environment into the current terminal and compile the workspace using `colcon`:
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
::: tab humble
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
::: tab foxy
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
This builds all the folders under `/src` using the sourced toolchain.
|
||||
This builds all the folders under `/src` using the sourced toolchain.
|
||||
|
||||
#### Running the Example
|
||||
|
||||
@@ -322,42 +322,42 @@ In a new terminal:
|
||||
|
||||
1. Navigate into the top level of your workspace directory and source the ROS 2 environment (in this case "Humble"):
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
::: tab humble
|
||||
|
||||
```sh
|
||||
cd ~/ws_sensor_combined/
|
||||
source /opt/ros/humble/setup.bash
|
||||
```
|
||||
```sh
|
||||
cd ~/ws_sensor_combined/
|
||||
source /opt/ros/humble/setup.bash
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
::: tab foxy
|
||||
|
||||
```sh
|
||||
cd ~/ws_sensor_combined/
|
||||
source /opt/ros/foxy/setup.bash
|
||||
```
|
||||
```sh
|
||||
cd ~/ws_sensor_combined/
|
||||
source /opt/ros/foxy/setup.bash
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
2. Source the `local_setup.bash`.
|
||||
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
|
||||
3. Now launch the example.
|
||||
Note here that we use `ros2 launch`, which is described below.
|
||||
Note here that we use `ros2 launch`, which is described below.
|
||||
|
||||
```sh
|
||||
ros2 launch px4_ros_com sensor_combined_listener.launch.py
|
||||
```
|
||||
```sh
|
||||
ros2 launch px4_ros_com sensor_combined_listener.launch.py
|
||||
```
|
||||
|
||||
If this is working you should see data being printed on the terminal/console where you launched the ROS listener:
|
||||
|
||||
@@ -385,18 +385,18 @@ If you were to use incompatible [message versions](../middleware/uorb.md#message
|
||||
|
||||
1. Include the [Message Translation Node](../ros2/px4_ros2_msg_translation_node.md) into the example workspace or a separate workspace by running the following script:
|
||||
|
||||
```sh
|
||||
cd /path/to/ros_ws
|
||||
/path/to/PX4-Autopilot/Tools/copy_to_ros_ws.sh .
|
||||
```
|
||||
```sh
|
||||
cd /path/to/ros_ws
|
||||
/path/to/PX4-Autopilot/Tools/copy_to_ros_ws.sh .
|
||||
```
|
||||
|
||||
2. Build and run the translation node:
|
||||
|
||||
```sh
|
||||
colcon build
|
||||
source install/local_setup.bash
|
||||
ros2 run translation_node translation_node_bin
|
||||
```
|
||||
```sh
|
||||
colcon build
|
||||
source install/local_setup.bash
|
||||
ros2 run translation_node translation_node_bin
|
||||
```
|
||||
|
||||
## Controlling a Vehicle
|
||||
|
||||
@@ -405,7 +405,7 @@ To control applications, ROS 2 applications:
|
||||
- subscribe to (listen to) telemetry topics published by PX4
|
||||
- publish to topics that cause PX4 to perform some action.
|
||||
|
||||
The topics that you can use are defined in [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml), and you can get more information about their data in the [uORB Message Reference](../msg_docs/index.md).
|
||||
The topics that you can use are defined in [dds_topics.yaml](../middleware/dds_topics.md), and you can get more information about their data in the [uORB Message Reference](../msg_docs/index.md).
|
||||
For example, [VehicleGlobalPosition](../msg_docs/VehicleGlobalPosition.md) can be used to get the vehicle global position, while [VehicleCommand](../msg_docs/VehicleCommand.md) can be used to command actions such as takeoff and land.
|
||||
|
||||
The [ROS 2 Example applications](#ros-2-example-applications) examples below provide concrete examples of how to use these topics.
|
||||
@@ -456,13 +456,13 @@ Therefore, ROS 2 nodes that want to interface with PX4 must take care of the fra
|
||||
|
||||
- To rotate a vector from ENU to NED two basic rotations must be performed:
|
||||
|
||||
- first a pi/2 rotation around the `Z`-axis (up),
|
||||
- then a pi rotation around the `X`-axis (old East/new North).
|
||||
- first a pi/2 rotation around the `Z`-axis (up),
|
||||
- then a pi rotation around the `X`-axis (old East/new North).
|
||||
|
||||
- To rotate a vector from NED to ENU two basic rotations must be performed:
|
||||
|
||||
- - first a pi/2 rotation around the `Z`-axis (down),
|
||||
- then a pi rotation around the `X`-axis (old North/new East). Note that the two resulting operations are mathematically equivalent.
|
||||
- then a pi rotation around the `X`-axis (old North/new East). Note that the two resulting operations are mathematically equivalent.
|
||||
|
||||
- To rotate a vector from FLU to FRD a pi rotation around the `X`-axis (front) is sufficient.
|
||||
|
||||
@@ -720,17 +720,17 @@ Therefore,
|
||||
|
||||
- If you're using a main or release version of PX4 you can get the message definitions by cloning the interface package [PX4/px4_msgs](https://github.com/PX4/px4_msgs) into your workspace.
|
||||
- If you're creating or modifying uORB messages you must manually update the messages in your workspace from your PX4 source tree.
|
||||
Generally this means that you would update [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml), clone the interface package, and then manually synchronize it by copying the new/modified message definitions from [PX4-Autopilot/msg](https://github.com/PX4/PX4-Autopilot/tree/main/msg) to its `msg` folders.
|
||||
Assuming that PX4-Autopilot is in your home directory `~`, while `px4_msgs` is in `~/ros2_ws/src/`, then the command might be:
|
||||
Generally this means that you would update [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml), clone the interface package, and then manually synchronize it by copying the new/modified message definitions from [PX4-Autopilot/msg](https://github.com/PX4/PX4-Autopilot/tree/main/msg) to its `msg` folders.
|
||||
Assuming that PX4-Autopilot is in your home directory `~`, while `px4_msgs` is in `~/ros2_ws/src/`, then the command might be:
|
||||
|
||||
```sh
|
||||
rm ~/ros2_ws/src/px4_msgs/msg/*.msg
|
||||
cp ~/PX4-Autopilot/mgs/*.msg ~/ros2_ws/src/px4_msgs/msg/
|
||||
```
|
||||
```sh
|
||||
rm ~/ros2_ws/src/px4_msgs/msg/*.msg
|
||||
cp ~/PX4-Autopilot/mgs/*.msg ~/ros2_ws/src/px4_msgs/msg/
|
||||
```
|
||||
|
||||
::: info
|
||||
Technically, [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) completely defines the relationship between PX4 uORB topics and ROS 2 messages.
|
||||
For more information see [uXRCE-DDS > DDS Topics YAML](../middleware/uxrce_dds.md#dds-topics-yaml).
|
||||
::: info
|
||||
Technically, [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) completely defines the relationship between PX4 uORB topics and ROS 2 messages.
|
||||
For more information see [uXRCE-DDS > DDS Topics YAML](../middleware/uxrce_dds.md#dds-topics-yaml).
|
||||
|
||||
:::
|
||||
|
||||
@@ -739,11 +739,11 @@ Therefore,
|
||||
Custom topic and service namespaces can be applied at build time (changing [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml)) or at runtime (useful for multi vehicle operations):
|
||||
|
||||
- One possibility is to use the `-n` option when starting the [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) from command line.
|
||||
This technique can be used both in simulation and real vehicles.
|
||||
This technique can be used both in simulation and real vehicles.
|
||||
- A custom namespace can be provided for simulations (only) by setting the environment variable `PX4_UXRCE_DDS_NS` before starting the simulation.
|
||||
|
||||
:::info
|
||||
Changing the namespace at runtime will append the desired namespace as a prefix to all `topic` fields in [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) and all [service servers](#px4-ros-2-service-servers).
|
||||
Changing the namespace at runtime will append the desired namespace as a prefix to all `topic` fields in [dds_topics.yaml](../middleware/dds_topics.md) and all [service servers](#px4-ros-2-service-servers).
|
||||
Therefore, commands like:
|
||||
|
||||
```sh
|
||||
@@ -780,7 +780,7 @@ The service servers that are built into the PX4 [uxrce_dds_client](../modules/mo
|
||||
|
||||
- `/fmu/vehicle_command` (definition: [`px4_msgs::srv::VehicleCommand`](https://github.com/PX4/px4_msgs/blob/main/srv/VehicleCommand.srv).)
|
||||
|
||||
This service can be called by ROS 2 applications to send PX4 [VehicleCommand](../msg_docs/VehicleCommand.md) uORB messages and receive PX4 [VehicleCommandAck](../msg_docs/VehicleCommandAck.md) uORB messages in response.
|
||||
This service can be called by ROS 2 applications to send PX4 [VehicleCommand](../msg_docs/VehicleCommand.md) uORB messages and receive PX4 [VehicleCommandAck](../msg_docs/VehicleCommandAck.md) uORB messages in response.
|
||||
|
||||
All PX4 service names follow the convention `{extra_namespace}/fmu/{server_specific_name}` where `{extra_namespace}` is the same [custom namespace](#customizing-the-namespace) that can be given to the PX4 topics.
|
||||
|
||||
@@ -973,38 +973,38 @@ The standard installation should include all the tools needed by ROS 2.
|
||||
If any are missing, they can be added separately:
|
||||
|
||||
- **`colcon`** build tools should be in the development tools.
|
||||
It can be installed using:
|
||||
It can be installed using:
|
||||
|
||||
```sh
|
||||
$ git clone https://github.com/PX4/px4_ros_com.git ~/px4_ros_com_ros2/src/px4_ros_com
|
||||
$ git clone https://github.com/PX4/px4_msgs.git ~/px4_ros_com_ros2/src/px4_msgs
|
||||
```
|
||||
```sh
|
||||
$ git clone https://github.com/PX4/px4_ros_com.git ~/px4_ros_com_ros2/src/px4_ros_com
|
||||
$ git clone https://github.com/PX4/px4_msgs.git ~/px4_ros_com_ros2/src/px4_msgs
|
||||
```
|
||||
|
||||
- The Eigen3 library used by the transforms library should be in the both the desktop and base packages.
|
||||
It should be installed as shown:
|
||||
It should be installed as shown:
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
::: tab humble
|
||||
|
||||
```sh
|
||||
sudo apt install ros-humble-eigen3-cmake-module
|
||||
```
|
||||
```sh
|
||||
sudo apt install ros-humble-eigen3-cmake-module
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
::: tab foxy
|
||||
|
||||
```sh
|
||||
$ cd ~/px4_ros_com_ros2/src/px4_ros_com/scripts
|
||||
$ source build_ros2_workspace.bash
|
||||
```
|
||||
```sh
|
||||
$ cd ~/px4_ros_com_ros2/src/px4_ros_com/scripts
|
||||
$ source build_ros2_workspace.bash
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
### ros_gz_bridge not publishing on the \clock topic
|
||||
|
||||
|
||||
@@ -733,6 +733,7 @@
|
||||
- [Protocols/Microservices](mavlink/protocols.md)
|
||||
- [Standard Modes Protocol](mavlink/standard_modes.md)
|
||||
- [uXRCE-DDS (PX4-ROS 2/DDS Bridge)](middleware/uxrce_dds.md)
|
||||
- [UORB Bridged to ROS 2](middleware/dds_topics.md)
|
||||
- [Модулі & Команди](modules/modules_main.md)
|
||||
- [Автоматичне підлаштування](modules/modules_autotune.md)
|
||||
- [Команди](modules/modules_command.md)
|
||||
|
||||
@@ -128,21 +128,21 @@ You add some "boilerplate" code to regularly listen for changes in the [uORB Top
|
||||
|
||||
- **px4_platform_common/module_params.h** для отримання макросу `DEFINE_PARAMETERS`:
|
||||
|
||||
```cpp
|
||||
#include <px4_platform_common/module_params.h>
|
||||
```
|
||||
```cpp
|
||||
#include <px4_platform_common/module_params.h>
|
||||
```
|
||||
|
||||
- **parameter_update.h** для доступу до повідомлень uORB `parameter_update`:
|
||||
|
||||
```cpp
|
||||
#include <uORB/topics/parameter_update.h>
|
||||
```
|
||||
```cpp
|
||||
#include <uORB/topics/parameter_update.h>
|
||||
```
|
||||
|
||||
- **Subscription.hpp** для uORB C++ API підписки:
|
||||
|
||||
```cpp
|
||||
#include <uORB/Subscription.hpp>
|
||||
```
|
||||
```cpp
|
||||
#include <uORB/Subscription.hpp>
|
||||
```
|
||||
|
||||
Derive your class from `ModuleParams`, and use `DEFINE_PARAMETERS` to specify a list of parameters and their associated parameter attributes.
|
||||
Назви параметрів мають збігатися з визначеннями метаданих параметрів.
|
||||
@@ -194,7 +194,7 @@ void Module::parameters_update()
|
||||
- `_param_update_sub.updated()` повідомляє нам, чи є _будь-яке_ оновлення в uORB-повідомленні `param_update` (але не вказує, який саме параметр змінено).
|
||||
- Якщо було оновлено "деякий" параметр, ми копіюємо оновлення у `parameter_update_s` (`param_update`), щоб очистити очікуване оновлення.
|
||||
- Then we call `ModuleParams::updateParams()`.
|
||||
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
|
||||
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
|
||||
|
||||
Атрибути параметрів (`_sys_autostart` і `_att_bias_max` у цьому випадку) можна використовувати для відображення параметрів, і вони будуть оновлюватися щоразу, коли значення параметра змінюватиметься.
|
||||
|
||||
@@ -267,12 +267,12 @@ YAML meta data is intended as a full replacement for the **.c** definitions.
|
||||
- Приклад використання визначень YAML можна знайти у визначенні параметрів MAVLink: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/module.yaml).
|
||||
- YAML-файл реєструється у системі збірки cmake шляхом додавання
|
||||
|
||||
```cmake
|
||||
MODULE_CONFIG
|
||||
module.yaml
|
||||
```
|
||||
```cmake
|
||||
MODULE_CONFIG
|
||||
module.yaml
|
||||
```
|
||||
|
||||
до секції `px4_add_module` файлу `CMakeLists.txt` цього модуля.
|
||||
до секції `px4_add_module` файлу `CMakeLists.txt` цього модуля.
|
||||
|
||||
#### Мета-дані YAML з багатьма екземплярами (шаблонами)
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ This guide walks through the process of setting up the board and connecting to P
|
||||
You will temporarily need the following hardware in order to log into your Jetson and get its IP address, after which you will be able to log in via SSH:
|
||||
|
||||
- External display.
|
||||
If your display doesn't have a mini HDMI connector you will also need a [Mini HDMI to HDMI converter](https://a.co/d/6N815N9) if your external display has HDMI input
|
||||
If your display doesn't have a mini HDMI connector you will also need a [Mini HDMI to HDMI converter](https://a.co/d/6N815N9) if your external display has HDMI input
|
||||
- Ethernet cable
|
||||
- Mouse and keyboard (the baseboard has 4 USB ports exposed from Jetson, two of which are USB 3.0)
|
||||
|
||||
@@ -45,11 +45,11 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- Розміри
|
||||
|
||||
- 126 x 80 x 45mm (with Jetson Orin NX + Heatsink/Fan & FC Module)
|
||||
- 126 x 80 x 22.9mm (without Jetson and FC Module)
|
||||
- 126 x 80 x 45mm (with Jetson Orin NX + Heatsink/Fan & FC Module)
|
||||
- 126 x 80 x 22.9mm (without Jetson and FC Module)
|
||||
|
||||
- Вага
|
||||
- 190g (with Jetson, Heatsink, Flight Controller, M.2 SSD, M.2 Wi-Fi Module)
|
||||
- 190g (with Jetson, Heatsink, Flight Controller, M.2 SSD, M.2 Wi-Fi Module)
|
||||
|
||||
:::
|
||||
|
||||
@@ -57,67 +57,67 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- 2x Gigabit Ethernet Port
|
||||
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- Ethernet Switch powered by the same circuit as the Pixhawk
|
||||
- 8-pin JST-GH
|
||||
- RJ45
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- Ethernet Switch powered by the same circuit as the Pixhawk
|
||||
- 8-pin JST-GH
|
||||
- RJ45
|
||||
|
||||
- 2x MIPI CSI Camera Inputs
|
||||
|
||||
- 4 Lanes each
|
||||
- 22-Pin Raspberry Pi Cam FFC
|
||||
- 4 Lanes each
|
||||
- 22-Pin Raspberry Pi Cam FFC
|
||||
|
||||
- 2x USB 3.0 Host Port
|
||||
|
||||
- USB A
|
||||
- 5A Current Limit
|
||||
- USB A
|
||||
- 5A Current Limit
|
||||
|
||||
- 2x USB 2.0 Host Port
|
||||
|
||||
- 5-Pin JST-GH
|
||||
- 0A Current Limit
|
||||
- 5-Pin JST-GH
|
||||
- 0A Current Limit
|
||||
|
||||
- USB 2.0 for Programming/Debugging
|
||||
|
||||
- USB-C
|
||||
- USB-C
|
||||
|
||||
- 2 Key M 2242/2280 for NVMe SSD
|
||||
|
||||
- PCIEx4
|
||||
- PCIEx4
|
||||
|
||||
- 2 Key E 2230 for WiFi/BT
|
||||
|
||||
- PCIEx2
|
||||
- USB
|
||||
- UART
|
||||
- I2S
|
||||
- PCIEx2
|
||||
- USB
|
||||
- UART
|
||||
- I2S
|
||||
|
||||
- Mini HDMI Out
|
||||
|
||||
- 4x GPIO
|
||||
|
||||
- 6-pin JST-GH
|
||||
- 6-pin JST-GH
|
||||
|
||||
- CAN Port
|
||||
|
||||
- Connected to Autopilot's CAN2 (4 Pin JST-GH)
|
||||
- Connected to Autopilot's CAN2 (4 Pin JST-GH)
|
||||
|
||||
- SPI порт
|
||||
|
||||
- 7-Pin JST-GH
|
||||
- 7-Pin JST-GH
|
||||
|
||||
- I2C порт
|
||||
|
||||
- 4-Pin JST-GH
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- I2S Port
|
||||
|
||||
- 7-Pin JST-GH
|
||||
- 7-Pin JST-GH
|
||||
|
||||
- 2x UART Port
|
||||
|
||||
- 1 for debug
|
||||
- 1 connected to Autopilot's telem2
|
||||
- 1 for debug
|
||||
- 1 connected to Autopilot's telem2
|
||||
|
||||
- Fan Power Port
|
||||
|
||||
@@ -129,13 +129,13 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- Pixhawk Autopilot Bus Interface
|
||||
|
||||
- 100 Pin Hirose DF40
|
||||
- 50 Pin Hirose DF40
|
||||
- 100 Pin Hirose DF40
|
||||
- 50 Pin Hirose DF40
|
||||
|
||||
- Redundant Digital Power Module Inputs
|
||||
|
||||
- I2C Power Monitor Support
|
||||
- 2x 6-Pin Molex CLIK-Mate
|
||||
- I2C Power Monitor Support
|
||||
- 2x 6-Pin Molex CLIK-Mate
|
||||
|
||||
- Power Path Selector
|
||||
|
||||
@@ -143,68 +143,68 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- Номінальна напруга
|
||||
|
||||
- Максимальна вхідна напруга: 6 В
|
||||
- Вхід USB Power: 4.75~5.25V
|
||||
- Максимальна вхідна напруга: 6 В
|
||||
- Вхід USB Power: 4.75~5.25V
|
||||
|
||||
- Повноцінний порт перемикача безпеки GPS Plus
|
||||
|
||||
- 10-Pin JST-GH
|
||||
- 10-Pin JST-GH
|
||||
|
||||
- Secondary (GPS2) Port
|
||||
|
||||
- 6-Pin JST-GH
|
||||
- 6-Pin JST-GH
|
||||
|
||||
- 2x CAN Ports
|
||||
|
||||
- 4-Pin JST-GH
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- 3x Telemetry Ports with Flow Control
|
||||
|
||||
- 2x 6-Pin JST-GH
|
||||
- 1 is connected to Jetson's `UART1` Port
|
||||
- 2x 6-Pin JST-GH
|
||||
- 1 is connected to Jetson's `UART1` Port
|
||||
|
||||
- 16 PWM Outputs
|
||||
|
||||
- 2x 10-Pin JST-GH
|
||||
- 2x 10-Pin JST-GH
|
||||
|
||||
- UART4 & I2C Port
|
||||
|
||||
- 6-Pin JST-GH
|
||||
- 6-Pin JST-GH
|
||||
|
||||
- 2x Gigabit Ethernet Port
|
||||
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- 8-Pin JST-GH
|
||||
- RJ45
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- 8-Pin JST-GH
|
||||
- RJ45
|
||||
|
||||
- AD & IO
|
||||
|
||||
- 8-Pin JST-GH
|
||||
- 8-Pin JST-GH
|
||||
|
||||
- USB 2.0
|
||||
|
||||
- USB-C
|
||||
- 4-Pin JST-GH
|
||||
- USB-C
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- DSM Input
|
||||
|
||||
- 3-Pin JST-ZH 1.5mm Pitch
|
||||
- 3-Pin JST-ZH 1.5mm Pitch
|
||||
|
||||
- RC In
|
||||
|
||||
- PPM/SBUS
|
||||
- 5-Pin JST-GH
|
||||
- PPM/SBUS
|
||||
- 5-Pin JST-GH
|
||||
|
||||
- SPI порт
|
||||
|
||||
- External Sensor Bus (SPI5)
|
||||
- 11-Pin JST-GH
|
||||
- External Sensor Bus (SPI5)
|
||||
- 11-Pin JST-GH
|
||||
|
||||
- 2x Debug Port
|
||||
|
||||
- 1 for FMU
|
||||
- 1 for IO
|
||||
- 10-Pin JST-SH
|
||||
- 1 for FMU
|
||||
- 1 for IO
|
||||
- 10-Pin JST-SH
|
||||
|
||||
:::
|
||||
|
||||
@@ -218,7 +218,7 @@ The Jetson has separate input power circuitry from the Pixhawk autopilot:
|
||||
- 8V/3A Minimum (Depends on Usage and Peripherals)
|
||||
- Voltage Rating: 7-21V (3S-4S)
|
||||
- Jetson Baseboard onboard BEC is rated for 7-21V (3S-4S).
|
||||
Note that the external UBEC-12A can be used for applications above 4S
|
||||
Note that the external UBEC-12A can be used for applications above 4S
|
||||
|
||||
During development using the following wired power supply is recommended:
|
||||
|
||||
@@ -698,7 +698,7 @@ On the following screen, confirm your selected device:
|
||||
|
||||
- Choose `Pre-config` for the OEM Configuration (this will skip Ubuntu first time setup screens after reboot).
|
||||
- Choose your preferred username and password (and write them down).
|
||||
These will be used as your login credentials to Jetpack.
|
||||
These will be used as your login credentials to Jetpack.
|
||||
- Choose `NVMe` as the storage device because the board has separate SSD for storage.
|
||||
|
||||

|
||||
@@ -922,95 +922,95 @@ These instructions approximately mirror the [PX4 Ethernet setup](../advanced_con
|
||||
Next we modify the Jetson IP address to be on the same network as the Pixhawk:
|
||||
|
||||
1. Make sure `netplan` is installed.
|
||||
You can check by running the following command:
|
||||
You can check by running the following command:
|
||||
|
||||
```sh
|
||||
netplan -h
|
||||
```
|
||||
```sh
|
||||
netplan -h
|
||||
```
|
||||
|
||||
If not, install it using the commands:
|
||||
If not, install it using the commands:
|
||||
|
||||
```sh
|
||||
sudo apt update
|
||||
sudo apt install netplan.io
|
||||
```
|
||||
```sh
|
||||
sudo apt update
|
||||
sudo apt install netplan.io
|
||||
```
|
||||
|
||||
2. Check `system_networkd` is running:
|
||||
|
||||
```sh
|
||||
sudo systemctl status systemd-networkd
|
||||
```
|
||||
```sh
|
||||
sudo systemctl status systemd-networkd
|
||||
```
|
||||
|
||||
You should see output like below if it is active:
|
||||
You should see output like below if it is active:
|
||||
|
||||
```sh
|
||||
● systemd-networkd.service - Network Configuration
|
||||
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2024-09-11 23:32:44 EDT; 23min ago
|
||||
TriggeredBy: ● systemd-networkd.socket
|
||||
Docs: man:systemd-networkd.service(8)
|
||||
Main PID: 2452 (systemd-network)
|
||||
Status: "Processing requests..."
|
||||
Tasks: 1 (limit: 18457)
|
||||
Memory: 2.7M
|
||||
CPU: 157ms
|
||||
CGroup: /system.slice/systemd-networkd.service
|
||||
└─2452 /lib/systemd/systemd-networkd
|
||||
```sh
|
||||
● systemd-networkd.service - Network Configuration
|
||||
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2024-09-11 23:32:44 EDT; 23min ago
|
||||
TriggeredBy: ● systemd-networkd.socket
|
||||
Docs: man:systemd-networkd.service(8)
|
||||
Main PID: 2452 (systemd-network)
|
||||
Status: "Processing requests..."
|
||||
Tasks: 1 (limit: 18457)
|
||||
Memory: 2.7M
|
||||
CPU: 157ms
|
||||
CGroup: /system.slice/systemd-networkd.service
|
||||
└─2452 /lib/systemd/systemd-networkd
|
||||
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: lo: Gained carrier
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: eth0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: Enumeration completed
|
||||
Sep 11 23:32:44 ubuntu systemd[1]: Started Network Configuration.
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Connected WiFi access point: Verizon_7YLWWD (78:67:0e:ea:a6:0>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
```
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: lo: Gained carrier
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: eth0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: Enumeration completed
|
||||
Sep 11 23:32:44 ubuntu systemd[1]: Started Network Configuration.
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Connected WiFi access point: Verizon_7YLWWD (78:67:0e:ea:a6:0>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
```
|
||||
|
||||
If `system_networkd` is not running, it can be enabled using:
|
||||
If `system_networkd` is not running, it can be enabled using:
|
||||
|
||||
```sh
|
||||
sudo systemctl start systemd-networkd
|
||||
sudo systemctl enable systemd-networkd
|
||||
```
|
||||
```sh
|
||||
sudo systemctl start systemd-networkd
|
||||
sudo systemctl enable systemd-networkd
|
||||
```
|
||||
|
||||
3. Open the Netplan configuration file (so we can set up a static IP for the Jetson).
|
||||
|
||||
The Netplan configuration file is usually located in the `/etc/netplan/` directory and named something like `01-netcfg.yaml` (the name can vary).
|
||||
Below we use `nano` to open the file, but you can use your preferred text editor:
|
||||
The Netplan configuration file is usually located in the `/etc/netplan/` directory and named something like `01-netcfg.yaml` (the name can vary).
|
||||
Below we use `nano` to open the file, but you can use your preferred text editor:
|
||||
|
||||
```sh
|
||||
sudo nano /etc/netplan/01-netcfg.yaml
|
||||
```
|
||||
```sh
|
||||
sudo nano /etc/netplan/01-netcfg.yaml
|
||||
```
|
||||
|
||||
4. Modify the yaml configuration, by overwriting the contents with the following information and then saving:
|
||||
|
||||
```sh
|
||||
network:
|
||||
version: 2
|
||||
renderer: networkd
|
||||
ethernets:
|
||||
eth0:
|
||||
dhcp4: no
|
||||
addresses:
|
||||
- 10.41.10.1/24
|
||||
routes:
|
||||
- to: 0.0.0.0/0
|
||||
via: 10.41.10.254
|
||||
nameservers:
|
||||
addresses:
|
||||
- 10.41.10.254
|
||||
```
|
||||
```sh
|
||||
network:
|
||||
version: 2
|
||||
renderer: networkd
|
||||
ethernets:
|
||||
eth0:
|
||||
dhcp4: no
|
||||
addresses:
|
||||
- 10.41.10.1/24
|
||||
routes:
|
||||
- to: 0.0.0.0/0
|
||||
via: 10.41.10.254
|
||||
nameservers:
|
||||
addresses:
|
||||
- 10.41.10.254
|
||||
```
|
||||
|
||||
This gives the Jetson a static IP address on the Ethernet interface of `10.41.10.1` .
|
||||
This gives the Jetson a static IP address on the Ethernet interface of `10.41.10.1` .
|
||||
|
||||
5. Apply the changes using the following command:
|
||||
|
||||
```sh
|
||||
sudo netplan apply
|
||||
```
|
||||
```sh
|
||||
sudo netplan apply
|
||||
```
|
||||
|
||||
The Pixhawk Ethernet address is set to `10.41.10.2` by default, which is on the same subnet.
|
||||
We can test our changes above by pinging the Pixhawk from within the Jetson terminal:
|
||||
@@ -1221,15 +1221,15 @@ Assuming the client is set up as defined above:
|
||||
|
||||
- (Serial connection) Start the agent on `/dev/ttyTHS1`:
|
||||
|
||||
```sh
|
||||
sudo MicroXRCEAgent serial --dev /dev/ttyTHS1 -b 921600
|
||||
```
|
||||
```sh
|
||||
sudo MicroXRCEAgent serial --dev /dev/ttyTHS1 -b 921600
|
||||
```
|
||||
|
||||
- (Ethernet) Start the agent on UDP port `8888`:
|
||||
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
|
||||
If your agent and client are connected and no nodes are running, you should see output similar to this in the Agent terminal:
|
||||
|
||||
|
||||
@@ -71,42 +71,42 @@ events::send<uint8_t, float>(events::ID("event_name"),
|
||||
- `/* EVENT`: Цей тег вказує, що коментар описує метадані для наступної події.
|
||||
|
||||
- **event_name**: ім'я події (`events::ID(event_name)`).
|
||||
- повинно бути унікальним в межах всього вихідного коду PX4.
|
||||
Як загальне правило, додайте префікс з назвою модуля або вихідного файлу для великих модулів.
|
||||
- має бути дійсна назва змінної, тобто не повинна містити пробіли, двокрапки тощо.
|
||||
- з цього імені отримується 24-бітний ID події за допомогою геш-функції.
|
||||
Це означає, що до тих пір, поки ім'я події залишається однаковим, ID залишиться тим же.
|
||||
- повинно бути унікальним в межах всього вихідного коду PX4.
|
||||
Як загальне правило, додайте префікс з назвою модуля або вихідного файлу для великих модулів.
|
||||
- має бути дійсна назва змінної, тобто не повинна містити пробіли, двокрапки тощо.
|
||||
- з цього імені отримується 24-бітний ID події за допомогою геш-функції.
|
||||
Це означає, що до тих пір, поки ім'я події залишається однаковим, ID залишиться тим же.
|
||||
|
||||
- **Рівень журналювання**:
|
||||
|
||||
- припустимі рівні журналювання такі ж, як і у перерахуванні MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY).
|
||||
Рівні перелічені за зменшенням важливості:
|
||||
- припустимі рівні журналювання такі ж, як і у перерахуванні MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY).
|
||||
Рівні перелічені за зменшенням важливості:
|
||||
|
||||
```plain
|
||||
Emergency,
|
||||
Alert,
|
||||
Critical,
|
||||
Error,
|
||||
Warning,
|
||||
Notice,
|
||||
Info,
|
||||
Debug,
|
||||
Disabled,
|
||||
```
|
||||
```plain
|
||||
Emergency,
|
||||
Alert,
|
||||
Critical,
|
||||
Error,
|
||||
Warning,
|
||||
Notice,
|
||||
Info,
|
||||
Debug,
|
||||
Disabled,
|
||||
```
|
||||
|
||||
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
|
||||
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
|
||||
There are cases it makes sense to have two different log levels.
|
||||
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
|
||||
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
|
||||
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
|
||||
There are cases it makes sense to have two different log levels.
|
||||
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
|
||||
|
||||
- **Повідомлення про подію**:
|
||||
- Коротке повідомлення про подію в один рядок.
|
||||
Може мати шаблонні замінники для аргументів (наприклад `{1}`). Для додаткової інформації дивіться нижче. Для додаткової інформації дивіться нижче.
|
||||
- Коротке повідомлення про подію в один рядок.
|
||||
Може мати шаблонні замінники для аргументів (наприклад `{1}`). Для додаткової інформації дивіться нижче. Для додаткової інформації дивіться нижче.
|
||||
|
||||
- **Опис події**:
|
||||
- Докладний, необов'язковий опис події.
|
||||
- Може бути кілька рядів/абзаців.
|
||||
- It may contain template placeholders for arguments (e.g. `{2}`) and supported tags (see below)
|
||||
- Докладний, необов'язковий опис події.
|
||||
- Може бути кілька рядів/абзаців.
|
||||
- It may contain template placeholders for arguments (e.g. `{2}`) and supported tags (see below)
|
||||
|
||||
#### Аргументи та перерахування
|
||||
|
||||
@@ -125,35 +125,35 @@ Events can have a fixed set of arguments that can be inserted into the message o
|
||||
|
||||
- символи можна екранувати за допомогою \\
|
||||
|
||||
Ці символи повинні бути екрановані: '\\\\', '\\<', '\\{'.
|
||||
Ці символи повинні бути екрановані: '\\\\', '\\<', '\\{'.
|
||||
|
||||
- теги що підтримуються:
|
||||
|
||||
- Профілі: `<profile name="[!]NAME">CONTENT</profile>`
|
||||
- Профілі: `<profile name="[!]NAME">CONTENT</profile>`
|
||||
|
||||
`CONTENT` буде показано, лише якщо назва збігається з налаштованим профілем.
|
||||
Це може бути використано, наприклад, щоб приховати інформацію для розробників від кінцевих користувачів.
|
||||
`CONTENT` буде показано, лише якщо назва збігається з налаштованим профілем.
|
||||
Це може бути використано, наприклад, щоб приховати інформацію для розробників від кінцевих користувачів.
|
||||
|
||||
- URLs: `<a [href="URL"]>CONTENT</a>`.
|
||||
If `href` is not set, use `CONTENT` as `URL` (i.e.`<a>https://docs.px4.io</a>` is interpreted as `<a href="https://docs.px4.io">https://docs.px4.io</a>`)
|
||||
- URLs: `<a [href="URL"]>CONTENT</a>`.
|
||||
If `href` is not set, use `CONTENT` as `URL` (i.e.`<a>https://docs.px4.io</a>` is interpreted as `<a href="https://docs.px4.io">https://docs.px4.io</a>`)
|
||||
|
||||
- Parameters: `<param>PARAM_NAME</param>`
|
||||
- Parameters: `<param>PARAM_NAME</param>`
|
||||
|
||||
- не дозволено використовувати вкладені теги того ж типу
|
||||
- не дозволено використовувати вкладені теги того ж типу
|
||||
|
||||
- аргументи: шаблонні замінники, що відповідають синтаксису python з індексацією що починається з 1 (замість 0)
|
||||
|
||||
- загальна форма: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
|
||||
- загальна форма: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
|
||||
|
||||
UNIT:
|
||||
UNIT:
|
||||
|
||||
- m: горизонтальна відстань в метрах
|
||||
- m_v: вертикальна відстань в метрах
|
||||
- m^2: площа в метрах квадратних
|
||||
- m/s: швидкість у метрах в секунду
|
||||
- C: температура у градусах Цельсія
|
||||
- m: горизонтальна відстань в метрах
|
||||
- m_v: вертикальна відстань в метрах
|
||||
- m^2: площа в метрах квадратних
|
||||
- m/s: швидкість у метрах в секунду
|
||||
- C: температура у градусах Цельсія
|
||||
|
||||
- `NUM_DECIMAL_DIGITS` підходить тільки для аргументів у вигляді дійсних чисел.
|
||||
- `NUM_DECIMAL_DIGITS` підходить тільки для аргументів у вигляді дійсних чисел.
|
||||
|
||||
## Логування
|
||||
|
||||
|
||||
+14
-14
@@ -38,9 +38,9 @@ Selecting an airframe applies a [frame configuration file](../dev_airframes/addi
|
||||
Коли ви виводите новий транспортний засіб, рама зазвичай містить досить мінімальну конфігурацію:
|
||||
|
||||
- Кадри з назвою "Загальний" визначають тип транспортного засобу, кількість роторів та позиції роторів-заповнювачі.
|
||||
Після вибору конструкції фюзеляжу ви визначаєте фактичну геометрію, а потім налаштовуєте виходи.
|
||||
Після вибору конструкції фюзеляжу ви визначаєте фактичну геометрію, а потім налаштовуєте виходи.
|
||||
- Кадри з назвою моделі/бренду визначать тип транспортного засобу, кількість роторів, фактичні позиції роторів та напрямки руху двигуна.
|
||||
Після вибору конструкції фюзеляжу вам зазвичай все ще потрібно налаштувати виводи.
|
||||
Після вибору конструкції фюзеляжу вам зазвичай все ще потрібно налаштувати виводи.
|
||||
|
||||
:::
|
||||
|
||||
@@ -52,7 +52,7 @@ If using PWM ESCs and OneShot ESCs (but not DShot and DroneCAN/Cyphal ESC) you s
|
||||
The final step is [Motor Configuration](../config/actuators.md#motor-configuration):
|
||||
|
||||
- [Reverse any motors](../config/actuators.md#reversing-motors) that don't match the spin direction configured in the Geometry.
|
||||
Для DShot ESC ви можете це зробити через інтерфейс тестування приводу.
|
||||
Для DShot ESC ви можете це зробити через інтерфейс тестування приводу.
|
||||
- PWM, OneShot та CAN ESC встановлюють ліміти введення мотора для режимів роззброєння, низької та високої швидкості (не потрібно для DShot ESC)
|
||||
|
||||
Відповідні теми:
|
||||
@@ -123,14 +123,14 @@ PX4 може бути налаштований для автоматичної
|
||||
|
||||
- [Autotune](../config/autotune_mc.md) — Automates tuning PX4 rate and attitude controllers (recommended).
|
||||
|
||||
::: info
|
||||
Automatic tuning works on frames that have reasonable authority and dynamics around all the body axes.
|
||||
Це було перевірено в основному на гоночних квадрокоптерах та X500, і очікується, що воно буде менш ефективним на трикоптерах з нахилом ротора.
|
||||
::: info
|
||||
Automatic tuning works on frames that have reasonable authority and dynamics around all the body axes.
|
||||
Це було перевірено в основному на гоночних квадрокоптерах та X500, і очікується, що воно буде менш ефективним на трикоптерах з нахилом ротора.
|
||||
|
||||
Manual tuning using these guides are only needed if there is a problem with autotune:
|
||||
Manual tuning using these guides are only needed if there is a problem with autotune:
|
||||
|
||||
- [MC PID Tuning (Manual/Basic)](../config_mc/pid_tuning_guide_multicopter_basic.md) — Manual tuning basic how to.
|
||||
- [MC PID Tuning Guide (Manual/Detailed)](../config_mc/pid_tuning_guide_multicopter.md) — Manual tuning with detailed explanation.
|
||||
- [MC PID Tuning (Manual/Basic)](../config_mc/pid_tuning_guide_multicopter_basic.md) — Manual tuning basic how to.
|
||||
- [MC PID Tuning Guide (Manual/Detailed)](../config_mc/pid_tuning_guide_multicopter.md) — Manual tuning with detailed explanation.
|
||||
|
||||
|
||||
:::
|
||||
@@ -138,7 +138,7 @@ PX4 може бути налаштований для автоматичної
|
||||
- [MC Filter/Control Latency Tuning](../config_mc/filter_tuning.md) — Trade off control latency and noise filtering.
|
||||
|
||||
- [MC Setpoint Tuning (Trajectory Generator)](../config_mc/mc_trajectory_tuning.md)
|
||||
- [MC Jerk-limited Type Trajectory](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
- [MC Jerk-limited Type Trajectory](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
|
||||
- [Multicopter Racer Setup](../config_mc/racer_setup.md)
|
||||
|
||||
@@ -167,7 +167,7 @@ Yes but it must be physically feasible. E.g. if you make a quadrotor where all m
|
||||
- [Периферія контролера польоту](../peripherals/README.md) - налаштування конкретних датчиків, опціональних датчиків, приводів тощо.
|
||||
- [Advanced Configuration](../advanced_config/index.md) - Factory/OEM calibration, configuring advanced features, less-common configuration.
|
||||
- Конфігурація/налаштування, що залежать від апарату:
|
||||
- **Multicopter Config/Tuning**
|
||||
- [Конфігурація/налаштування гелікоптера](../config_heli/index.md)
|
||||
- [Fixed Wing Config/Tuning](../config_fw/index.md)
|
||||
- [Конфігурація/налаштування VTOL](../config_vtol/index.md)
|
||||
- **Multicopter Config/Tuning**
|
||||
- [Конфігурація/налаштування гелікоптера](../config_heli/index.md)
|
||||
- [Fixed Wing Config/Tuning](../config_fw/index.md)
|
||||
- [Конфігурація/налаштування VTOL](../config_vtol/index.md)
|
||||
|
||||
@@ -26,13 +26,13 @@ This topic provides full instructions for building the [Holybro X500 V2 ARF Kit]
|
||||
The Holybro [X500 V2 Kit](https://holybro.com/collections/x500-kits) includes almost all the required components:
|
||||
|
||||
- X500V2 Frame Kit
|
||||
- Body - Full Carbon Fiber Top & Bottom plate (144 x 144mm, 2mm thick)
|
||||
- Arm - High strength & ultra-lightweight 16mm carbon fiber tubes
|
||||
- Landing gear - 16mm & 10mm diameter carbon fiber tubes
|
||||
- Platform board - With mounting holes for GPS & popular companion computer
|
||||
- Система кріплення з подвійними пружинними валиками 10 мм Ø та довжиною 250 мм
|
||||
- Кріплення батареї з двома стропами для батареї
|
||||
- Ручні інструменти для встановлення
|
||||
- Body - Full Carbon Fiber Top & Bottom plate (144 x 144mm, 2mm thick)
|
||||
- Arm - High strength & ultra-lightweight 16mm carbon fiber tubes
|
||||
- Landing gear - 16mm & 10mm diameter carbon fiber tubes
|
||||
- Platform board - With mounting holes for GPS & popular companion computer
|
||||
- Система кріплення з подвійними пружинними валиками 10 мм Ø та довжиною 250 мм
|
||||
- Кріплення батареї з двома стропами для батареї
|
||||
- Ручні інструменти для встановлення
|
||||
- Holybro Motors - 2216 KV880 x6 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
- Holybro BLHeli S ESC 20A x4 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
- Propellers - 1045 x4 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
@@ -93,92 +93,92 @@ _Figure 1_: X500 V2 ARF Kit what's inside
|
||||
Орієнтовний час збірки - 55 хвилин (25 хвилин на раму, 30 хвилин на встановлення/налаштування автопілота)
|
||||
|
||||
1. Start by assembling the payload & battery holder.
|
||||
Втисніть гумки в захоплювачі (не використовуйте гострі предмети, щоб їх втиснути в них!).
|
||||
Далі пропустіть тримачі через планки тримача з основами тримача батарей, як показано на рисунку 3.
|
||||
Втисніть гумки в захоплювачі (не використовуйте гострі предмети, щоб їх втиснути в них!).
|
||||
Далі пропустіть тримачі через планки тримача з основами тримача батарей, як показано на рисунку 3.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 2_: Payload holder components
|
||||
_Figure 2_: Payload holder components
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 3_: Payload holder assembled
|
||||
_Figure 3_: Payload holder assembled
|
||||
|
||||
2. Наступним кроком буде прикріплення нижньої пластини до тримача вантажу.
|
||||
|
||||
Вам знадобляться деталі, як показано на рисунку 4.
|
||||
Потім встановіть основу для розподільної плати живлення, використовуючи нейлонові гайки, як зображено на Рис. 5.
|
||||
Нарешті, використовуючи 8 шестигранних гвинтів, ви можете приєднати нижню пластину до тримача навантаження (Рисунок 7)
|
||||
Вам знадобляться деталі, як показано на рисунку 4.
|
||||
Потім встановіть основу для розподільної плати живлення, використовуючи нейлонові гайки, як зображено на Рис. 5.
|
||||
Нарешті, використовуючи 8 шестигранних гвинтів, ви можете приєднати нижню пластину до тримача навантаження (Рисунок 7)
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 4_: Needed Materials
|
||||
_Figure 4_: Needed Materials
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 5_: PDB mount base
|
||||
_Figure 5_: PDB mount base
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 6_: Mounted pdb with nylon nuts
|
||||
_Figure 6_: Mounted pdb with nylon nuts
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 7_: Mounted Plate on payload holder
|
||||
_Figure 7_: Mounted Plate on payload holder
|
||||
|
||||
3. Давайте зберемо речі, необхідні для монтажу посадкового шасі, як на рисунку 8.
|
||||
Використовуйте гвинти, щоб приєднати посадкові шасі до нижньої пластини.
|
||||
Також потрібно відкрити три шестигранних гвинти на кожній з ніжок, щоб ви могли вставити їх у вуглецеві труби.
|
||||
Не забудьте знову їх затягнути.
|
||||
Використовуйте гвинти, щоб приєднати посадкові шасі до нижньої пластини.
|
||||
Також потрібно відкрити три шестигранних гвинти на кожній з ніжок, щоб ви могли вставити їх у вуглецеві труби.
|
||||
Не забудьте знову їх затягнути.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 8_: Required parts for landing gear attachment
|
||||
_Figure 8_: Required parts for landing gear attachment
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 9_: Landing gear attachment to the body
|
||||
_Figure 9_: Landing gear attachment to the body
|
||||
|
||||
4. Зараз ми зберемо все оснащення, щоб встановити верхню пластину.
|
||||
Прошу звернути увагу, що номери моторів на кронштейнах відповідають тим, що згадані на верхній платі.
|
||||
На щастя, мотори встановлені, а ESCs були з'єднані заздалегідь.
|
||||
Почніть, проходячи через всі гвинти, так як ви зафіксували кронштейни на їхніх власних місцях (Вони мають направляючий елемент, як показано на рисунку 11, щоб переконатися, що вони на місці), і трохи підтягніть всі нейлонові гайки.
|
||||
Потім ви зможете підключити роз'єми живлення XT30 до плати живлення.
|
||||
Пам'ятайте, що дроти сигналу повинні бути проведені через верхню пластину так, що ми зможемо пізніше їх підключити до Pixhawk.
|
||||
Прошу звернути увагу, що номери моторів на кронштейнах відповідають тим, що згадані на верхній платі.
|
||||
На щастя, мотори встановлені, а ESCs були з'єднані заздалегідь.
|
||||
Почніть, проходячи через всі гвинти, так як ви зафіксували кронштейни на їхніх власних місцях (Вони мають направляючий елемент, як показано на рисунку 11, щоб переконатися, що вони на місці), і трохи підтягніть всі нейлонові гайки.
|
||||
Потім ви зможете підключити роз'єми живлення XT30 до плати живлення.
|
||||
Пам'ятайте, що дроти сигналу повинні бути проведені через верхню пластину так, що ми зможемо пізніше їх підключити до Pixhawk.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/needed_stuff_top_plate.png" width="700" title="Arms and top plate materials">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/needed_stuff_top_plate.png" width="700" title="Arms and top plate materials">
|
||||
|
||||
_Figure 10_: Connecting arms needed materials.
|
||||
_Figure 10_: Connecting arms needed materials.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/guide_for_arm_mount.png" width="700" title="Guide for the arms mount">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/guide_for_arm_mount.png" width="700" title="Guide for the arms mount">
|
||||
|
||||
_Figure 11_: Guide for the arms mount
|
||||
_Figure 11_: Guide for the arms mount
|
||||
|
||||
5. Для затягування всіх 16 гвинтів і гайок використовуйте як шестигранний ключ, так і гайковий ключ.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 12_: Mounted top plate
|
||||
_Figure 12_: Mounted top plate
|
||||
|
||||
6. Наступним кроком ви можете закріпити свій pixhawk на верхній плиті, використовуючи наклейки.
|
||||
Рекомендується мати напрямок стрілки вашого Pixhawk таким же, як зазначено на верхній плиті.
|
||||
Рекомендується мати напрямок стрілки вашого Pixhawk таким же, як зазначено на верхній плиті.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 13_: Sticker tapes on Pixhawk
|
||||
_Figure 13_: Sticker tapes on Pixhawk
|
||||
|
||||
7. Якщо ви хочете встановити GPS на плату компаньйона-комп'ютера, тепер ви можете закріпити кріплення GPS на ній за допомогою 4 гвинтів і гайок.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/gps_mount_plate.png" width="400" title="Secure GPS mount onto companion plate">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/gps_mount_plate.png" width="400" title="Secure GPS mount onto companion plate">
|
||||
|
||||
_Figure 14_: Secure GPS mount onto companion plate
|
||||
_Figure 14_: Secure GPS mount onto companion plate
|
||||
|
||||
8. За допомогою скотча приклейте GPS до верхньої частини GPS-щогли і встановіть її на щоглу.
|
||||
Переконайтеся, що стрілка на gps вказує вперед (зображення 15).
|
||||
Переконайтеся, що стрілка на gps вказує вперед (зображення 15).
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_holybro_pixhawk4/gps2.jpg" width="400" title="Figure 16: GPS and mast">
|
||||
<img src="../../assets/airframes/multicopter/x500_holybro_pixhawk4/gps2.jpg" width="400" title="Figure 16: GPS and mast">
|
||||
|
||||
_Figure 15_: GPS and mast
|
||||
_Figure 15_: GPS and mast
|
||||
|
||||
9. Наразі ви можете підключити інтерфейси Pixhawk, такі як телеметрійне радіо до 'TELEM1' та відповідно кабелі сигналів для моторів.
|
||||
|
||||
@@ -204,14 +204,14 @@ _QGroundControl_ is used to install the PX4 autopilot and configure/tune it for
|
||||
|
||||
- [Airframe](../config/airframe.md)
|
||||
|
||||
You will need to select the _Holybro X500 V2_ airframe (**Quadrotor x > Holybro 500 V2**)
|
||||
You will need to select the _Holybro X500 V2_ airframe (**Quadrotor x > Holybro 500 V2**)
|
||||
|
||||

|
||||

|
||||
|
||||
- [Actuators](../config/actuators.md)
|
||||
- Вам не потрібно оновлювати геометрію транспортного засобу (оскільки це попередньо налаштована конструкція повітряного каркасу).
|
||||
- Призначте функції приводу до актуаторів, щоб відповідати вашому підключенню.
|
||||
- Перевірте конфігурацію, використовуючи слайдери.
|
||||
- Вам не потрібно оновлювати геометрію транспортного засобу (оскільки це попередньо налаштована конструкція повітряного каркасу).
|
||||
- Призначте функції приводу до актуаторів, щоб відповідати вашому підключенню.
|
||||
- Перевірте конфігурацію, використовуючи слайдери.
|
||||
|
||||
Потім виконайте обов'язкове налаштування / калібрування:
|
||||
|
||||
|
||||
@@ -20,12 +20,12 @@ The Reptile Dragon 2 is a twin motor RC airplane specifically designed for effic
|
||||
- Видалення V-хвоста або варіанти звичайного хвоста включені
|
||||
- Різьбові вставки в крилах та верхній частині фюзеляжу для зовнішнього монтажу
|
||||
- Чимало кріплень-ознак
|
||||
- Отвір для верхньої антени
|
||||
- Верхнє покриття GPS
|
||||
- Кріплення антени біля гільзи "T"
|
||||
- Задній електронний лоток
|
||||
- Виріз "екшн камери" на передній панелі
|
||||
- Виріз для камери FPV спереду
|
||||
- Отвір для верхньої антени
|
||||
- Верхнє покриття GPS
|
||||
- Кріплення антени біля гільзи "T"
|
||||
- Задній електронний лоток
|
||||
- Виріз "екшн камери" на передній панелі
|
||||
- Виріз для камери FPV спереду
|
||||
- Знімні крила
|
||||
- Низька швидкість стійки
|
||||
- Лагідна обробка
|
||||
@@ -69,10 +69,10 @@ The Reptile Dragon 2 is a twin motor RC airplane specifically designed for effic
|
||||
- [6s2p 18650 LiIon flight battery](https://www.upgradeenergytech.com/product-page/6s-22-2v-5600mah-30c-dark-lithium-liion-drone-battery) (select XT60 connector)
|
||||
|
||||
- [Custom designed 3D printed parts](https://github.com/PX4/PX4-user_guide/raw/main/assets/airframes/fw/reptile_dragon_2/rd2_3d_printed_parts.zip)
|
||||
- Монтаж платформи ARK6X
|
||||
- Кріплення для каркасу Holybro Pixhawk 5x
|
||||
- FPV модуль та кріплення камери
|
||||
- Адаптер "заглушка" статичного зонда Піто
|
||||
- Монтаж платформи ARK6X
|
||||
- Кріплення для каркасу Holybro Pixhawk 5x
|
||||
- FPV модуль та кріплення камери
|
||||
- Адаптер "заглушка" статичного зонда Піто
|
||||
|
||||
- [Custom designed power distribution PCB](https://github.com/PX4/PX4-user_guide/raw/main/assets/airframes/fw/reptile_dragon_2/xt30_power_distro_pcb.zip)
|
||||
|
||||
@@ -425,15 +425,15 @@ With the propellers removed, power the airplane up and use the [Actuator](../con
|
||||
Я рекомендую перевірити наступні елементи:
|
||||
|
||||
- Калібрування датчиків (QGC)
|
||||
- Калібрування магнітів
|
||||
- Калібрування акселерометра
|
||||
- Калібрування швидкості повітря
|
||||
- Калібрування рівня горизонту
|
||||
- Калібрування магнітів
|
||||
- Калібрування акселерометра
|
||||
- Калібрування швидкості повітря
|
||||
- Калібрування рівня горизонту
|
||||
- Перевірка контролю над відхиленням поверхні
|
||||
- Right stick -> Right aileron goes up, left aileron goes down
|
||||
- Left stick -> Left aileron goes up, right aileron goes down
|
||||
- Stick back -> elevator goes up
|
||||
-Stick forward -> elevator goes down
|
||||
-Stick forward -> elevator goes down
|
||||
- Left rudder -> Rudder goes left
|
||||
- Right rudder -> Rudder goes right
|
||||
- Check Px4 inputs (in `stabilized mode`)
|
||||
|
||||
@@ -98,11 +98,11 @@ The mapping between flight controller outputs and specific controls/motors depen
|
||||
Assembly information is covered in several sections:
|
||||
|
||||
- [Basic Assembly](../assembly/index.md) contains topics shows the setup of core components for a number of popular [flight controllers](../flight_controller/index.md).
|
||||
Контролери польоту, для яких у нас немає посібників, зазвичай налаштовуються таким же чином (і майже завжди містять схожі посібники з налаштуванням).
|
||||
Контролери польоту, для яких у нас немає посібників, зазвичай налаштовуються таким же чином (і майже завжди містять схожі посібники з налаштуванням).
|
||||
- [Peripherals](../peripherals/index.md) contains information about other peripherals, including [Airspeed Sensors](../sensor/airspeed.md).
|
||||
- [Airframes Reference > VTOL](../airframes/airframe_reference.md#vtol) explains which flight controller outputs must be connected to different flight controls for each airframe configuration:
|
||||
- Виберіть конфігурацію для вашого транспортного засобу, якщо вона існує, оскільки вона буде достатньо попередньо налаштована для польоту (можливо, потребує тільки дрібного налаштування).
|
||||
- В іншому випадку виберіть "Загальну конструкцію", яка відповідає вашому транспортному засобу.
|
||||
- Виберіть конфігурацію для вашого транспортного засобу, якщо вона існує, оскільки вона буде достатньо попередньо налаштована для польоту (можливо, потребує тільки дрібного налаштування).
|
||||
- В іншому випадку виберіть "Загальну конструкцію", яка відповідає вашому транспортному засобу.
|
||||
|
||||
In addition, build logs showing how others have set up different types of vehicles are provided as sub topics.
|
||||
For example see [FunCub QuadPlane](../frames_vtol/vtol_quadplane_fun_cub_vtol_pixhawk.md).
|
||||
|
||||
+119
-119
@@ -29,151 +29,151 @@ This consists of a single _C_ file and a _cmake_ definition (which tells the too
|
||||
|
||||
2. Create a new C file in that directory named **px4_simple_app.c**:
|
||||
|
||||
- Скопіюйте заголовок за замовчуванням у верхній частині сторінки.
|
||||
Це повинно бути присутнім у всіх розміщених файлах!
|
||||
- Скопіюйте заголовок за замовчуванням у верхній частині сторінки.
|
||||
Це повинно бути присутнім у всіх розміщених файлах!
|
||||
|
||||
```c
|
||||
/****************************************************************************
|
||||
*
|
||||
* Copyright (c) 2012-2022 PX4 Development Team. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
*
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in
|
||||
* the documentation and/or other materials provided with the
|
||||
* distribution.
|
||||
* 3. Neither the name PX4 nor the names of its contributors may be
|
||||
* used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
* POSSIBILITY OF SUCH DAMAGE.
|
||||
*
|
||||
****************************************************************************/
|
||||
```
|
||||
```c
|
||||
/****************************************************************************
|
||||
*
|
||||
* Copyright (c) 2012-2022 PX4 Development Team. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
*
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in
|
||||
* the documentation and/or other materials provided with the
|
||||
* distribution.
|
||||
* 3. Neither the name PX4 nor the names of its contributors may be
|
||||
* used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
* POSSIBILITY OF SUCH DAMAGE.
|
||||
*
|
||||
****************************************************************************/
|
||||
```
|
||||
|
||||
- Скопіюйте наступний код під заголовком за замовчуванням.
|
||||
Це повинно бути присутнім у всіх розміщених файлах!
|
||||
- Скопіюйте наступний код під заголовком за замовчуванням.
|
||||
Це повинно бути присутнім у всіх розміщених файлах!
|
||||
|
||||
```c
|
||||
/**
|
||||
* @file px4_simple_app.c
|
||||
* Minimal application example for PX4 autopilot
|
||||
*
|
||||
* @author Example User <mail@example.com>
|
||||
*/
|
||||
```c
|
||||
/**
|
||||
* @file px4_simple_app.c
|
||||
* Minimal application example for PX4 autopilot
|
||||
*
|
||||
* @author Example User <mail@example.com>
|
||||
*/
|
||||
|
||||
#include <px4_platform_common/log.h>
|
||||
#include <px4_platform_common/log.h>
|
||||
|
||||
__EXPORT int px4_simple_app_main(int argc, char *argv[]);
|
||||
__EXPORT int px4_simple_app_main(int argc, char *argv[]);
|
||||
|
||||
int px4_simple_app_main(int argc, char *argv[])
|
||||
{
|
||||
PX4_INFO("Hello Sky!");
|
||||
return OK;
|
||||
}
|
||||
```
|
||||
int px4_simple_app_main(int argc, char *argv[])
|
||||
{
|
||||
PX4_INFO("Hello Sky!");
|
||||
return OK;
|
||||
}
|
||||
```
|
||||
|
||||
:::tip
|
||||
The main function must be named `<module_name>_main` and exported from the module as shown.
|
||||
:::tip
|
||||
The main function must be named `<module_name>_main` and exported from the module as shown.
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
`PX4_INFO` is the equivalent of `printf` for the PX4 shell (included from **px4_platform_common/log.h**).
|
||||
There are different log levels: `PX4_INFO`, `PX4_WARN`, `PX4_ERR`, `PX4_DEBUG`.
|
||||
Warnings and errors are additionally added to the [ULog](../dev_log/ulog_file_format.md) and shown on [Flight Review](https://logs.px4.io/).
|
||||
:::tip
|
||||
`PX4_INFO` is the equivalent of `printf` for the PX4 shell (included from **px4_platform_common/log.h**).
|
||||
There are different log levels: `PX4_INFO`, `PX4_WARN`, `PX4_ERR`, `PX4_DEBUG`.
|
||||
Warnings and errors are additionally added to the [ULog](../dev_log/ulog_file_format.md) and shown on [Flight Review](https://logs.px4.io/).
|
||||
|
||||
:::
|
||||
|
||||
3. Create and open a new _cmake_ definition file named **CMakeLists.txt**.
|
||||
Скопіюйте текст нижче:
|
||||
Скопіюйте текст нижче:
|
||||
|
||||
```cmake
|
||||
############################################################################
|
||||
#
|
||||
# Copyright (c) 2015 PX4 Development Team. All rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or without
|
||||
# modification, are permitted provided that the following conditions
|
||||
# are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above copyright
|
||||
# notice, this list of conditions and the following disclaimer in
|
||||
# the documentation and/or other materials provided with the
|
||||
# distribution.
|
||||
# 3. Neither the name PX4 nor the names of its contributors may be
|
||||
# used to endorse or promote products derived from this software
|
||||
# without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
# POSSIBILITY OF SUCH DAMAGE.
|
||||
#
|
||||
############################################################################
|
||||
px4_add_module(
|
||||
MODULE examples__px4_simple_app
|
||||
MAIN px4_simple_app
|
||||
STACK_MAIN 2000
|
||||
SRCS
|
||||
px4_simple_app.c
|
||||
DEPENDS
|
||||
)
|
||||
```
|
||||
```cmake
|
||||
############################################################################
|
||||
#
|
||||
# Copyright (c) 2015 PX4 Development Team. All rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or without
|
||||
# modification, are permitted provided that the following conditions
|
||||
# are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above copyright
|
||||
# notice, this list of conditions and the following disclaimer in
|
||||
# the documentation and/or other materials provided with the
|
||||
# distribution.
|
||||
# 3. Neither the name PX4 nor the names of its contributors may be
|
||||
# used to endorse or promote products derived from this software
|
||||
# without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
# POSSIBILITY OF SUCH DAMAGE.
|
||||
#
|
||||
############################################################################
|
||||
px4_add_module(
|
||||
MODULE examples__px4_simple_app
|
||||
MAIN px4_simple_app
|
||||
STACK_MAIN 2000
|
||||
SRCS
|
||||
px4_simple_app.c
|
||||
DEPENDS
|
||||
)
|
||||
```
|
||||
|
||||
The `px4_add_module()` method builds a static library from a module description.
|
||||
The `px4_add_module()` method builds a static library from a module description.
|
||||
|
||||
- The `MODULE` block is the Firmware-unique name of the module (by convention the module name is prefixed by parent directories back to `src`).
|
||||
- The `MAIN` block lists the entry point of the module, which registers the command with NuttX so that it can be called from the PX4 shell or SITL console.
|
||||
- The `MODULE` block is the Firmware-unique name of the module (by convention the module name is prefixed by parent directories back to `src`).
|
||||
- The `MAIN` block lists the entry point of the module, which registers the command with NuttX so that it can be called from the PX4 shell or SITL console.
|
||||
|
||||
:::tip
|
||||
The `px4_add_module()` format is documented in [PX4-Autopilot/cmake/px4_add_module.cmake](https://github.com/PX4/PX4-Autopilot/blob/main/cmake/px4_add_module.cmake). <!-- NEED px4_version -->
|
||||
:::tip
|
||||
The `px4_add_module()` format is documented in [PX4-Autopilot/cmake/px4_add_module.cmake](https://github.com/PX4/PX4-Autopilot/blob/main/cmake/px4_add_module.cmake). <!-- NEED px4_version -->
|
||||
|
||||
:::
|
||||
|
||||
::: info
|
||||
If you specify `DYNAMIC` as an option to `px4_add_module`, a _shared library_ is created instead of a static library on POSIX platforms (these can be loaded without having to recompile PX4, and shared to others as binaries rather than source code).
|
||||
Your app will not become a builtin command, but ends up in a separate file called `examples__px4_simple_app.px4mod`.
|
||||
You can then run your command by loading the file at runtime using the `dyn` command: `dyn ./examples__px4_simple_app.px4mod`
|
||||
::: info
|
||||
If you specify `DYNAMIC` as an option to `px4_add_module`, a _shared library_ is created instead of a static library on POSIX platforms (these can be loaded without having to recompile PX4, and shared to others as binaries rather than source code).
|
||||
Your app will not become a builtin command, but ends up in a separate file called `examples__px4_simple_app.px4mod`.
|
||||
You can then run your command by loading the file at runtime using the `dyn` command: `dyn ./examples__px4_simple_app.px4mod`
|
||||
|
||||
:::
|
||||
|
||||
4. Create and open a new _Kconfig_ definition file named **Kconfig** and define your symbol for naming (see [Kconfig naming convention](../hardware/porting_guide_config.md#px4-kconfig-symbol-naming-convention)).
|
||||
Скопіюйте текст нижче:
|
||||
Скопіюйте текст нижче:
|
||||
|
||||
```
|
||||
menuconfig EXAMPLES_PX4_SIMPLE_APP
|
||||
bool "px4_simple_app"
|
||||
default n
|
||||
---help---
|
||||
Enable support for px4_simple_app
|
||||
```
|
||||
```
|
||||
menuconfig EXAMPLES_PX4_SIMPLE_APP
|
||||
bool "px4_simple_app"
|
||||
default n
|
||||
---help---
|
||||
Enable support for px4_simple_app
|
||||
```
|
||||
|
||||
## Побудуйте Програму/прошивку
|
||||
|
||||
|
||||
@@ -347,7 +347,7 @@ CONFIG_DRIVERS_RPM_CAPTURE=y
|
||||
Additionally, to enable the module:
|
||||
|
||||
- Set [ICE_EN](../advanced_config/parameter_reference.md#ICE_EN)
|
||||
to true and adjust the other `ICE_` module parameters according to your needs.
|
||||
to true and adjust the other `ICE_` module parameters according to your needs.
|
||||
- Set [RPM_CAP_ENABLE](../advanced_config/parameter_reference.md#RPM_CAP_ENABLE) to true.
|
||||
|
||||
The module outputs control signals for ignition, throttle, and choke,
|
||||
@@ -367,8 +367,8 @@ The state machine:
|
||||
|
||||
- Checks if [Rpm.msg](../msg_docs/Rpm.md) is updated to know if the engine is running
|
||||
- Allows for user inputs from:
|
||||
- AUX{N}
|
||||
- Arming state in [VehicleStatus.msg](../msg_docs/VehicleStatus.md)
|
||||
- AUX{N}
|
||||
- Arming state in [VehicleStatus.msg](../msg_docs/VehicleStatus.md)
|
||||
|
||||
The module publishes [InternalCombustionEngineControl.msg](../msg_docs/InternalCombustionEngineControl.md).
|
||||
|
||||
@@ -484,7 +484,7 @@ The normal log is always a superset of the mission log.
|
||||
The implementation uses two threads:
|
||||
|
||||
- The main thread, running at a fixed rate (or polling on a topic if started with -p) and checking for
|
||||
data updates
|
||||
data updates
|
||||
- The writer thread, writing data to the file
|
||||
|
||||
In between there is a write buffer with configurable size (and another fixed-size buffer for
|
||||
@@ -688,9 +688,9 @@ There are 2 environment variables used for configuration: `replay`, which must b
|
||||
the log file to be replayed. The second is the mode, specified via `replay_mode`:
|
||||
|
||||
- `replay_mode=ekf2`: specific EKF2 replay mode. It can only be used with the ekf2 module, but allows the replay
|
||||
to run as fast as possible.
|
||||
to run as fast as possible.
|
||||
- Generic otherwise: this can be used to replay any module(s), but the replay will be done with the same speed as the
|
||||
log was recorded.
|
||||
log was recorded.
|
||||
|
||||
The module is typically used together with uORB publisher rules, to specify which messages should be replayed.
|
||||
The replay module will just publish all messages that are found in the log. It also applies the parameters from
|
||||
@@ -842,12 +842,12 @@ it into a more usable form, and publishes it for the rest of the system.
|
||||
The provided functionality includes:
|
||||
|
||||
- Read the output from the sensor drivers (`SensorGyro`, etc.).
|
||||
If there are multiple of the same type, do voting and failover handling.
|
||||
Then apply the board rotation and temperature calibration (if enabled). And finally publish the data; one of the
|
||||
topics is `SensorCombined`, used by many parts of the system.
|
||||
If there are multiple of the same type, do voting and failover handling.
|
||||
Then apply the board rotation and temperature calibration (if enabled). And finally publish the data; one of the
|
||||
topics is `SensorCombined`, used by many parts of the system.
|
||||
- Make sure the sensor drivers get the updated calibration parameters (scale & offset) when the parameters change or
|
||||
on startup. The sensor drivers use the ioctl interface for parameter updates. For this to work properly, the
|
||||
sensor drivers must already be running when `sensors` is started.
|
||||
on startup. The sensor drivers use the ioctl interface for parameter updates. For this to work properly, the
|
||||
sensor drivers must already be running when `sensors` is started.
|
||||
- Do sensor consistency checks and publish the `SensorsStatusImu` topic.
|
||||
|
||||
### Імплементація
|
||||
|
||||
@@ -25,37 +25,37 @@ Other examples in Python can be found here: [integrationtests/python_src/px4_it/
|
||||
|
||||
1. Open the terminal and go to `~/catkin_ws/src` directory
|
||||
|
||||
```sh
|
||||
roscd # Should cd into ~/catkin_ws/devel
|
||||
cd ..
|
||||
cd src
|
||||
```
|
||||
```sh
|
||||
roscd # Should cd into ~/catkin_ws/devel
|
||||
cd ..
|
||||
cd src
|
||||
```
|
||||
|
||||
2. In the `~/catkin_ws/src` directory create a new package named `offboard_py` (in this case) with the `rospy` dependency:
|
||||
|
||||
```sh
|
||||
catkin_create_pkg offboard_py rospy
|
||||
```
|
||||
```sh
|
||||
catkin_create_pkg offboard_py rospy
|
||||
```
|
||||
|
||||
3. Build the new package in the `~/catkin_ws/` directory:
|
||||
|
||||
```sh
|
||||
cd .. # Assuming previous directory to be ~/catkin_ws/src
|
||||
catkin build
|
||||
source devel/setup.bash
|
||||
```
|
||||
```sh
|
||||
cd .. # Assuming previous directory to be ~/catkin_ws/src
|
||||
catkin build
|
||||
source devel/setup.bash
|
||||
```
|
||||
|
||||
4. Тепер ви можете мати можливість перейти до пакета, використовуючи:
|
||||
|
||||
```sh
|
||||
```
|
||||
```sh
|
||||
```
|
||||
|
||||
5. To store your Python files, create a new folder called `/scripts` on the package:
|
||||
|
||||
```sh
|
||||
mkdir scripts
|
||||
cd scripts
|
||||
```
|
||||
```sh
|
||||
mkdir scripts
|
||||
cd scripts
|
||||
```
|
||||
|
||||
## Код
|
||||
|
||||
|
||||
@@ -37,63 +37,63 @@ This is needed because, by default, you cannot arm a vehicle without a connectio
|
||||
|
||||
2. Створіть новий каталог робочого простору colcon і перейдіть до нього за допомогою:
|
||||
|
||||
```sh
|
||||
mkdir -p ~/ws_offboard_control/src/
|
||||
cd ~/ws_offboard_control/src/
|
||||
```
|
||||
```sh
|
||||
mkdir -p ~/ws_offboard_control/src/
|
||||
cd ~/ws_offboard_control/src/
|
||||
```
|
||||
|
||||
3. Clone the [px4_msgs](https://github.com/PX4/px4_msgs) repo to the `/src` directory (this repo is needed in every ROS 2 PX4 workspace!):
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
# checkout the matching release branch if not using PX4 main.
|
||||
```
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
# checkout the matching release branch if not using PX4 main.
|
||||
```
|
||||
|
||||
4. Clone the example repository [px4_ros_com](https://github.com/PX4/px4_ros_com) to the `/src` directory:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
|
||||
5. Source the ROS 2 development environment into the current terminal and compile the workspace using `colcon`:
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
::: tab humble
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
::: tab foxy
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
6. Source the `local_setup.bash`:
|
||||
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
|
||||
7. Запустіть приклад.
|
||||
|
||||
```
|
||||
ros2 run px4_ros_com offboard_control
|
||||
```
|
||||
```
|
||||
ros2 run px4_ros_com offboard_control
|
||||
```
|
||||
|
||||
Транспортний засіб повинен озброїтися, піднятися на 5 метрів і потім зачекати (вічно).
|
||||
|
||||
|
||||
@@ -128,21 +128,21 @@ You add some "boilerplate" code to regularly listen for changes in the [uORB Top
|
||||
|
||||
- **px4_platform_common/module_params.h** to get the `DEFINE_PARAMETERS` macro:
|
||||
|
||||
```cpp
|
||||
#include <px4_platform_common/module_params.h>
|
||||
```
|
||||
```cpp
|
||||
#include <px4_platform_common/module_params.h>
|
||||
```
|
||||
|
||||
- **parameter_update.h** to access the uORB `parameter_update` message:
|
||||
|
||||
```cpp
|
||||
#include <uORB/topics/parameter_update.h>
|
||||
```
|
||||
```cpp
|
||||
#include <uORB/topics/parameter_update.h>
|
||||
```
|
||||
|
||||
- **Subscription.hpp** for the uORB C++ subscription API:
|
||||
|
||||
```cpp
|
||||
#include <uORB/Subscription.hpp>
|
||||
```
|
||||
```cpp
|
||||
#include <uORB/Subscription.hpp>
|
||||
```
|
||||
|
||||
Derive your class from `ModuleParams`, and use `DEFINE_PARAMETERS` to specify a list of parameters and their associated parameter attributes.
|
||||
参数的名称必须与其参数元数据定义相同。
|
||||
@@ -194,7 +194,7 @@ void Module::parameters_update()
|
||||
- `_parameter_update_sub.updated()` tells us if there is _any_ update to the `param_update` uORB message (but not what parameter is affected).
|
||||
- If there has been "some" parameter updated, we copy the update into a `parameter_update_s` (`param_update`), to clear the pending update.
|
||||
- Then we call `ModuleParams::updateParams()`.
|
||||
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
|
||||
This "under the hood" updates all parameter attributes listed in our `DEFINE_PARAMETERS` list.
|
||||
|
||||
The parameter attributes (`_sys_autostart` and `_att_bias_max` in this case) can then be used to represent the parameters, and will be updated whenever the parameter value changes.
|
||||
|
||||
@@ -267,12 +267,12 @@ YAML meta data is intended as a full replacement for the **.c** definitions.
|
||||
- An example of YAML definitions being used can be found in the MAVLink parameter definitions: [/src/modules/mavlink/module.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/module.yaml).
|
||||
- 通过添加到 cmake 构建系统中注册一个 YAML 文件
|
||||
|
||||
```cmake
|
||||
MODULE_CONFIG
|
||||
module.yaml
|
||||
```
|
||||
```cmake
|
||||
MODULE_CONFIG
|
||||
module.yaml
|
||||
```
|
||||
|
||||
to the `px4_add_module` section of the `CMakeLists.txt` file of that module.
|
||||
to the `px4_add_module` section of the `CMakeLists.txt` file of that module.
|
||||
|
||||
#### 多实例(模块化)YAML 元数据
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ This guide walks through the process of setting up the board and connecting to P
|
||||
You will temporarily need the following hardware in order to log into your Jetson and get its IP address, after which you will be able to log in via SSH:
|
||||
|
||||
- External display.
|
||||
If your display doesn't have a mini HDMI connector you will also need a [Mini HDMI to HDMI converter](https://a.co/d/6N815N9) if your external display has HDMI input
|
||||
If your display doesn't have a mini HDMI connector you will also need a [Mini HDMI to HDMI converter](https://a.co/d/6N815N9) if your external display has HDMI input
|
||||
- Ethernet cable
|
||||
- Mouse and keyboard (the baseboard has 4 USB ports exposed from Jetson, two of which are USB 3.0)
|
||||
|
||||
@@ -45,11 +45,11 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- 尺寸
|
||||
|
||||
- 126 x 80 x 45mm (with Jetson Orin NX + Heatsink/Fan & FC Module)
|
||||
- 126 x 80 x 22.9mm (without Jetson and FC Module)
|
||||
- 126 x 80 x 45mm (with Jetson Orin NX + Heatsink/Fan & FC Module)
|
||||
- 126 x 80 x 22.9mm (without Jetson and FC Module)
|
||||
|
||||
- 重量
|
||||
- 190g (with Jetson, Heatsink, Flight Controller, M.2 SSD, M.2 Wi-Fi Module)
|
||||
- 190g (with Jetson, Heatsink, Flight Controller, M.2 SSD, M.2 Wi-Fi Module)
|
||||
|
||||
:::
|
||||
|
||||
@@ -57,67 +57,67 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- 2x Gigabit Ethernet Port
|
||||
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- Ethernet Switch powered by the same circuit as the Pixhawk
|
||||
- 8-pin JST-GH
|
||||
- RJ45
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- Ethernet Switch powered by the same circuit as the Pixhawk
|
||||
- 8-pin JST-GH
|
||||
- RJ45
|
||||
|
||||
- 2x MIPI CSI Camera Inputs
|
||||
|
||||
- 4 Lanes each
|
||||
- 22-Pin Raspberry Pi Cam FFC
|
||||
- 4 Lanes each
|
||||
- 22-Pin Raspberry Pi Cam FFC
|
||||
|
||||
- 2x USB 3.0 Host Port
|
||||
|
||||
- USB A
|
||||
- 5A Current Limit
|
||||
- USB A
|
||||
- 5A Current Limit
|
||||
|
||||
- 2x USB 2.0 Host Port
|
||||
|
||||
- 5-Pin JST-GH
|
||||
- 0A Current Limit
|
||||
- 5-Pin JST-GH
|
||||
- 0A Current Limit
|
||||
|
||||
- USB 2.0 for Programming/Debugging
|
||||
|
||||
- USB-C
|
||||
- USB-C
|
||||
|
||||
- 2 Key M 2242/2280 for NVMe SSD
|
||||
|
||||
- PCIEx4
|
||||
- PCIEx4
|
||||
|
||||
- 2 Key E 2230 for WiFi/BT
|
||||
|
||||
- PCIEx2
|
||||
- USB
|
||||
- UART
|
||||
- I2S
|
||||
- PCIEx2
|
||||
- USB
|
||||
- UART
|
||||
- I2S
|
||||
|
||||
- Mini HDMI Out
|
||||
|
||||
- 4x GPIO
|
||||
|
||||
- 6-pin JST-GH
|
||||
- 6-pin JST-GH
|
||||
|
||||
- CAN Port
|
||||
|
||||
- Connected to Autopilot's CAN2 (4 Pin JST-GH)
|
||||
- Connected to Autopilot's CAN2 (4 Pin JST-GH)
|
||||
|
||||
- SPI Port
|
||||
|
||||
- 7-Pin JST-GH
|
||||
- 7-Pin JST-GH
|
||||
|
||||
- I2C Port
|
||||
|
||||
- 4-Pin JST-GH
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- I2S Port
|
||||
|
||||
- 7-Pin JST-GH
|
||||
- 7-Pin JST-GH
|
||||
|
||||
- 2x UART Port
|
||||
|
||||
- 1 for debug
|
||||
- 1 connected to Autopilot's telem2
|
||||
- 1 for debug
|
||||
- 1 connected to Autopilot's telem2
|
||||
|
||||
- Fan Power Port
|
||||
|
||||
@@ -129,13 +129,13 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- Pixhawk Autopilot Bus Interface
|
||||
|
||||
- 100 Pin Hirose DF40
|
||||
- 50 Pin Hirose DF40
|
||||
- 100 Pin Hirose DF40
|
||||
- 50 Pin Hirose DF40
|
||||
|
||||
- Redundant Digital Power Module Inputs
|
||||
|
||||
- I2C Power Monitor Support
|
||||
- 2x 6-Pin Molex CLIK-Mate
|
||||
- I2C Power Monitor Support
|
||||
- 2x 6-Pin Molex CLIK-Mate
|
||||
|
||||
- Power Path Selector
|
||||
|
||||
@@ -143,68 +143,68 @@ This information comes from the [Holybro Pixhawk-Jetson Baseboard Documentation]
|
||||
|
||||
- 额定电压
|
||||
|
||||
- Max input voltage: 6V
|
||||
- USB 电源输入:4.75~5.25V
|
||||
- Max input voltage: 6V
|
||||
- USB 电源输入:4.75~5.25V
|
||||
|
||||
- Full GPS Plus Safety Switch Port
|
||||
|
||||
- 10-Pin JST-GH
|
||||
- 10-Pin JST-GH
|
||||
|
||||
- Secondary (GPS2) Port
|
||||
|
||||
- 6-Pin JST-GH
|
||||
- 6-Pin JST-GH
|
||||
|
||||
- 2x CAN Ports
|
||||
|
||||
- 4-Pin JST-GH
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- 3x Telemetry Ports with Flow Control
|
||||
|
||||
- 2x 6-Pin JST-GH
|
||||
- 1 is connected to Jetson's `UART1` Port
|
||||
- 2x 6-Pin JST-GH
|
||||
- 1 is connected to Jetson's `UART1` Port
|
||||
|
||||
- 16 PWM Outputs
|
||||
|
||||
- 2x 10-Pin JST-GH
|
||||
- 2x 10-Pin JST-GH
|
||||
|
||||
- UART4 & I2C Port
|
||||
|
||||
- 6-Pin JST-GH
|
||||
- 6-Pin JST-GH
|
||||
|
||||
- 2x Gigabit Ethernet Port
|
||||
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- 8-Pin JST-GH
|
||||
- RJ45
|
||||
- Connected to both Jetson & Autopilot via Ethernet switch (RTL8367S)
|
||||
- 8-Pin JST-GH
|
||||
- RJ45
|
||||
|
||||
- AD & IO
|
||||
|
||||
- 8-Pin JST-GH
|
||||
- 8-Pin JST-GH
|
||||
|
||||
- USB 2.0
|
||||
|
||||
- USB-C
|
||||
- 4-Pin JST-GH
|
||||
- USB-C
|
||||
- 4-Pin JST-GH
|
||||
|
||||
- DSM Input
|
||||
|
||||
- 3-Pin JST-ZH 1.5mm Pitch
|
||||
- 3-Pin JST-ZH 1.5mm Pitch
|
||||
|
||||
- RC In
|
||||
|
||||
- PPM/SBUS
|
||||
- 5-Pin JST-GH
|
||||
- PPM/SBUS
|
||||
- 5-Pin JST-GH
|
||||
|
||||
- SPI Port
|
||||
|
||||
- External Sensor Bus (SPI5)
|
||||
- 11-Pin JST-GH
|
||||
- External Sensor Bus (SPI5)
|
||||
- 11-Pin JST-GH
|
||||
|
||||
- 2x Debug Port
|
||||
|
||||
- 1 for FMU
|
||||
- 1 for IO
|
||||
- 10-Pin JST-SH
|
||||
- 1 for FMU
|
||||
- 1 for IO
|
||||
- 10-Pin JST-SH
|
||||
|
||||
:::
|
||||
|
||||
@@ -218,7 +218,7 @@ The Jetson has separate input power circuitry from the Pixhawk autopilot:
|
||||
- 8V/3A Minimum (Depends on Usage and Peripherals)
|
||||
- Voltage Rating: 7-21V (3S-4S)
|
||||
- Jetson Baseboard onboard BEC is rated for 7-21V (3S-4S).
|
||||
Note that the external UBEC-12A can be used for applications above 4S
|
||||
Note that the external UBEC-12A can be used for applications above 4S
|
||||
|
||||
During development using the following wired power supply is recommended:
|
||||
|
||||
@@ -698,7 +698,7 @@ On the following screen, confirm your selected device:
|
||||
|
||||
- Choose `Pre-config` for the OEM Configuration (this will skip Ubuntu first time setup screens after reboot).
|
||||
- Choose your preferred username and password (and write them down).
|
||||
These will be used as your login credentials to Jetpack.
|
||||
These will be used as your login credentials to Jetpack.
|
||||
- Choose `NVMe` as the storage device because the board has separate SSD for storage.
|
||||
|
||||

|
||||
@@ -922,95 +922,95 @@ These instructions approximately mirror the [PX4 Ethernet setup](../advanced_con
|
||||
Next we modify the Jetson IP address to be on the same network as the Pixhawk:
|
||||
|
||||
1. Make sure `netplan` is installed.
|
||||
You can check by running the following command:
|
||||
You can check by running the following command:
|
||||
|
||||
```sh
|
||||
netplan -h
|
||||
```
|
||||
```sh
|
||||
netplan -h
|
||||
```
|
||||
|
||||
If not, install it using the commands:
|
||||
If not, install it using the commands:
|
||||
|
||||
```sh
|
||||
sudo apt update
|
||||
sudo apt install netplan.io
|
||||
```
|
||||
```sh
|
||||
sudo apt update
|
||||
sudo apt install netplan.io
|
||||
```
|
||||
|
||||
2. Check `system_networkd` is running:
|
||||
|
||||
```sh
|
||||
sudo systemctl status systemd-networkd
|
||||
```
|
||||
```sh
|
||||
sudo systemctl status systemd-networkd
|
||||
```
|
||||
|
||||
You should see output like below if it is active:
|
||||
You should see output like below if it is active:
|
||||
|
||||
```sh
|
||||
● systemd-networkd.service - Network Configuration
|
||||
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2024-09-11 23:32:44 EDT; 23min ago
|
||||
TriggeredBy: ● systemd-networkd.socket
|
||||
Docs: man:systemd-networkd.service(8)
|
||||
Main PID: 2452 (systemd-network)
|
||||
Status: "Processing requests..."
|
||||
Tasks: 1 (limit: 18457)
|
||||
Memory: 2.7M
|
||||
CPU: 157ms
|
||||
CGroup: /system.slice/systemd-networkd.service
|
||||
└─2452 /lib/systemd/systemd-networkd
|
||||
```sh
|
||||
● systemd-networkd.service - Network Configuration
|
||||
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2024-09-11 23:32:44 EDT; 23min ago
|
||||
TriggeredBy: ● systemd-networkd.socket
|
||||
Docs: man:systemd-networkd.service(8)
|
||||
Main PID: 2452 (systemd-network)
|
||||
Status: "Processing requests..."
|
||||
Tasks: 1 (limit: 18457)
|
||||
Memory: 2.7M
|
||||
CPU: 157ms
|
||||
CGroup: /system.slice/systemd-networkd.service
|
||||
└─2452 /lib/systemd/systemd-networkd
|
||||
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: lo: Gained carrier
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: eth0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: Enumeration completed
|
||||
Sep 11 23:32:44 ubuntu systemd[1]: Started Network Configuration.
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Connected WiFi access point: Verizon_7YLWWD (78:67:0e:ea:a6:0>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
```
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: lo: Gained carrier
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: eth0: Gained IPv6LL
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: Enumeration completed
|
||||
Sep 11 23:32:44 ubuntu systemd[1]: Started Network Configuration.
|
||||
Sep 11 23:32:44 ubuntu systemd-networkd[2452]: wlan0: Connected WiFi access point: Verizon_7YLWWD (78:67:0e:ea:a6:0>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: Re-configuring with /run/systemd/network/10-netplan-eth0.netwo>
|
||||
Sep 11 23:34:16 ubuntu systemd-networkd[2452]: eth0: DHCPv6 lease lost
|
||||
```
|
||||
|
||||
If `system_networkd` is not running, it can be enabled using:
|
||||
If `system_networkd` is not running, it can be enabled using:
|
||||
|
||||
```sh
|
||||
sudo systemctl start systemd-networkd
|
||||
sudo systemctl enable systemd-networkd
|
||||
```
|
||||
```sh
|
||||
sudo systemctl start systemd-networkd
|
||||
sudo systemctl enable systemd-networkd
|
||||
```
|
||||
|
||||
3. Open the Netplan configuration file (so we can set up a static IP for the Jetson).
|
||||
|
||||
The Netplan configuration file is usually located in the `/etc/netplan/` directory and named something like `01-netcfg.yaml` (the name can vary).
|
||||
Below we use `nano` to open the file, but you can use your preferred text editor:
|
||||
The Netplan configuration file is usually located in the `/etc/netplan/` directory and named something like `01-netcfg.yaml` (the name can vary).
|
||||
Below we use `nano` to open the file, but you can use your preferred text editor:
|
||||
|
||||
```sh
|
||||
sudo nano /etc/netplan/01-netcfg.yaml
|
||||
```
|
||||
```sh
|
||||
sudo nano /etc/netplan/01-netcfg.yaml
|
||||
```
|
||||
|
||||
4. Modify the yaml configuration, by overwriting the contents with the following information and then saving:
|
||||
|
||||
```sh
|
||||
network:
|
||||
version: 2
|
||||
renderer: networkd
|
||||
ethernets:
|
||||
eth0:
|
||||
dhcp4: no
|
||||
addresses:
|
||||
- 10.41.10.1/24
|
||||
routes:
|
||||
- to: 0.0.0.0/0
|
||||
via: 10.41.10.254
|
||||
nameservers:
|
||||
addresses:
|
||||
- 10.41.10.254
|
||||
```
|
||||
```sh
|
||||
network:
|
||||
version: 2
|
||||
renderer: networkd
|
||||
ethernets:
|
||||
eth0:
|
||||
dhcp4: no
|
||||
addresses:
|
||||
- 10.41.10.1/24
|
||||
routes:
|
||||
- to: 0.0.0.0/0
|
||||
via: 10.41.10.254
|
||||
nameservers:
|
||||
addresses:
|
||||
- 10.41.10.254
|
||||
```
|
||||
|
||||
This gives the Jetson a static IP address on the Ethernet interface of `10.41.10.1` .
|
||||
This gives the Jetson a static IP address on the Ethernet interface of `10.41.10.1` .
|
||||
|
||||
5. Apply the changes using the following command:
|
||||
|
||||
```sh
|
||||
sudo netplan apply
|
||||
```
|
||||
```sh
|
||||
sudo netplan apply
|
||||
```
|
||||
|
||||
The Pixhawk Ethernet address is set to `10.41.10.2` by default, which is on the same subnet.
|
||||
We can test our changes above by pinging the Pixhawk from within the Jetson terminal:
|
||||
@@ -1221,15 +1221,15 @@ Assuming the client is set up as defined above:
|
||||
|
||||
- (Serial connection) Start the agent on `/dev/ttyTHS1`:
|
||||
|
||||
```sh
|
||||
sudo MicroXRCEAgent serial --dev /dev/ttyTHS1 -b 921600
|
||||
```
|
||||
```sh
|
||||
sudo MicroXRCEAgent serial --dev /dev/ttyTHS1 -b 921600
|
||||
```
|
||||
|
||||
- (Ethernet) Start the agent on UDP port `8888`:
|
||||
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
```sh
|
||||
MicroXRCEAgent udp4 -p 8888
|
||||
```
|
||||
|
||||
If your agent and client are connected and no nodes are running, you should see output similar to this in the Agent terminal:
|
||||
|
||||
|
||||
@@ -71,42 +71,42 @@ Explanations and requirements:
|
||||
- `/* EVENT`: This tag indicates that a comment defines metadata for the following event.
|
||||
|
||||
- **event_name**: the event name (`events::ID(event_name)`).
|
||||
- must be unique within the whole source code of PX4.
|
||||
As a general convention, prefix it with the module name, or the source file for larger modules.
|
||||
- must be a valid variable name, i.e. must not contain spaces, colons, etc.
|
||||
- from that name, a 24 bit event ID is derived using a hash function.
|
||||
This means as long as the event name stays the same, so will the ID.
|
||||
- must be unique within the whole source code of PX4.
|
||||
As a general convention, prefix it with the module name, or the source file for larger modules.
|
||||
- must be a valid variable name, i.e. must not contain spaces, colons, etc.
|
||||
- from that name, a 24 bit event ID is derived using a hash function.
|
||||
This means as long as the event name stays the same, so will the ID.
|
||||
|
||||
- **Log Level**:
|
||||
|
||||
- valid log levels are the same as used in the MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY) enum.
|
||||
In order of descending importance these are:
|
||||
- valid log levels are the same as used in the MAVLink [MAV_SEVERITY](https://mavlink.io/en/messages/common.html#MAV_SEVERITY) enum.
|
||||
In order of descending importance these are:
|
||||
|
||||
```plain
|
||||
Emergency,
|
||||
Alert,
|
||||
Critical,
|
||||
Error,
|
||||
Warning,
|
||||
Notice,
|
||||
Info,
|
||||
Debug,
|
||||
Disabled,
|
||||
```
|
||||
```plain
|
||||
Emergency,
|
||||
Alert,
|
||||
Critical,
|
||||
Error,
|
||||
Warning,
|
||||
Notice,
|
||||
Info,
|
||||
Debug,
|
||||
Disabled,
|
||||
```
|
||||
|
||||
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
|
||||
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
|
||||
There are cases it makes sense to have two different log levels.
|
||||
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
|
||||
- Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`.
|
||||
For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases.
|
||||
There are cases it makes sense to have two different log levels.
|
||||
For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`.
|
||||
|
||||
- **Event Message**:
|
||||
- Single-line, short message of the event.
|
||||
It may contain template placeholders for arguments (e.g. `{1}`). For more information see below.
|
||||
- Single-line, short message of the event.
|
||||
It may contain template placeholders for arguments (e.g. `{1}`). For more information see below.
|
||||
|
||||
- **Event Description**:
|
||||
- Detailed, optional event description.
|
||||
- Can be multiple lines/paragraphs.
|
||||
- It may contain template placeholders for arguments (e.g. `{2}`) and supported tags (see below)
|
||||
- Detailed, optional event description.
|
||||
- Can be multiple lines/paragraphs.
|
||||
- It may contain template placeholders for arguments (e.g. `{2}`) and supported tags (see below)
|
||||
|
||||
#### Arguments and Enums
|
||||
|
||||
@@ -125,35 +125,35 @@ Text format for event message description:
|
||||
|
||||
- characters can be escaped with \\
|
||||
|
||||
These have to be escaped: '\\\\', '\\<', '\\{'.
|
||||
These have to be escaped: '\\\\', '\\<', '\\{'.
|
||||
|
||||
- supported tags:
|
||||
|
||||
- Profiles: `<profile name="[!]NAME">CONTENT</profile>`
|
||||
- Profiles: `<profile name="[!]NAME">CONTENT</profile>`
|
||||
|
||||
`CONTENT` will only be shown if the name matches the configured profile.
|
||||
This can be used for example to hide developer information from end-users.
|
||||
`CONTENT` will only be shown if the name matches the configured profile.
|
||||
This can be used for example to hide developer information from end-users.
|
||||
|
||||
- URLs: `<a [href="URL"]>CONTENT</a>`.
|
||||
If `href` is not set, use `CONTENT` as `URL` (i.e.`<a>https://docs.px4.io</a>` is interpreted as `<a href="https://docs.px4.io">https://docs.px4.io</a>`)
|
||||
- URLs: `<a [href="URL"]>CONTENT</a>`.
|
||||
If `href` is not set, use `CONTENT` as `URL` (i.e.`<a>https://docs.px4.io</a>` is interpreted as `<a href="https://docs.px4.io">https://docs.px4.io</a>`)
|
||||
|
||||
- Parameters: `<param>PARAM_NAME</param>`
|
||||
- Parameters: `<param>PARAM_NAME</param>`
|
||||
|
||||
- no nested tags of the same type are allowed
|
||||
- no nested tags of the same type are allowed
|
||||
|
||||
- arguments: template placeholders that follow python syntax, with 1-based indexing (instead of 0)
|
||||
|
||||
- general form: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
|
||||
- general form: `{ARG_IDX[:.NUM_DECIMAL_DIGITS][UNIT]}`
|
||||
|
||||
UNIT:
|
||||
UNIT:
|
||||
|
||||
- m: horizontal distance in meters
|
||||
- m_v: vertical distance in meters
|
||||
- m^2: area in m^2
|
||||
- m/s: speed in m/s
|
||||
- C: temperature in degrees celsius
|
||||
- m: horizontal distance in meters
|
||||
- m_v: vertical distance in meters
|
||||
- m^2: area in m^2
|
||||
- m/s: speed in m/s
|
||||
- C: temperature in degrees celsius
|
||||
|
||||
- `NUM_DECIMAL_DIGITS` only makes sense for real number arguments.
|
||||
- `NUM_DECIMAL_DIGITS` only makes sense for real number arguments.
|
||||
|
||||
## 日志
|
||||
|
||||
|
||||
+14
-14
@@ -38,9 +38,9 @@ A frame configuration can define everything about a vehicle, from it's geometry
|
||||
When you're bringing up a new vehicle though, the frame will usually contain a fairly minimal configuration:
|
||||
|
||||
- Frames named with "Generic" define the vehicle type, number of rotors, and "placeholder" rotor positions.
|
||||
After selecting the airframe you define the actual geometry and then configure outputs.
|
||||
After selecting the airframe you define the actual geometry and then configure outputs.
|
||||
- Frames named with model/brand will define the vehicle type, number of rotors, actual rotor positions, and motor directions.
|
||||
After selecting the airframe you usually still have to configure outputs.
|
||||
After selecting the airframe you usually still have to configure outputs.
|
||||
|
||||
:::
|
||||
|
||||
@@ -52,7 +52,7 @@ This ensures that all ESC provide exactly the same output for a given input (ide
|
||||
The final step is [Motor Configuration](../config/actuators.md#motor-configuration):
|
||||
|
||||
- [Reverse any motors](../config/actuators.md#reversing-motors) that don't match the spin direction configured in the Geometry.
|
||||
For DShot ESC you can do this through the Acuator Testing UI.
|
||||
For DShot ESC you can do this through the Acuator Testing UI.
|
||||
- PWM, OneShot, and CAN ESC, set the motor input limits for disarmed, low and high speed (not needed for DShot ESC)
|
||||
|
||||
相关章节:
|
||||
@@ -123,14 +123,14 @@ Tuning is the final step, carried out only after most other setup and configurat
|
||||
|
||||
- [Autotune](../config/autotune_mc.md) — Automates tuning PX4 rate and attitude controllers (recommended).
|
||||
|
||||
::: info
|
||||
Automatic tuning works on frames that have reasonable authority and dynamics around all the body axes.
|
||||
It has primarily been tested on racing quads and X500, and is expected to be less effective on tricopters with a tiltable rotor.
|
||||
::: info
|
||||
Automatic tuning works on frames that have reasonable authority and dynamics around all the body axes.
|
||||
It has primarily been tested on racing quads and X500, and is expected to be less effective on tricopters with a tiltable rotor.
|
||||
|
||||
Manual tuning using these guides are only needed if there is a problem with autotune:
|
||||
Manual tuning using these guides are only needed if there is a problem with autotune:
|
||||
|
||||
- [MC PID Tuning (Manual/Basic)](../config_mc/pid_tuning_guide_multicopter_basic.md) — Manual tuning basic how to.
|
||||
- [MC PID Tuning Guide (Manual/Detailed)](../config_mc/pid_tuning_guide_multicopter.md) — Manual tuning with detailed explanation.
|
||||
- [MC PID Tuning (Manual/Basic)](../config_mc/pid_tuning_guide_multicopter_basic.md) — Manual tuning basic how to.
|
||||
- [MC PID Tuning Guide (Manual/Detailed)](../config_mc/pid_tuning_guide_multicopter.md) — Manual tuning with detailed explanation.
|
||||
|
||||
|
||||
:::
|
||||
@@ -138,7 +138,7 @@ Tuning is the final step, carried out only after most other setup and configurat
|
||||
- [MC Filter/Control Latency Tuning](../config_mc/filter_tuning.md) — Trade off control latency and noise filtering.
|
||||
|
||||
- [MC Setpoint Tuning (Trajectory Generator)](../config_mc/mc_trajectory_tuning.md)
|
||||
- [MC Jerk-limited Type Trajectory](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
- [MC Jerk-limited Type Trajectory](../config_mc/mc_jerk_limited_type_trajectory.md)
|
||||
|
||||
- [Multicopter Racer Setup](../config_mc/racer_setup.md)
|
||||
|
||||
@@ -167,7 +167,7 @@ Yes but it must be physically feasible. E.g. if you make a quadrotor where all m
|
||||
- [飞控外设](../peripherals/index.md) - 设置特定传感器、可选传感器、执行器等。
|
||||
- [Advanced Configuration](../advanced_config/index.md) - Factory/OEM calibration, configuring advanced features, less-common configuration.
|
||||
- Vehicle-Centric Config/Tuning:
|
||||
- **Multicopter Config/Tuning**
|
||||
- [直升机配置/调参](../config_heli/index.md)
|
||||
- [Fixed Wing Config/Tuning](../config_fw/index.md)
|
||||
- [VTOL 配置/调参](../config_vtol/index.md)
|
||||
- **Multicopter Config/Tuning**
|
||||
- [直升机配置/调参](../config_heli/index.md)
|
||||
- [Fixed Wing Config/Tuning](../config_fw/index.md)
|
||||
- [VTOL 配置/调参](../config_vtol/index.md)
|
||||
|
||||
@@ -26,13 +26,13 @@ The ARF kit can be used with most flight controllers supported by PX4.
|
||||
The Holybro [X500 V2 Kit](https://holybro.com/collections/x500-kits) includes almost all the required components:
|
||||
|
||||
- X500V2 Frame Kit
|
||||
- Body - Full Carbon Fiber Top & Bottom plate (144 x 144mm, 2mm thick)
|
||||
- Arm - High strength & ultra-lightweight 16mm carbon fiber tubes
|
||||
- Landing gear - 16mm & 10mm diameter carbon fiber tubes
|
||||
- Platform board - With mounting holes for GPS & popular companion computer
|
||||
- Dual 10mm Ø rod x 250 mm long rail mounting system
|
||||
- Battery mount with two Battery Straps
|
||||
- Hand tools for installation
|
||||
- Body - Full Carbon Fiber Top & Bottom plate (144 x 144mm, 2mm thick)
|
||||
- Arm - High strength & ultra-lightweight 16mm carbon fiber tubes
|
||||
- Landing gear - 16mm & 10mm diameter carbon fiber tubes
|
||||
- Platform board - With mounting holes for GPS & popular companion computer
|
||||
- Dual 10mm Ø rod x 250 mm long rail mounting system
|
||||
- Battery mount with two Battery Straps
|
||||
- Hand tools for installation
|
||||
- Holybro Motors - 2216 KV880 x6 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
- Holybro BLHeli S ESC 20A x4 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
- Propellers - 1045 x4 (superseded - check [spare parts list](https://holybro.com/products/spare-parts-x500-v2-kit) for current version).
|
||||
@@ -93,92 +93,92 @@ Tools are included to do the assembly, however you may need:
|
||||
Estimate time to assemble is 55 min (25 minutes for frame, 30 minutes for autopilot installation/configuration)
|
||||
|
||||
1. Start by assembling the payload & battery holder.
|
||||
Push the rubbers into grippers (Do not use sharp items to push them in!).
|
||||
Next, pass the holders through the holder bars with the battery holder bases as Figure 3.
|
||||
Push the rubbers into grippers (Do not use sharp items to push them in!).
|
||||
Next, pass the holders through the holder bars with the battery holder bases as Figure 3.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 2_: Payload holder components
|
||||
_Figure 2_: Payload holder components
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 3_: Payload holder assembled
|
||||
_Figure 3_: Payload holder assembled
|
||||
|
||||
2. The next is to go for attaching the bottom plate to the payload holder.
|
||||
|
||||
You will need the parts as shown in Figure 4.
|
||||
Then mount the base for power distribution board using nylon nuts as Figure 5.
|
||||
Finally using 8 hex screws you can join the bottom plate to the payload holder (Figure 7)
|
||||
You will need the parts as shown in Figure 4.
|
||||
Then mount the base for power distribution board using nylon nuts as Figure 5.
|
||||
Finally using 8 hex screws you can join the bottom plate to the payload holder (Figure 7)
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 4_: Needed Materials
|
||||
_Figure 4_: Needed Materials
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 5_: PDB mount base
|
||||
_Figure 5_: PDB mount base
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 6_: Mounted pdb with nylon nuts
|
||||
_Figure 6_: Mounted pdb with nylon nuts
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 7_: Mounted Plate on payload holder
|
||||
_Figure 7_: Mounted Plate on payload holder
|
||||
|
||||
3. Let's gather the stuff needed for mounting landing gear as Figure 8.
|
||||
Use the hex screws to join landing gears to the bottom plate.
|
||||
You also need to open three hex screws on each of the leg stands so you can push them into carbon fiber pipes.
|
||||
Do not forget to tighten them back again.
|
||||
Use the hex screws to join landing gears to the bottom plate.
|
||||
You also need to open three hex screws on each of the leg stands so you can push them into carbon fiber pipes.
|
||||
Do not forget to tighten them back again.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 8_: Required parts for landing gear attachment
|
||||
_Figure 8_: Required parts for landing gear attachment
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 9_: Landing gear attachment to the body
|
||||
_Figure 9_: Landing gear attachment to the body
|
||||
|
||||
4. We will gather all the arms now to mount the top plate.
|
||||
Please pay attention that the motor numbers on arms are a match with the ones mentioned on the top plate.
|
||||
Fortunately, motors are mounted and ESCs have been connected in advance.
|
||||
Start by passing through all the screws as you have the arms fixed in their own places (They have a guide as shown in Figure 11 to ensure they are in place) and tighten all nylon nuts a bit.
|
||||
Then you can connect XT30 power connectors to the power board.
|
||||
Please keep in mind that the signal wires have to be passed through the top plate such that we can connect them later to Pixhawk.
|
||||
Please pay attention that the motor numbers on arms are a match with the ones mentioned on the top plate.
|
||||
Fortunately, motors are mounted and ESCs have been connected in advance.
|
||||
Start by passing through all the screws as you have the arms fixed in their own places (They have a guide as shown in Figure 11 to ensure they are in place) and tighten all nylon nuts a bit.
|
||||
Then you can connect XT30 power connectors to the power board.
|
||||
Please keep in mind that the signal wires have to be passed through the top plate such that we can connect them later to Pixhawk.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/needed_stuff_top_plate.png" width="700" title="Arms and top plate materials">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/needed_stuff_top_plate.png" width="700" title="Arms and top plate materials">
|
||||
|
||||
_Figure 10_: Connecting arms needed materials.
|
||||
_Figure 10_: Connecting arms needed materials.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/guide_for_arm_mount.png" width="700" title="Guide for the arms mount">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/guide_for_arm_mount.png" width="700" title="Guide for the arms mount">
|
||||
|
||||
_Figure 11_: Guide for the arms mount
|
||||
_Figure 11_: Guide for the arms mount
|
||||
|
||||
5. Tighten all 16 screws and nuts by using both hex wrench and nut driver.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 12_: Mounted top plate
|
||||
_Figure 12_: Mounted top plate
|
||||
|
||||
6. Next you can mount your pixhawk on the top plate by using the stickers.
|
||||
It is recommended to have the direction of your Pixhawk's arrow the same as the one mentioned on the top plate.
|
||||
It is recommended to have the direction of your Pixhawk's arrow the same as the one mentioned on the top plate.
|
||||
|
||||

|
||||

|
||||
|
||||
_Figure 13_: Sticker tapes on Pixhawk
|
||||
_Figure 13_: Sticker tapes on Pixhawk
|
||||
|
||||
7. If you want to mount the GPS on the companion computer plate, you can now secure the GPS mount onto it using 4 screws and nuts.
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/gps_mount_plate.png" width="400" title="Secure GPS mount onto companion plate">
|
||||
<img src="../../assets/airframes/multicopter/x500_v2_holybro_pixhawk5x/gps_mount_plate.png" width="400" title="Secure GPS mount onto companion plate">
|
||||
|
||||
_Figure 14_: Secure GPS mount onto companion plate
|
||||
_Figure 14_: Secure GPS mount onto companion plate
|
||||
|
||||
8. Use the tape and stick the GPS to the top of the GPS mast and mount the GPS mast.
|
||||
Make sure the arrow on the gps is pointing forward (Figure 15).
|
||||
Make sure the arrow on the gps is pointing forward (Figure 15).
|
||||
|
||||
<img src="../../assets/airframes/multicopter/x500_holybro_pixhawk4/gps2.jpg" width="400" title="Figure 16: GPS and mast">
|
||||
<img src="../../assets/airframes/multicopter/x500_holybro_pixhawk4/gps2.jpg" width="400" title="Figure 16: GPS and mast">
|
||||
|
||||
_Figure 15_: GPS and mast
|
||||
_Figure 15_: GPS and mast
|
||||
|
||||
9. Finally, you can connect the Pixhawk interfaces such as telemetry radio to 'TELEM1' and motors signal cables accordingly.
|
||||
|
||||
@@ -204,14 +204,14 @@ First update the firmware, airframe, and actuator mappings:
|
||||
|
||||
- [Airframe](../config/airframe.md)
|
||||
|
||||
You will need to select the _Holybro X500 V2_ airframe (**Quadrotor x > Holybro 500 V2**)
|
||||
You will need to select the _Holybro X500 V2_ airframe (**Quadrotor x > Holybro 500 V2**)
|
||||
|
||||

|
||||

|
||||
|
||||
- [Actuators](../config/actuators.md)
|
||||
- You should not need to update the vehicle geometry (as this is a preconfigured airframe).
|
||||
- Assign actuator functions to outputs to match your wiring.
|
||||
- Test the configuration using the sliders.
|
||||
- You should not need to update the vehicle geometry (as this is a preconfigured airframe).
|
||||
- Assign actuator functions to outputs to match your wiring.
|
||||
- Test the configuration using the sliders.
|
||||
|
||||
Then perform the mandatory setup/calibration:
|
||||
|
||||
|
||||
@@ -20,12 +20,12 @@ Key airframe features:
|
||||
- Removable V tail or conventional tail options included
|
||||
- Threaded inserts in the wings and fuselage top for external mounting
|
||||
- Numerous mounting features
|
||||
- Top antenna hole
|
||||
- Top GPS cover
|
||||
- Side "T" antenna mounts
|
||||
- Rear electronics tray
|
||||
- Front facing "action cam" cutout
|
||||
- Front facing FPV camera cutout
|
||||
- Top antenna hole
|
||||
- Top GPS cover
|
||||
- Side "T" antenna mounts
|
||||
- Rear electronics tray
|
||||
- Front facing "action cam" cutout
|
||||
- Front facing FPV camera cutout
|
||||
- Removable wings
|
||||
- Low stall speed
|
||||
- Gentle handling
|
||||
@@ -69,10 +69,10 @@ Key build features
|
||||
- [6s2p 18650 LiIon flight battery](https://www.upgradeenergytech.com/product-page/6s-22-2v-5600mah-30c-dark-lithium-liion-drone-battery) (select XT60 connector)
|
||||
|
||||
- [Custom designed 3D printed parts](https://github.com/PX4/PX4-user_guide/raw/main/assets/airframes/fw/reptile_dragon_2/rd2_3d_printed_parts.zip)
|
||||
- ARK6X carrier mount
|
||||
- Holybro Pixhawk 5x carrier mount
|
||||
- FPV pod and camera mount
|
||||
- Pitot static probe "plug" adapter
|
||||
- ARK6X carrier mount
|
||||
- Holybro Pixhawk 5x carrier mount
|
||||
- FPV pod and camera mount
|
||||
- Pitot static probe "plug" adapter
|
||||
|
||||
- [Custom designed power distribution PCB](https://github.com/PX4/PX4-user_guide/raw/main/assets/airframes/fw/reptile_dragon_2/xt30_power_distro_pcb.zip)
|
||||
|
||||
@@ -426,15 +426,15 @@ Prior to the first flight, a comprehensive preflight must be conducted.
|
||||
I recommend checking the following items:
|
||||
|
||||
- Sensor calibration (QGC)
|
||||
- Mag calibration
|
||||
- Accelerometer calibration
|
||||
- Airspeed calibration
|
||||
- Level horizon calibration
|
||||
- Mag calibration
|
||||
- Accelerometer calibration
|
||||
- Airspeed calibration
|
||||
- Level horizon calibration
|
||||
- Check control surface deflection
|
||||
- Right stick -> Right aileron goes up, left aileron goes down
|
||||
- Left stick -> Left aileron goes up, right aileron goes down
|
||||
- Stick back -> elevator goes up
|
||||
-Stick forward -> elevator goes down
|
||||
-Stick forward -> elevator goes down
|
||||
- Left rudder -> Rudder goes left
|
||||
- Right rudder -> Rudder goes right
|
||||
- Check Px4 inputs (in `stabilized mode`)
|
||||
|
||||
@@ -98,11 +98,11 @@ The mapping between flight controller outputs and specific controls/motors depen
|
||||
Assembly information is covered in several sections:
|
||||
|
||||
- [Basic Assembly](../assembly/index.md) contains topics shows the setup of core components for a number of popular [flight controllers](../flight_controller/index.md).
|
||||
Flight controllers for which we do not have guides are usually set up in much the same way (and almost always include similar setup guides).
|
||||
Flight controllers for which we do not have guides are usually set up in much the same way (and almost always include similar setup guides).
|
||||
- [Peripherals](../peripherals/index.md) contains information about other peripherals, including [Airspeed Sensors](../sensor/airspeed.md).
|
||||
- [Airframes Reference > VTOL](../airframes/airframe_reference.md#vtol) explains which flight controller outputs must be connected to different flight controls for each airframe configuration:
|
||||
- Select the configuration for your vehicle if one exists, as this will have been pre-tuned well enough to fly (may only require fine tuning).
|
||||
- Otherwise select a "Generic Airframe" that matches your vehicle.
|
||||
- Select the configuration for your vehicle if one exists, as this will have been pre-tuned well enough to fly (may only require fine tuning).
|
||||
- Otherwise select a "Generic Airframe" that matches your vehicle.
|
||||
|
||||
In addition, build logs showing how others have set up different types of vehicles are provided as sub topics.
|
||||
For example see [FunCub QuadPlane](../frames_vtol/vtol_quadplane_fun_cub_vtol_pixhawk.md).
|
||||
|
||||
+119
-119
@@ -29,151 +29,151 @@ This consists of a single _C_ file and a _cmake_ definition (which tells the too
|
||||
|
||||
2. Create a new C file in that directory named **px4_simple_app.c**:
|
||||
|
||||
- Copy in the default header to the top of the page.
|
||||
该注释应出现在所有贡献的文件中!
|
||||
- Copy in the default header to the top of the page.
|
||||
该注释应出现在所有贡献的文件中!
|
||||
|
||||
```c
|
||||
/****************************************************************************
|
||||
*
|
||||
* Copyright (c) 2012-2022 PX4 Development Team. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
*
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in
|
||||
* the documentation and/or other materials provided with the
|
||||
* distribution.
|
||||
* 3. Neither the name PX4 nor the names of its contributors may be
|
||||
* used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
* POSSIBILITY OF SUCH DAMAGE.
|
||||
*
|
||||
****************************************************************************/
|
||||
```
|
||||
```c
|
||||
/****************************************************************************
|
||||
*
|
||||
* Copyright (c) 2012-2022 PX4 Development Team. All rights reserved.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
*
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in
|
||||
* the documentation and/or other materials provided with the
|
||||
* distribution.
|
||||
* 3. Neither the name PX4 nor the names of its contributors may be
|
||||
* used to endorse or promote products derived from this software
|
||||
* without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
* OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
* POSSIBILITY OF SUCH DAMAGE.
|
||||
*
|
||||
****************************************************************************/
|
||||
```
|
||||
|
||||
- 将下面的代码复制到头部注释的下方,
|
||||
该注释应出现在所有贡献的文件中!
|
||||
- 将下面的代码复制到头部注释的下方,
|
||||
该注释应出现在所有贡献的文件中!
|
||||
|
||||
```c
|
||||
/**
|
||||
* @file px4_simple_app.c
|
||||
* Minimal application example for PX4 autopilot
|
||||
*
|
||||
* @author Example User <mail@example.com>
|
||||
*/
|
||||
```c
|
||||
/**
|
||||
* @file px4_simple_app.c
|
||||
* Minimal application example for PX4 autopilot
|
||||
*
|
||||
* @author Example User <mail@example.com>
|
||||
*/
|
||||
|
||||
#include <px4_platform_common/log.h>
|
||||
#include <px4_platform_common/log.h>
|
||||
|
||||
__EXPORT int px4_simple_app_main(int argc, char *argv[]);
|
||||
__EXPORT int px4_simple_app_main(int argc, char *argv[]);
|
||||
|
||||
int px4_simple_app_main(int argc, char *argv[])
|
||||
{
|
||||
PX4_INFO("Hello Sky!");
|
||||
return OK;
|
||||
}
|
||||
```
|
||||
int px4_simple_app_main(int argc, char *argv[])
|
||||
{
|
||||
PX4_INFO("Hello Sky!");
|
||||
return OK;
|
||||
}
|
||||
```
|
||||
|
||||
:::tip
|
||||
The main function must be named `<module_name>_main` and exported from the module as shown.
|
||||
:::tip
|
||||
The main function must be named `<module_name>_main` and exported from the module as shown.
|
||||
|
||||
:::
|
||||
|
||||
:::tip
|
||||
`PX4_INFO` is the equivalent of `printf` for the PX4 shell (included from **px4_platform_common/log.h**).
|
||||
There are different log levels: `PX4_INFO`, `PX4_WARN`, `PX4_ERR`, `PX4_DEBUG`.
|
||||
Warnings and errors are additionally added to the [ULog](../dev_log/ulog_file_format.md) and shown on [Flight Review](https://logs.px4.io/).
|
||||
:::tip
|
||||
`PX4_INFO` is the equivalent of `printf` for the PX4 shell (included from **px4_platform_common/log.h**).
|
||||
There are different log levels: `PX4_INFO`, `PX4_WARN`, `PX4_ERR`, `PX4_DEBUG`.
|
||||
Warnings and errors are additionally added to the [ULog](../dev_log/ulog_file_format.md) and shown on [Flight Review](https://logs.px4.io/).
|
||||
|
||||
:::
|
||||
|
||||
3. Create and open a new _cmake_ definition file named **CMakeLists.txt**.
|
||||
复制下面的文本:
|
||||
复制下面的文本:
|
||||
|
||||
```cmake
|
||||
############################################################################
|
||||
#
|
||||
# Copyright (c) 2015 PX4 Development Team. All rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or without
|
||||
# modification, are permitted provided that the following conditions
|
||||
# are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above copyright
|
||||
# notice, this list of conditions and the following disclaimer in
|
||||
# the documentation and/or other materials provided with the
|
||||
# distribution.
|
||||
# 3. Neither the name PX4 nor the names of its contributors may be
|
||||
# used to endorse or promote products derived from this software
|
||||
# without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
# POSSIBILITY OF SUCH DAMAGE.
|
||||
#
|
||||
############################################################################
|
||||
px4_add_module(
|
||||
MODULE examples__px4_simple_app
|
||||
MAIN px4_simple_app
|
||||
STACK_MAIN 2000
|
||||
SRCS
|
||||
px4_simple_app.c
|
||||
DEPENDS
|
||||
)
|
||||
```
|
||||
```cmake
|
||||
############################################################################
|
||||
#
|
||||
# Copyright (c) 2015 PX4 Development Team. All rights reserved.
|
||||
#
|
||||
# Redistribution and use in source and binary forms, with or without
|
||||
# modification, are permitted provided that the following conditions
|
||||
# are met:
|
||||
#
|
||||
# 1. Redistributions of source code must retain the above copyright
|
||||
# notice, this list of conditions and the following disclaimer.
|
||||
# 2. Redistributions in binary form must reproduce the above copyright
|
||||
# notice, this list of conditions and the following disclaimer in
|
||||
# the documentation and/or other materials provided with the
|
||||
# distribution.
|
||||
# 3. Neither the name PX4 nor the names of its contributors may be
|
||||
# used to endorse or promote products derived from this software
|
||||
# without specific prior written permission.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
||||
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
||||
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
|
||||
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
|
||||
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
||||
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
|
||||
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
|
||||
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
|
||||
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
|
||||
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
# POSSIBILITY OF SUCH DAMAGE.
|
||||
#
|
||||
############################################################################
|
||||
px4_add_module(
|
||||
MODULE examples__px4_simple_app
|
||||
MAIN px4_simple_app
|
||||
STACK_MAIN 2000
|
||||
SRCS
|
||||
px4_simple_app.c
|
||||
DEPENDS
|
||||
)
|
||||
```
|
||||
|
||||
The `px4_add_module()` method builds a static library from a module description.
|
||||
The `px4_add_module()` method builds a static library from a module description.
|
||||
|
||||
- The `MODULE` block is the Firmware-unique name of the module (by convention the module name is prefixed by parent directories back to `src`).
|
||||
- The `MAIN` block lists the entry point of the module, which registers the command with NuttX so that it can be called from the PX4 shell or SITL console.
|
||||
- The `MODULE` block is the Firmware-unique name of the module (by convention the module name is prefixed by parent directories back to `src`).
|
||||
- The `MAIN` block lists the entry point of the module, which registers the command with NuttX so that it can be called from the PX4 shell or SITL console.
|
||||
|
||||
:::tip
|
||||
The `px4_add_module()` format is documented in [PX4-Autopilot/cmake/px4_add_module.cmake](https://github.com/PX4/PX4-Autopilot/blob/main/cmake/px4_add_module.cmake). <!-- NEED px4_version -->
|
||||
:::tip
|
||||
The `px4_add_module()` format is documented in [PX4-Autopilot/cmake/px4_add_module.cmake](https://github.com/PX4/PX4-Autopilot/blob/main/cmake/px4_add_module.cmake). <!-- NEED px4_version -->
|
||||
|
||||
:::
|
||||
|
||||
::: info
|
||||
If you specify `DYNAMIC` as an option to `px4_add_module`, a _shared library_ is created instead of a static library on POSIX platforms (these can be loaded without having to recompile PX4, and shared to others as binaries rather than source code).
|
||||
Your app will not become a builtin command, but ends up in a separate file called `examples__px4_simple_app.px4mod`.
|
||||
You can then run your command by loading the file at runtime using the `dyn` command: `dyn ./examples__px4_simple_app.px4mod`
|
||||
::: info
|
||||
If you specify `DYNAMIC` as an option to `px4_add_module`, a _shared library_ is created instead of a static library on POSIX platforms (these can be loaded without having to recompile PX4, and shared to others as binaries rather than source code).
|
||||
Your app will not become a builtin command, but ends up in a separate file called `examples__px4_simple_app.px4mod`.
|
||||
You can then run your command by loading the file at runtime using the `dyn` command: `dyn ./examples__px4_simple_app.px4mod`
|
||||
|
||||
:::
|
||||
|
||||
4. Create and open a new _Kconfig_ definition file named **Kconfig** and define your symbol for naming (see [Kconfig naming convention](../hardware/porting_guide_config.md#px4-kconfig-symbol-naming-convention)).
|
||||
复制下面的文本:
|
||||
复制下面的文本:
|
||||
|
||||
```
|
||||
menuconfig EXAMPLES_PX4_SIMPLE_APP
|
||||
bool "px4_simple_app"
|
||||
default n
|
||||
---help---
|
||||
Enable support for px4_simple_app
|
||||
```
|
||||
```
|
||||
menuconfig EXAMPLES_PX4_SIMPLE_APP
|
||||
bool "px4_simple_app"
|
||||
default n
|
||||
---help---
|
||||
Enable support for px4_simple_app
|
||||
```
|
||||
|
||||
## 编译应用程序/固件
|
||||
|
||||
|
||||
@@ -347,7 +347,7 @@ CONFIG_DRIVERS_RPM_CAPTURE=y
|
||||
Additionally, to enable the module:
|
||||
|
||||
- Set [ICE_EN](../advanced_config/parameter_reference.md#ICE_EN)
|
||||
to true and adjust the other `ICE_` module parameters according to your needs.
|
||||
to true and adjust the other `ICE_` module parameters according to your needs.
|
||||
- Set [RPM_CAP_ENABLE](../advanced_config/parameter_reference.md#RPM_CAP_ENABLE) to true.
|
||||
|
||||
The module outputs control signals for ignition, throttle, and choke,
|
||||
@@ -367,8 +367,8 @@ The state machine:
|
||||
|
||||
- Checks if [Rpm.msg](../msg_docs/Rpm.md) is updated to know if the engine is running
|
||||
- Allows for user inputs from:
|
||||
- AUX{N}
|
||||
- Arming state in [VehicleStatus.msg](../msg_docs/VehicleStatus.md)
|
||||
- AUX{N}
|
||||
- Arming state in [VehicleStatus.msg](../msg_docs/VehicleStatus.md)
|
||||
|
||||
The module publishes [InternalCombustionEngineControl.msg](../msg_docs/InternalCombustionEngineControl.md).
|
||||
|
||||
@@ -484,7 +484,7 @@ The normal log is always a superset of the mission log.
|
||||
The implementation uses two threads:
|
||||
|
||||
- The main thread, running at a fixed rate (or polling on a topic if started with -p) and checking for
|
||||
data updates
|
||||
data updates
|
||||
- The writer thread, writing data to the file
|
||||
|
||||
In between there is a write buffer with configurable size (and another fixed-size buffer for
|
||||
@@ -688,9 +688,9 @@ There are 2 environment variables used for configuration: `replay`, which must b
|
||||
the log file to be replayed. The second is the mode, specified via `replay_mode`:
|
||||
|
||||
- `replay_mode=ekf2`: specific EKF2 replay mode. It can only be used with the ekf2 module, but allows the replay
|
||||
to run as fast as possible.
|
||||
to run as fast as possible.
|
||||
- Generic otherwise: this can be used to replay any module(s), but the replay will be done with the same speed as the
|
||||
log was recorded.
|
||||
log was recorded.
|
||||
|
||||
The module is typically used together with uORB publisher rules, to specify which messages should be replayed.
|
||||
The replay module will just publish all messages that are found in the log. It also applies the parameters from
|
||||
@@ -842,12 +842,12 @@ it into a more usable form, and publishes it for the rest of the system.
|
||||
The provided functionality includes:
|
||||
|
||||
- Read the output from the sensor drivers (`SensorGyro`, etc.).
|
||||
If there are multiple of the same type, do voting and failover handling.
|
||||
Then apply the board rotation and temperature calibration (if enabled). And finally publish the data; one of the
|
||||
topics is `SensorCombined`, used by many parts of the system.
|
||||
If there are multiple of the same type, do voting and failover handling.
|
||||
Then apply the board rotation and temperature calibration (if enabled). And finally publish the data; one of the
|
||||
topics is `SensorCombined`, used by many parts of the system.
|
||||
- Make sure the sensor drivers get the updated calibration parameters (scale & offset) when the parameters change or
|
||||
on startup. The sensor drivers use the ioctl interface for parameter updates. For this to work properly, the
|
||||
sensor drivers must already be running when `sensors` is started.
|
||||
on startup. The sensor drivers use the ioctl interface for parameter updates. For this to work properly, the
|
||||
sensor drivers must already be running when `sensors` is started.
|
||||
- Do sensor consistency checks and publish the `SensorsStatusImu` topic.
|
||||
|
||||
### 实现
|
||||
|
||||
@@ -25,38 +25,38 @@ Other examples in Python can be found here: [integrationtests/python_src/px4_it/
|
||||
|
||||
1. Open the terminal and go to `~/catkin_ws/src` directory
|
||||
|
||||
```sh
|
||||
roscd # Should cd into ~/catkin_ws/devel
|
||||
cd ..
|
||||
cd src
|
||||
```
|
||||
```sh
|
||||
roscd # Should cd into ~/catkin_ws/devel
|
||||
cd ..
|
||||
cd src
|
||||
```
|
||||
|
||||
2. In the `~/catkin_ws/src` directory create a new package named `offboard_py` (in this case) with the `rospy` dependency:
|
||||
|
||||
```sh
|
||||
catkin_create_pkg offboard_py rospy
|
||||
```
|
||||
```sh
|
||||
catkin_create_pkg offboard_py rospy
|
||||
```
|
||||
|
||||
3. Build the new package in the `~/catkin_ws/` directory:
|
||||
|
||||
```sh
|
||||
cd .. # Assuming previous directory to be ~/catkin_ws/src
|
||||
catkin build
|
||||
source devel/setup.bash
|
||||
```
|
||||
```sh
|
||||
cd .. # Assuming previous directory to be ~/catkin_ws/src
|
||||
catkin build
|
||||
source devel/setup.bash
|
||||
```
|
||||
|
||||
4. 您现在应该能够通过使用以下方法切换至包目录:
|
||||
|
||||
```sh
|
||||
roscd offboard_py
|
||||
```
|
||||
```sh
|
||||
roscd offboard_py
|
||||
```
|
||||
|
||||
5. To store your Python files, create a new folder called `/scripts` on the package:
|
||||
|
||||
```sh
|
||||
mkdir scripts
|
||||
cd scripts
|
||||
```
|
||||
```sh
|
||||
mkdir scripts
|
||||
cd scripts
|
||||
```
|
||||
|
||||
## 代码
|
||||
|
||||
|
||||
@@ -37,63 +37,63 @@ This is needed because, by default, you cannot arm a vehicle without a connectio
|
||||
|
||||
2. 使用以下方法创建并切换至新的 colcon工作目录:
|
||||
|
||||
```sh
|
||||
mkdir -p ~/ws_offboard_control/src/
|
||||
cd ~/ws_offboard_control/src/
|
||||
```
|
||||
```sh
|
||||
mkdir -p ~/ws_offboard_control/src/
|
||||
cd ~/ws_offboard_control/src/
|
||||
```
|
||||
|
||||
3. Clone the [px4_msgs](https://github.com/PX4/px4_msgs) repo to the `/src` directory (this repo is needed in every ROS 2 PX4 workspace!):
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
# checkout the matching release branch if not using PX4 main.
|
||||
```
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_msgs.git
|
||||
# checkout the matching release branch if not using PX4 main.
|
||||
```
|
||||
|
||||
4. Clone the example repository [px4_ros_com](https://github.com/PX4/px4_ros_com) to the `/src` directory:
|
||||
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
```sh
|
||||
git clone https://github.com/PX4/px4_ros_com.git
|
||||
```
|
||||
|
||||
5. Source the ROS 2 development environment into the current terminal and compile the workspace using `colcon`:
|
||||
|
||||
:::: tabs
|
||||
:::: tabs
|
||||
|
||||
::: tab humble
|
||||
::: tab humble
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/humble/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::: tab foxy
|
||||
::: tab foxy
|
||||
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
```sh
|
||||
cd ..
|
||||
source /opt/ros/foxy/setup.bash
|
||||
colcon build
|
||||
```
|
||||
|
||||
|
||||
:::
|
||||
|
||||
::::
|
||||
::::
|
||||
|
||||
6. Source the `local_setup.bash`:
|
||||
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
```sh
|
||||
source install/local_setup.bash
|
||||
```
|
||||
|
||||
7. 启动例程。
|
||||
|
||||
```
|
||||
ros2 run px4_ros_com offboard_control
|
||||
```
|
||||
```
|
||||
ros2 run px4_ros_com offboard_control
|
||||
```
|
||||
|
||||
飞行器将解锁、起飞至5米并悬停等待(永久)。
|
||||
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
# Battery information
|
||||
#
|
||||
# Static or near-invariant battery information.
|
||||
# Should be streamed at low rate.
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
|
||||
uint8 id # Must match the id in the battery_status message for the same battery
|
||||
char[32] serial_number # [@invalid 0 All bytes] Serial number of the battery pack in ASCII characters, 0 terminated
|
||||
@@ -47,6 +47,7 @@ set(msg_files
|
||||
Airspeed.msg
|
||||
AirspeedWind.msg
|
||||
AutotuneAttitudeControlStatus.msg
|
||||
BatteryInfo.msg
|
||||
ButtonEvent.msg
|
||||
CameraCapture.msg
|
||||
CameraStatus.msg
|
||||
@@ -226,6 +227,7 @@ set(msg_files
|
||||
VehicleImu.msg
|
||||
VehicleImuStatus.msg
|
||||
VehicleLocalPositionSetpoint.msg
|
||||
TaskLocalPositionSetpoint.msg
|
||||
VehicleMagnetometer.msg
|
||||
VehicleOpticalFlow.msg
|
||||
VehicleOpticalFlowVel.msg
|
||||
|
||||
+25
-25
@@ -2,37 +2,37 @@
|
||||
#
|
||||
# This is currently used only for logging cell status from MAVLink.
|
||||
|
||||
uint64 timestamp # [us] Time since system start.
|
||||
uint64 timestamp # [us] Time since system start
|
||||
|
||||
uint16 status # [@enum STATUS_FLAG] Status bitmap.
|
||||
uint16 STATUS_FLAG_UNKNOWN = 1 # State unknown or not reportable.
|
||||
uint16 STATUS_FLAG_FAILED = 2 # Modem is unusable.
|
||||
uint16 STATUS_FLAG_INITIALIZING = 4 # Modem is being initialized.
|
||||
uint16 STATUS_FLAG_LOCKED = 8 # Modem is locked.
|
||||
uint16 STATUS_FLAG_DISABLED = 16 # Modem is not enabled and is powered down.
|
||||
uint16 STATUS_FLAG_DISABLING = 32 # Modem is currently transitioning to the STATUS_FLAG_DISABLED state.
|
||||
uint16 STATUS_FLAG_ENABLING = 64 # Modem is currently transitioning to the STATUS_FLAG_ENABLED state.
|
||||
uint16 STATUS_FLAG_ENABLED = 128 # Modem is enabled and powered on but not registered with a network provider and not available for data connections.
|
||||
uint16 STATUS_FLAG_SEARCHING = 256 # Modem is searching for a network provider to register.
|
||||
uint16 STATUS_FLAG_REGISTERED = 512 # Modem is registered with a network provider, and data connections and messaging may be available for use.
|
||||
uint16 STATUS_FLAG_DISCONNECTING = 1024 # Modem is disconnecting and deactivating the last active packet data bearer. This state will not be entered if more than one packet data bearer is active and one of the active bearers is deactivated.
|
||||
uint16 STATUS_FLAG_CONNECTING = 2048 # Modem is activating and connecting the first packet data bearer. Subsequent bearer activations when another bearer is already active do not cause this state to be entered.
|
||||
uint16 STATUS_FLAG_CONNECTED = 4096 # One or more packet data bearers is active and connected.
|
||||
uint16 status # [@enum STATUS_FLAG] Status bitmap
|
||||
uint16 STATUS_FLAG_UNKNOWN = 1 # State unknown or not reportable
|
||||
uint16 STATUS_FLAG_FAILED = 2 # Modem is unusable
|
||||
uint16 STATUS_FLAG_INITIALIZING = 4 # Modem is being initialized
|
||||
uint16 STATUS_FLAG_LOCKED = 8 # Modem is locked
|
||||
uint16 STATUS_FLAG_DISABLED = 16 # Modem is not enabled and is powered down
|
||||
uint16 STATUS_FLAG_DISABLING = 32 # Modem is currently transitioning to the STATUS_FLAG_DISABLED state
|
||||
uint16 STATUS_FLAG_ENABLING = 64 # Modem is currently transitioning to the STATUS_FLAG_ENABLED state
|
||||
uint16 STATUS_FLAG_ENABLED = 128 # Modem is enabled and powered on but not registered with a network provider and not available for data connections
|
||||
uint16 STATUS_FLAG_SEARCHING = 256 # Modem is searching for a network provider to register
|
||||
uint16 STATUS_FLAG_REGISTERED = 512 # Modem is registered with a network provider, and data connections and messaging may be available for use
|
||||
uint16 STATUS_FLAG_DISCONNECTING = 1024 # Modem is disconnecting and deactivating the last active packet data bearer. This state will not be entered if more than one packet data bearer is active and one of the active bearers is deactivated
|
||||
uint16 STATUS_FLAG_CONNECTING = 2048 # Modem is activating and connecting the first packet data bearer. Subsequent bearer activations when another bearer is already active do not cause this state to be entered
|
||||
uint16 STATUS_FLAG_CONNECTED = 4096 # One or more packet data bearers is active and connected
|
||||
|
||||
uint8 failure_reason # [@enum FAILURE_REASON] Failure reason.
|
||||
uint8 FAILURE_REASON_NONE = 0 # No error.
|
||||
uint8 FAILURE_REASON_UNKNOWN = 1 # Error state is unknown.
|
||||
uint8 FAILURE_REASON_SIM_MISSING = 2 # SIM is required for the modem but missing.
|
||||
uint8 FAILURE_REASON_SIM_ERROR = 3 # SIM is available, but not usable for connection.
|
||||
uint8 failure_reason # [@enum FAILURE_REASON] Failure reason
|
||||
uint8 FAILURE_REASON_NONE = 0 # No error
|
||||
uint8 FAILURE_REASON_UNKNOWN = 1 # Error state is unknown
|
||||
uint8 FAILURE_REASON_SIM_MISSING = 2 # SIM is required for the modem but missing
|
||||
uint8 FAILURE_REASON_SIM_ERROR = 3 # SIM is available, but not usable for connection
|
||||
|
||||
uint8 type # [@enum CELLULAR_NETWORK_RADIO_TYPE] Cellular network radio type.
|
||||
uint8 type # [@enum CELLULAR_NETWORK_RADIO_TYPE] Cellular network radio type
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_NONE = 0 # None
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_GSM = 1 # GSM
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_CDMA = 2 # CDMA
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_WCDMA = 3 # WCDMA
|
||||
uint8 CELLULAR_NETWORK_RADIO_TYPE_LTE = 4 # LTE
|
||||
|
||||
uint8 quality # [dBm] Cellular network RSSI/RSRP, absolute value.
|
||||
uint16 mcc # [@invalid UINT16_MAX] Mobile country code.
|
||||
uint16 mnc # [@invalid UINT16_MAX] Mobile network code.
|
||||
uint16 lac # [@invalid 0] Location area code.
|
||||
uint8 quality # [dBm] Cellular network RSSI/RSRP, absolute value
|
||||
uint16 mcc # [@invalid UINT16_MAX] Mobile country code
|
||||
uint16 mnc # [@invalid UINT16_MAX] Mobile network code
|
||||
uint16 lac # [@invalid 0] Location area code
|
||||
|
||||
@@ -39,14 +39,12 @@ uint8 CS_FIXED_WING = 17 # 17 - true when thought to be operating as a fixed win
|
||||
uint8 CS_MAG_FAULT = 18 # 18 - true when the magnetometer has been declared faulty and is no longer being used
|
||||
uint8 CS_ASPD = 19 # 19 - true when airspeed measurements are being fused
|
||||
uint8 CS_GND_EFFECT = 20 # 20 - true when when protection from ground effect induced static pressure rise is active
|
||||
uint8 CS_RNG_STUCK = 21 # 21 - true when a stuck range finder sensor has been detected
|
||||
uint8 CS_GPS_YAW = 22 # 22 - true when yaw (not ground course) data from a GPS receiver is being fused
|
||||
uint8 CS_MAG_ALIGNED = 23 # 23 - true when the in-flight mag field alignment has been completed
|
||||
uint8 CS_EV_VEL = 24 # 24 - true when local frame velocity data fusion from external vision measurements is intended
|
||||
uint8 CS_SYNTHETIC_MAG_Z = 25 # 25 - true when we are using a synthesized measurement for the magnetometer Z component
|
||||
uint8 CS_VEHICLE_AT_REST = 26 # 26 - true when the vehicle is at rest
|
||||
uint8 CS_GPS_YAW_FAULT = 27 # 27 - true when the GNSS heading has been declared faulty and is no longer being used
|
||||
uint8 CS_RNG_FAULT = 28 # 28 - true when the range finder has been declared faulty and is no longer being used
|
||||
uint8 CS_GNSS_VEL = 44 # 44 - true if GNSS velocity measurements are being fused
|
||||
|
||||
uint32 filter_fault_flags # Bitmask to indicate EKF internal faults
|
||||
|
||||
@@ -25,14 +25,12 @@ bool cs_fixed_wing # 17 - true when the vehicle is operating as a fix
|
||||
bool cs_mag_fault # 18 - true when the magnetometer has been declared faulty and is no longer being used
|
||||
bool cs_fuse_aspd # 19 - true when airspeed measurements are being fused
|
||||
bool cs_gnd_effect # 20 - true when protection from ground effect induced static pressure rise is active
|
||||
bool cs_rng_stuck # 21 - true when rng data wasn't ready for more than 10s and new rng values haven't changed enough
|
||||
bool cs_gnss_yaw # 22 - true when yaw (not ground course) data fusion from a GPS receiver is intended
|
||||
bool cs_mag_aligned_in_flight # 23 - true when the in-flight mag field alignment has been completed
|
||||
bool cs_ev_vel # 24 - true when local frame velocity data fusion from external vision measurements is intended
|
||||
bool cs_synthetic_mag_z # 25 - true when we are using a synthesized measurement for the magnetometer Z component
|
||||
bool cs_vehicle_at_rest # 26 - true when the vehicle is at rest
|
||||
bool cs_gnss_yaw_fault # 27 - true when the GNSS heading has been declared faulty and is no longer being used
|
||||
bool cs_rng_fault # 28 - true when the range finder has been declared faulty and is no longer being used
|
||||
bool cs_inertial_dead_reckoning # 29 - true if we are no longer fusing measurements that constrain horizontal velocity drift
|
||||
bool cs_wind_dead_reckoning # 30 - true if we are navigationg reliant on wind relative measurements
|
||||
bool cs_rng_kin_consistent # 31 - true when the range finder kinematic consistency check is passing
|
||||
|
||||
@@ -36,3 +36,5 @@ float32 alt_acceptance_radius # vertical acceptance radius, only used for fixed
|
||||
float32 cruising_speed # the generally desired cruising speed (not a hard constraint)
|
||||
bool gliding_enabled # commands the vehicle to glide if the capability is available (fixed wing only)
|
||||
float32 cruising_throttle # the generally desired cruising throttle (not a hard constraint), only has an effect for rover
|
||||
|
||||
# TOPICS position_setpoint task_position_setpoint
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
uint64 timestamp # time since system start (microseconds)
|
||||
|
||||
float32 normalized_steering_angle # [-1, 1] Normalized steering angle (Ackermann only, Positiv: Steer right, Negativ: Steer left)
|
||||
|
||||
float32 normalized_speed_diff # [-1, 1] Normalized speed difference between the left and right wheels of the rover (Differential/Mecanum only, Positiv = Turn right, Negativ: Turn left)
|
||||
float32 normalized_steering_setpoint # [-1, 1] Positiv = Turn right, Negativ: Turn left (Ackermann: Steering angle, Differential/Mecanum: Speed difference between the left and right wheels)
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
# Local position setpoint in NED frame
|
||||
# Telemetry of PID position controller to monitor tracking.
|
||||
# NaN means the state was not controlled
|
||||
|
||||
uint64 timestamp # time since system start (microseconds)
|
||||
|
||||
float32 x # in meters NED
|
||||
float32 y # in meters NED
|
||||
float32 z # in meters NED
|
||||
|
||||
float32 vx # in meters/sec
|
||||
float32 vy # in meters/sec
|
||||
float32 vz # in meters/sec
|
||||
|
||||
float32[3] acceleration # in meters/sec^2
|
||||
float32[3] thrust # normalized thrust vector in NED
|
||||
|
||||
float32 yaw # in radians NED -PI..+PI
|
||||
float32 yawspeed # in radians/sec
|
||||
@@ -7,3 +7,5 @@ float32 speed_up # in meters/sec
|
||||
float32 speed_down # in meters/sec
|
||||
|
||||
bool want_takeoff # tell the controller to initiate takeoff when idling (ignored during flight)
|
||||
|
||||
bool lock_dist_bottom # altitude is locked to the current distance to ground
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
# Battery status
|
||||
#
|
||||
# Battery status information for up to 4 battery instances.
|
||||
# These are populated from power module and smart battery device drivers, and one battery updated from MAVLink.
|
||||
# Battery instance information is also logged and streamed in MAVLink telemetry.
|
||||
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
uint8 MAX_INSTANCES = 4
|
||||
|
||||
uint64 timestamp # [us] Time since system start
|
||||
bool connected # Whether or not a battery is connected. For power modules this is based on a voltage threshold.
|
||||
float32 voltage_v # [V] [@invalid 0] Battery voltage
|
||||
float32 current_a # [A] [@invalid -1] Battery current
|
||||
float32 current_average_a # [A] [@invalid -1] Battery current average (for FW average in level flight)
|
||||
float32 discharged_mah # [mAh] [@invalid -1] Discharged amount
|
||||
float32 remaining # [@range 0,1] [@invalid -1] Remaining capacity
|
||||
float32 scale # [@range 1,] [@invalid -1] Scaling factor to compensate for lower actuation power caused by voltage sag
|
||||
float32 time_remaining_s # [s] [@invalid NaN] Predicted time remaining until battery is empty under previous averaged load
|
||||
float32 temperature # [°C] [@invalid NaN] Temperature of the battery
|
||||
uint8 cell_count # [@invalid 0] Number of cells
|
||||
|
||||
|
||||
uint8 source # [@enum SOURCE] Battery source
|
||||
uint8 SOURCE_POWER_MODULE = 0 # Power module
|
||||
uint8 SOURCE_EXTERNAL = 1 # External
|
||||
uint8 SOURCE_ESCS = 2 # ESCs
|
||||
|
||||
uint8 priority # Zero based priority is the connection on the Power Controller V1..Vn AKA BrickN-1
|
||||
uint16 capacity # [mAh] Capacity of the battery when fully charged
|
||||
uint16 cycle_count # Number of discharge cycles the battery has experienced
|
||||
uint16 average_time_to_empty # [minutes] Predicted remaining battery capacity based on the average rate of discharge
|
||||
uint16 serial_number # Serial number of the battery pack
|
||||
uint16 manufacture_date # Manufacture date, part of serial number of the battery pack. Formatted as: Day + Month×32 + (Year–1980)×512
|
||||
uint16 state_of_health # [%] [@range 0, 100] State of health. FullChargeCapacity/DesignCapacity
|
||||
uint16 max_error # [%] [@range 1, 100] Max error, expected margin of error in the state-of-charge calculation
|
||||
uint8 id # ID number of a battery. Should be unique and consistent for the lifetime of a vehicle. 1-indexed
|
||||
uint16 interface_error # Interface error counter
|
||||
|
||||
float32[14] voltage_cell_v # [V] [@invalid 0] Battery individual cell voltages
|
||||
float32 max_cell_voltage_delta # Max difference between individual cell voltages
|
||||
|
||||
bool is_powering_off # Power off event imminent indication, false if unknown
|
||||
bool is_required # Set if the battery is explicitly required before arming
|
||||
|
||||
uint8 warning # [@enum WARNING STATE] Current battery warning
|
||||
uint8 WARNING_NONE = 0 # No battery low voltage warning active
|
||||
uint8 WARNING_LOW = 1 # Low voltage warning
|
||||
uint8 WARNING_CRITICAL = 2 # Critical voltage, return / abort immediately
|
||||
uint8 WARNING_EMERGENCY = 3 # Immediate landing required
|
||||
uint8 WARNING_FAILED = 4 # Battery has failed completely
|
||||
uint8 STATE_UNHEALTHY = 6 # Battery is diagnosed to be defective or an error occurred, usage is discouraged / prohibited. Possible causes (faults) are listed in faults field
|
||||
uint8 STATE_CHARGING = 7 # Battery is charging
|
||||
|
||||
uint16 faults # [@enum FAULT] Smart battery supply status/fault flags (bitmask) for health indication
|
||||
uint8 FAULT_DEEP_DISCHARGE = 0 # Battery has deep discharged
|
||||
uint8 FAULT_SPIKES = 1 # Voltage spikes
|
||||
uint8 FAULT_CELL_FAIL= 2 # One or more cells have failed
|
||||
uint8 FAULT_OVER_CURRENT = 3 # Over-current
|
||||
uint8 FAULT_OVER_TEMPERATURE = 4 # Over-temperature
|
||||
uint8 FAULT_UNDER_TEMPERATURE = 5 # Under-temperature fault
|
||||
uint8 FAULT_INCOMPATIBLE_VOLTAGE = 6 # Vehicle voltage is not compatible with this battery (batteries on same power rail should have similar voltage)
|
||||
uint8 FAULT_INCOMPATIBLE_FIRMWARE = 7 # Battery firmware is not compatible with current autopilot firmware
|
||||
uint8 FAULT_INCOMPATIBLE_MODEL = 8 # Battery model is not supported by the system
|
||||
uint8 FAULT_HARDWARE_FAILURE = 9 # Hardware problem
|
||||
uint8 FAULT_FAILED_TO_ARM = 10 # Battery had a problem while arming
|
||||
uint8 FAULT_COUNT = 11 # Counter. Keep this as last element
|
||||
|
||||
float32 full_charge_capacity_wh # [Wh] Compensated battery capacity
|
||||
float32 remaining_capacity_wh # [Wh] Compensated battery capacity remaining
|
||||
uint16 over_discharge_count # Number of battery overdischarge
|
||||
float32 nominal_voltage # [V] Nominal voltage of the battery pack
|
||||
|
||||
float32 internal_resistance_estimate # [Ohm] Internal resistance per cell estimate
|
||||
float32 ocv_estimate # [V] Open circuit voltage estimate
|
||||
float32 ocv_estimate_filtered # [V] Filtered open circuit voltage estimate
|
||||
float32 volt_based_soc_estimate # [@range 0, 1] Normalized volt based state of charge estimate
|
||||
float32 voltage_prediction # [V] Predicted voltage
|
||||
float32 prediction_error # [V] Prediction error
|
||||
float32 estimation_covariance_norm # Norm of the covariance matrix
|
||||
@@ -6,12 +6,9 @@
|
||||
|
||||
#include <translation_util.h>
|
||||
|
||||
//#include "example_translation_direct_v1.h"
|
||||
//#include "example_translation_multi_v2.h"
|
||||
//#include "example_translation_service_v1.h"
|
||||
|
||||
#include "translation_vehicle_status_v1.h"
|
||||
#include "translation_airspeed_validated_v1.h"
|
||||
#include "translation_vehicle_attitude_setpoint_v1.h"
|
||||
#include "translation_arming_check_reply_v1.h"
|
||||
#include "translation_battery_status_v1.h"
|
||||
#include "translation_event_v1.h"
|
||||
#include "translation_vehicle_attitude_setpoint_v1.h"
|
||||
#include "translation_vehicle_status_v1.h"
|
||||
|
||||
@@ -0,0 +1,114 @@
|
||||
/****************************************************************************
|
||||
* Copyright (c) 2025 PX4 Development Team.
|
||||
* SPDX-License-Identifier: BSD-3-Clause
|
||||
****************************************************************************/
|
||||
#pragma once
|
||||
|
||||
// Translate BatteryStatus v0 <--> v1
|
||||
#include <px4_msgs_old/msg/battery_status_v0.hpp>
|
||||
#include <px4_msgs/msg/battery_status.hpp>
|
||||
|
||||
class BatteryStatusV1Translation {
|
||||
public:
|
||||
using MessageOlder = px4_msgs_old::msg::BatteryStatusV0;
|
||||
static_assert(MessageOlder::MESSAGE_VERSION == 0);
|
||||
|
||||
using MessageNewer = px4_msgs::msg::BatteryStatus;
|
||||
static_assert(MessageNewer::MESSAGE_VERSION == 1);
|
||||
|
||||
static constexpr const char* kTopic = "fmu/out/battery_status";
|
||||
|
||||
static void fromOlder(const MessageOlder &msg_older, MessageNewer &msg_newer) {
|
||||
msg_newer.timestamp = msg_older.timestamp;
|
||||
msg_newer.connected = msg_older.connected;
|
||||
msg_newer.voltage_v = msg_older.voltage_v;
|
||||
msg_newer.current_a = msg_older.current_a;
|
||||
msg_newer.current_average_a = msg_older.current_average_a;
|
||||
msg_newer.discharged_mah = msg_older.discharged_mah;
|
||||
msg_newer.remaining = msg_older.remaining;
|
||||
msg_newer.scale = msg_older.scale;
|
||||
msg_newer.time_remaining_s = msg_older.time_remaining_s;
|
||||
msg_newer.temperature = msg_older.temperature;
|
||||
msg_newer.cell_count = msg_older.cell_count;
|
||||
msg_newer.source = msg_older.source;
|
||||
msg_newer.priority = msg_older.priority;
|
||||
msg_newer.capacity = msg_older.capacity;
|
||||
msg_newer.cycle_count = msg_older.cycle_count;
|
||||
msg_newer.average_time_to_empty = msg_older.average_time_to_empty;
|
||||
// The serial number moved to the battery_info message and is char[32] instead of uint16
|
||||
msg_newer.manufacture_date = msg_older.manufacture_date;
|
||||
msg_newer.state_of_health = msg_older.state_of_health;
|
||||
msg_newer.max_error = msg_older.max_error;
|
||||
msg_newer.id = msg_older.id;
|
||||
msg_newer.interface_error = msg_older.interface_error;
|
||||
|
||||
for (int i = 0; i < 14; ++i) {
|
||||
msg_newer.voltage_cell_v[i] = msg_older.voltage_cell_v[i];
|
||||
}
|
||||
|
||||
msg_newer.max_cell_voltage_delta = msg_older.max_cell_voltage_delta;
|
||||
msg_newer.is_powering_off = msg_older.is_powering_off;
|
||||
msg_newer.is_required = msg_older.is_required;
|
||||
msg_newer.warning = msg_older.warning;
|
||||
msg_newer.faults = msg_older.faults;
|
||||
msg_newer.full_charge_capacity_wh = msg_older.full_charge_capacity_wh;
|
||||
msg_newer.remaining_capacity_wh = msg_older.remaining_capacity_wh;
|
||||
msg_newer.over_discharge_count = msg_older.over_discharge_count;
|
||||
msg_newer.nominal_voltage = msg_older.nominal_voltage;
|
||||
msg_newer.internal_resistance_estimate = msg_older.internal_resistance_estimate;
|
||||
msg_newer.ocv_estimate = msg_older.ocv_estimate;
|
||||
msg_newer.ocv_estimate_filtered = msg_older.ocv_estimate_filtered;
|
||||
msg_newer.volt_based_soc_estimate = msg_older.volt_based_soc_estimate;
|
||||
msg_newer.voltage_prediction = msg_older.voltage_prediction;
|
||||
msg_newer.prediction_error = msg_older.prediction_error;
|
||||
msg_newer.estimation_covariance_norm = msg_older.estimation_covariance_norm;
|
||||
}
|
||||
|
||||
static void toOlder(const MessageNewer &msg_newer, MessageOlder &msg_older) {
|
||||
msg_older.timestamp = msg_newer.timestamp;
|
||||
msg_older.connected = msg_newer.connected;
|
||||
msg_older.voltage_v = msg_newer.voltage_v;
|
||||
msg_older.current_a = msg_newer.current_a;
|
||||
msg_older.current_average_a = msg_newer.current_average_a;
|
||||
msg_older.discharged_mah = msg_newer.discharged_mah;
|
||||
msg_older.remaining = msg_newer.remaining;
|
||||
msg_older.scale = msg_newer.scale;
|
||||
msg_older.time_remaining_s = msg_newer.time_remaining_s;
|
||||
msg_older.temperature = msg_newer.temperature;
|
||||
msg_older.cell_count = msg_newer.cell_count;
|
||||
msg_older.source = msg_newer.source;
|
||||
msg_older.priority = msg_newer.priority;
|
||||
msg_older.capacity = msg_newer.capacity;
|
||||
msg_older.cycle_count = msg_newer.cycle_count;
|
||||
msg_older.average_time_to_empty = msg_newer.average_time_to_empty;
|
||||
msg_older.serial_number = 0; // The serial number moved to the battery_info message and is char[32] instead of uint16
|
||||
msg_older.manufacture_date = msg_newer.manufacture_date;
|
||||
msg_older.state_of_health = msg_newer.state_of_health;
|
||||
msg_older.max_error = msg_newer.max_error;
|
||||
msg_older.id = msg_newer.id;
|
||||
msg_older.interface_error = msg_newer.interface_error;
|
||||
|
||||
for (int i = 0; i < 14; ++i) {
|
||||
msg_older.voltage_cell_v[i] = msg_newer.voltage_cell_v[i];
|
||||
}
|
||||
|
||||
msg_older.max_cell_voltage_delta = msg_newer.max_cell_voltage_delta;
|
||||
msg_older.is_powering_off = msg_newer.is_powering_off;
|
||||
msg_older.is_required = msg_newer.is_required;
|
||||
msg_older.warning = msg_newer.warning;
|
||||
msg_older.faults = msg_newer.faults;
|
||||
msg_older.full_charge_capacity_wh = msg_newer.full_charge_capacity_wh;
|
||||
msg_older.remaining_capacity_wh = msg_newer.remaining_capacity_wh;
|
||||
msg_older.over_discharge_count = msg_newer.over_discharge_count;
|
||||
msg_older.nominal_voltage = msg_newer.nominal_voltage;
|
||||
msg_older.internal_resistance_estimate = msg_newer.internal_resistance_estimate;
|
||||
msg_older.ocv_estimate = msg_newer.ocv_estimate;
|
||||
msg_older.ocv_estimate_filtered = msg_newer.ocv_estimate_filtered;
|
||||
msg_older.volt_based_soc_estimate = msg_newer.volt_based_soc_estimate;
|
||||
msg_older.voltage_prediction = msg_newer.voltage_prediction;
|
||||
msg_older.prediction_error = msg_newer.prediction_error;
|
||||
msg_older.estimation_covariance_norm = msg_newer.estimation_covariance_norm;
|
||||
}
|
||||
};
|
||||
|
||||
REGISTER_TOPIC_TRANSLATION_DIRECT(BatteryStatusV1Translation);
|
||||
@@ -1,15 +1,16 @@
|
||||
# Motor control message
|
||||
#
|
||||
# Normalised thrust setpoint for up to 12 motors.
|
||||
# Published by the vehicle's allocation and consumed by the ESC protocol drivers e.g. PWM, DSHOT, UAVCAN.
|
||||
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
|
||||
uint64 timestamp # time since system start (microseconds)
|
||||
uint64 timestamp_sample # the timestamp the data this control response is based on was sampled
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Sampling timestamp of the data this control response is based on
|
||||
|
||||
uint16 reversible_flags # bitset which motors are configured to be reversible
|
||||
uint16 reversible_flags # Bitset indicating which motors are configured to be reversible
|
||||
|
||||
uint8 ACTUATOR_FUNCTION_MOTOR1 = 101
|
||||
|
||||
uint8 NUM_CONTROLS = 12
|
||||
float32[12] control # range: [-1, 1], where 1 means maximum positive thrust,
|
||||
# -1 maximum negative (if not supported by the output, <0 maps to NaN),
|
||||
# and NaN maps to disarmed (stop the motors)
|
||||
float32[12] control # [@range -1, 1] Normalized thrust. where 1 means maximum positive thrust, -1 maximum negative (if not supported by the output, <0 maps to NaN). NaN maps to disarmed (stop the motors)
|
||||
|
||||
@@ -1,11 +1,12 @@
|
||||
# Servo control message
|
||||
#
|
||||
# Normalised output setpoint for up to 8 servos.
|
||||
# Published by the vehicle's allocation and consumed by the actuator output drivers.
|
||||
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
|
||||
uint64 timestamp # time since system start (microseconds)
|
||||
uint64 timestamp_sample # the timestamp the data this control response is based on was sampled
|
||||
uint64 timestamp # [us] Time since system start
|
||||
uint64 timestamp_sample # [us] Sampling timestamp of the data this control response is based on
|
||||
|
||||
uint8 NUM_CONTROLS = 8
|
||||
float32[8] control # range: [-1, 1], where 1 means maximum positive position,
|
||||
# -1 maximum negative,
|
||||
# and NaN maps to disarmed
|
||||
float32[8] control # [@range -1, 1] Normalized output. 1 means maximum positive position. -1 maximum negative position (if not supported by the output, <0 maps to NaN). NaN maps to disarmed.
|
||||
|
||||
@@ -1,74 +1,78 @@
|
||||
uint32 MESSAGE_VERSION = 0
|
||||
|
||||
uint64 timestamp # time since system start (microseconds)
|
||||
bool connected # Whether or not a battery is connected, based on a voltage threshold
|
||||
float32 voltage_v # Battery voltage in volts, 0 if unknown
|
||||
float32 current_a # Battery current in amperes, -1 if unknown
|
||||
float32 current_average_a # Battery current average in amperes (for FW average in level flight), -1 if unknown
|
||||
float32 discharged_mah # Discharged amount in mAh, -1 if unknown
|
||||
float32 remaining # From 1 to 0, -1 if unknown
|
||||
float32 scale # Power scaling factor, >= 1, or -1 if unknown
|
||||
float32 time_remaining_s # predicted time in seconds remaining until battery is empty under previous averaged load, NAN if unknown
|
||||
float32 temperature # Temperature of the battery in degrees Celcius, NaN if unknown
|
||||
uint8 cell_count # Number of cells, 0 if unknown
|
||||
|
||||
uint8 SOURCE_POWER_MODULE = 0
|
||||
uint8 SOURCE_EXTERNAL = 1
|
||||
uint8 SOURCE_ESCS = 2
|
||||
uint8 source # Battery source
|
||||
uint8 priority # Zero based priority is the connection on the Power Controller V1..Vn AKA BrickN-1
|
||||
uint16 capacity # actual capacity of the battery
|
||||
uint16 cycle_count # number of discharge cycles the battery has experienced
|
||||
uint16 average_time_to_empty # predicted remaining battery capacity based on the average rate of discharge in min
|
||||
uint16 serial_number # serial number of the battery pack
|
||||
uint16 manufacture_date # manufacture date, part of serial number of the battery pack. Formatted as: Day + Month×32 + (Year–1980)×512
|
||||
uint16 state_of_health # state of health. FullChargeCapacity/DesignCapacity, 0-100%.
|
||||
uint16 max_error # max error, expected margin of error in % in the state-of-charge calculation with a range of 1 to 100%
|
||||
uint8 id # ID number of a battery. Should be unique and consistent for the lifetime of a vehicle. 1-indexed.
|
||||
uint16 interface_error # interface error counter
|
||||
|
||||
float32[14] voltage_cell_v # Battery individual cell voltages, 0 if unknown
|
||||
float32 max_cell_voltage_delta # Max difference between individual cell voltages
|
||||
|
||||
bool is_powering_off # Power off event imminent indication, false if unknown
|
||||
bool is_required # Set if the battery is explicitly required before arming
|
||||
|
||||
|
||||
uint8 WARNING_NONE = 0 # no battery low voltage warning active
|
||||
uint8 WARNING_LOW = 1 # warning of low voltage
|
||||
uint8 WARNING_CRITICAL = 2 # critical voltage, return / abort immediately
|
||||
uint8 WARNING_EMERGENCY = 3 # immediate landing required
|
||||
uint8 WARNING_FAILED = 4 # the battery has failed completely
|
||||
uint8 STATE_UNHEALTHY = 6 # Battery is diagnosed to be defective or an error occurred, usage is discouraged / prohibited. Possible causes (faults) are listed in faults field.
|
||||
uint8 STATE_CHARGING = 7 # Battery is charging
|
||||
|
||||
uint8 FAULT_DEEP_DISCHARGE = 0 # Battery has deep discharged
|
||||
uint8 FAULT_SPIKES = 1 # Voltage spikes
|
||||
uint8 FAULT_CELL_FAIL= 2 # One or more cells have failed
|
||||
uint8 FAULT_OVER_CURRENT = 3 # Over-current
|
||||
uint8 FAULT_OVER_TEMPERATURE = 4 # Over-temperature
|
||||
uint8 FAULT_UNDER_TEMPERATURE = 5 # Under-temperature fault
|
||||
uint8 FAULT_INCOMPATIBLE_VOLTAGE = 6 # Vehicle voltage is not compatible with this battery (batteries on same power rail should have similar voltage).
|
||||
uint8 FAULT_INCOMPATIBLE_FIRMWARE = 7 # Battery firmware is not compatible with current autopilot firmware
|
||||
uint8 FAULT_INCOMPATIBLE_MODEL = 8 # Battery model is not supported by the system
|
||||
uint8 FAULT_HARDWARE_FAILURE = 9 # hardware problem
|
||||
uint8 FAULT_FAILED_TO_ARM = 10 # Battery had a problem while arming
|
||||
uint8 FAULT_COUNT = 11 # Counter - keep it as last element!
|
||||
|
||||
uint16 faults # Smart battery supply status/fault flags (bitmask) for health indication.
|
||||
uint8 warning # Current battery warning
|
||||
# Battery status
|
||||
#
|
||||
# Battery status information for up to 4 battery instances.
|
||||
# These are populated from power module and smart battery device drivers, and one battery updated from MAVLink.
|
||||
# Battery instance information is also logged and streamed in MAVLink telemetry.
|
||||
|
||||
uint32 MESSAGE_VERSION = 1
|
||||
uint8 MAX_INSTANCES = 4
|
||||
|
||||
float32 full_charge_capacity_wh # The compensated battery capacity
|
||||
float32 remaining_capacity_wh # The compensated battery capacity remaining
|
||||
uint16 over_discharge_count # Number of battery overdischarge
|
||||
float32 nominal_voltage # Nominal voltage of the battery pack
|
||||
uint64 timestamp # [us] Time since system start
|
||||
bool connected # Whether or not a battery is connected. For power modules this is based on a voltage threshold.
|
||||
float32 voltage_v # [V] [@invalid 0] Battery voltage
|
||||
float32 current_a # [A] [@invalid -1] Battery current
|
||||
float32 current_average_a # [A] [@invalid -1] Battery current average (for FW average in level flight)
|
||||
float32 discharged_mah # [mAh] [@invalid -1] Discharged amount
|
||||
float32 remaining # [@range 0,1] [@invalid -1] Remaining capacity
|
||||
float32 scale # [@range 1,] [@invalid -1] Scaling factor to compensate for lower actuation power caused by voltage sag
|
||||
float32 time_remaining_s # [s] [@invalid NaN] Predicted time remaining until battery is empty under previous averaged load
|
||||
float32 temperature # [°C] [@invalid NaN] Temperature of the battery
|
||||
uint8 cell_count # [@invalid 0] Number of cells
|
||||
|
||||
float32 internal_resistance_estimate # [Ohm] Internal resistance per cell estimate
|
||||
float32 ocv_estimate # [V] Open circuit voltage estimate
|
||||
float32 ocv_estimate_filtered # [V] Filtered open circuit voltage estimate
|
||||
float32 volt_based_soc_estimate # [0, 1] Normalized volt based state of charge estimate
|
||||
float32 voltage_prediction # [V] Predicted voltage
|
||||
float32 prediction_error # [V] Prediction error
|
||||
float32 estimation_covariance_norm # Norm of the covariance matrix
|
||||
|
||||
uint8 source # [@enum SOURCE] Battery source
|
||||
uint8 SOURCE_POWER_MODULE = 0 # Power module
|
||||
uint8 SOURCE_EXTERNAL = 1 # External
|
||||
uint8 SOURCE_ESCS = 2 # ESCs
|
||||
|
||||
uint8 priority # Zero based priority is the connection on the Power Controller V1..Vn AKA BrickN-1
|
||||
uint16 capacity # [mAh] Capacity of the battery when fully charged
|
||||
uint16 cycle_count # Number of discharge cycles the battery has experienced
|
||||
uint16 average_time_to_empty # [minutes] Predicted remaining battery capacity based on the average rate of discharge
|
||||
uint16 manufacture_date # Manufacture date, part of serial number of the battery pack. Formatted as: Day + Month×32 + (Year–1980)×512
|
||||
uint16 state_of_health # [%] [@range 0, 100] State of health. FullChargeCapacity/DesignCapacity
|
||||
uint16 max_error # [%] [@range 1, 100] Max error, expected margin of error in the state-of-charge calculation
|
||||
uint8 id # ID number of a battery. Should be unique and consistent for the lifetime of a vehicle. 1-indexed
|
||||
uint16 interface_error # Interface error counter
|
||||
|
||||
float32[14] voltage_cell_v # [V] [@invalid 0] Battery individual cell voltages
|
||||
float32 max_cell_voltage_delta # Max difference between individual cell voltages
|
||||
|
||||
bool is_powering_off # Power off event imminent indication, false if unknown
|
||||
bool is_required # Set if the battery is explicitly required before arming
|
||||
|
||||
uint8 warning # [@enum WARNING STATE] Current battery warning
|
||||
uint8 WARNING_NONE = 0 # No battery low voltage warning active
|
||||
uint8 WARNING_LOW = 1 # Low voltage warning
|
||||
uint8 WARNING_CRITICAL = 2 # Critical voltage, return / abort immediately
|
||||
uint8 WARNING_EMERGENCY = 3 # Immediate landing required
|
||||
uint8 WARNING_FAILED = 4 # Battery has failed completely
|
||||
uint8 STATE_UNHEALTHY = 6 # Battery is diagnosed to be defective or an error occurred, usage is discouraged / prohibited. Possible causes (faults) are listed in faults field
|
||||
uint8 STATE_CHARGING = 7 # Battery is charging
|
||||
|
||||
uint16 faults # [@enum FAULT] Smart battery supply status/fault flags (bitmask) for health indication
|
||||
uint8 FAULT_DEEP_DISCHARGE = 0 # Battery has deep discharged
|
||||
uint8 FAULT_SPIKES = 1 # Voltage spikes
|
||||
uint8 FAULT_CELL_FAIL= 2 # One or more cells have failed
|
||||
uint8 FAULT_OVER_CURRENT = 3 # Over-current
|
||||
uint8 FAULT_OVER_TEMPERATURE = 4 # Over-temperature
|
||||
uint8 FAULT_UNDER_TEMPERATURE = 5 # Under-temperature fault
|
||||
uint8 FAULT_INCOMPATIBLE_VOLTAGE = 6 # Vehicle voltage is not compatible with this battery (batteries on same power rail should have similar voltage)
|
||||
uint8 FAULT_INCOMPATIBLE_FIRMWARE = 7 # Battery firmware is not compatible with current autopilot firmware
|
||||
uint8 FAULT_INCOMPATIBLE_MODEL = 8 # Battery model is not supported by the system
|
||||
uint8 FAULT_HARDWARE_FAILURE = 9 # Hardware problem
|
||||
uint8 FAULT_FAILED_TO_ARM = 10 # Battery had a problem while arming
|
||||
uint8 FAULT_COUNT = 11 # Counter. Keep this as last element
|
||||
|
||||
float32 full_charge_capacity_wh # [Wh] Compensated battery capacity
|
||||
float32 remaining_capacity_wh # [Wh] Compensated battery capacity remaining
|
||||
uint16 over_discharge_count # Number of battery overdischarge
|
||||
float32 nominal_voltage # [V] Nominal voltage of the battery pack
|
||||
|
||||
float32 internal_resistance_estimate # [Ohm] Internal resistance per cell estimate
|
||||
float32 ocv_estimate # [V] Open circuit voltage estimate
|
||||
float32 ocv_estimate_filtered # [V] Filtered open circuit voltage estimate
|
||||
float32 volt_based_soc_estimate # [@range 0, 1] Normalized volt based state of charge estimate
|
||||
float32 voltage_prediction # [V] Predicted voltage
|
||||
float32 prediction_error # [V] Prediction error
|
||||
float32 estimation_covariance_norm # Norm of the covariance matrix
|
||||
|
||||
@@ -89,6 +89,7 @@ uint8 HIL_STATE_ON = 1
|
||||
|
||||
# Current vehicle locomotion method. A vehicle can have different methods (e.g. VTOL transitions from RW to FW method)
|
||||
uint8 vehicle_type
|
||||
uint8 VEHICLE_TYPE_UNSPECIFIED = 0
|
||||
uint8 VEHICLE_TYPE_ROTARY_WING = 1
|
||||
uint8 VEHICLE_TYPE_FIXED_WING = 2
|
||||
uint8 VEHICLE_TYPE_ROVER = 3
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
## FlightTaskManualAltitude
|
||||
- dist_bottom_var -- currently terrain variance, I see occasionally dist_bottom diverge and then clamp back to expected
|
||||
- ground slowdown (_respectGroundSlowdown) uses mpc_land_alt ... weird, remove?
|
||||
- _respectMaxAltitude ... weird, remove? We can instead use dist_bottom validity
|
||||
- _respectMinAltitude ... weird, remove? No need for a function
|
||||
|
||||
|
||||
## FlightTask
|
||||
- _dist_to_bottom and _dist_to_ground ... confusing, unify
|
||||
-
|
||||
|
||||
## FlightTaskAuto
|
||||
- reuse logic for range alt lock
|
||||
- _prepareLandSetpoints -- Slow down automatic descend close to ground ... use only with terrain estimate available? (baro estimate unreliable)
|
||||
|
||||
## EKF
|
||||
- Vz does not reflect true Vz due to noisy baro
|
||||
- Vz errors cause rangefinder kinematic consistency check to fail
|
||||
- Position setpoint error remains over long periods (might be related to Vz issues above)
|
||||
|
||||
@@ -77,6 +77,7 @@ BATT_SMBUS::BATT_SMBUS(const I2CSPIDriverConfig &config, SMBus *interface) :
|
||||
|
||||
BATT_SMBUS::~BATT_SMBUS()
|
||||
{
|
||||
orb_unadvertise(_battery_info_topic);
|
||||
orb_unadvertise(_batt_topic);
|
||||
perf_free(_cycle);
|
||||
|
||||
@@ -165,7 +166,6 @@ void BATT_SMBUS::RunImpl()
|
||||
if (ret == PX4_OK) {
|
||||
new_report.capacity = _batt_capacity;
|
||||
new_report.cycle_count = _cycle_count;
|
||||
new_report.serial_number = _serial_number;
|
||||
new_report.max_cell_voltage_delta = _max_cell_voltage_delta;
|
||||
new_report.cell_count = _cell_count;
|
||||
new_report.state_of_health = _state_of_health;
|
||||
@@ -192,6 +192,13 @@ void BATT_SMBUS::RunImpl()
|
||||
int instance = 0;
|
||||
orb_publish_auto(ORB_ID(battery_status), &_batt_topic, &new_report, &instance);
|
||||
|
||||
battery_info_s battery_info{};
|
||||
battery_info.timestamp = new_report.timestamp;
|
||||
battery_info.id = new_report.id;
|
||||
snprintf(battery_info.serial_number, sizeof(battery_info.serial_number), "%" PRIu16, _serial_number);
|
||||
orb_publish_auto(ORB_ID(battery_info), &_battery_info_topic, &battery_info, &instance);
|
||||
|
||||
|
||||
_last_report = new_report;
|
||||
}
|
||||
}
|
||||
|
||||
@@ -52,6 +52,7 @@
|
||||
#include <px4_platform_common/param.h>
|
||||
#include <px4_platform_common/getopt.h>
|
||||
#include <px4_platform_common/i2c_spi_buses.h>
|
||||
#include <uORB/topics/battery_info.h>
|
||||
#include <uORB/topics/battery_status.h>
|
||||
|
||||
#include <board_config.h>
|
||||
@@ -242,7 +243,7 @@ private:
|
||||
/** @param _last_report Last published report, used for test(). */
|
||||
battery_status_s _last_report{};
|
||||
|
||||
/** @param _batt_topic uORB battery topic. */
|
||||
orb_advert_t _battery_info_topic{nullptr};
|
||||
orb_advert_t _batt_topic{nullptr};
|
||||
|
||||
/** @param _cell_count Number of series cell. */
|
||||
|
||||
@@ -94,7 +94,6 @@ public:
|
||||
bat_status.connected = bat_info.status_flags & legacy_equipment_power_BatteryInfo_1_0_STATUS_FLAG_IN_USE;
|
||||
bat_status.source = 1; // External
|
||||
bat_status.capacity = bat_info.full_charge_capacity_wh;
|
||||
bat_status.serial_number = bat_info.model_instance_id & 0xFFFF; // Take first 16 bits
|
||||
bat_status.state_of_health = bat_info.state_of_health_pct; // External
|
||||
bat_status.id = bat_info.battery_id;
|
||||
|
||||
@@ -118,9 +117,17 @@ public:
|
||||
|
||||
_battery_status_pub.publish(bat_status);
|
||||
print_message(ORB_ID(battery_status), bat_status);
|
||||
|
||||
battery_info_s battery_info{};
|
||||
battery_info.timestamp = bat_status.timestamp;
|
||||
battery_info.id = bat_status.id;
|
||||
snprintf(battery_info.serial_number, sizeof(battery_info.serial_number), "%" PRIu32,
|
||||
bat_info.model_instance_id);
|
||||
_battery_info_pub.publish(battery_info);
|
||||
};
|
||||
|
||||
private:
|
||||
uORB::PublicationMulti<battery_info_s> _battery_info_pub{ORB_ID(battery_info)};
|
||||
uORB::PublicationMulti<battery_status_s> _battery_status_pub{ORB_ID(battery_status)};
|
||||
|
||||
};
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user