fly316/PX4-Autopilot
7
0
Fork 0
mirror of https://gitee.com/mirrors_PX4/PX4-Autopilot.git synced 2026-10-12 07:13:33 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'main' into dev-boat

Browse Source
This commit is contained in:
Pedro Roque
2026-01-14 11:53:54 -08:00
committed by GitHub
parent 076e07444d 8e658a6e2d
commit 8a700471b4
193 changed files with 4682 additions and 961 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/ISSUE_TEMPLATE/bug_report.yml
+29 -76
View File
@@ -3,92 +3,45 @@ description: Create a report to help us improve
title: "[Bug] "
labels: ["bug-report"]
body:
- type: markdown
attributes:
value: |
**Tips for a great bug report:**
- Describe what went wrong and what you expected
- Include a flight log link from [logs.px4.io](http://logs.px4.io/) if possible
- Mention your PX4 version, flight controller, and vehicle type if relevant
- type: textarea
attributes:
label: Describe the bug
description: A clear and concise description of the bug.
description: A clear description of the bug and what you expected to happen.
placeholder: |
What happened and what did you expect instead?
Steps to reproduce (if applicable):
1.
2.
3.
validations:
required: true
- type: textarea
attributes:
label: To Reproduce
label: Flight Log / Additional Information
description: |
Steps to reproduce the behavior.
1. Drone switched on '...'
2. Uploaded mission '....' (attach QGC mission file)
3. Took off '....'
4. See error
validations:
required: false
**Flight log** (highly recommended for flight-related issues):
- Upload to [PX4 Flight Review](http://logs.px4.io/) and paste the link
- type: textarea
attributes:
label: Expected behavior
description: A clear and concise description of what you expected to happen.
validations:
required: false
- type: textarea
attributes:
label: Screenshot / Media
description: Add screenshot / media if you have them
- type: textarea
attributes:
label: Flight Log
description: |
*Always* provide a link to the flight log file:
- Download the flight log file from the vehicle ([tutorial](https://docs.px4.io/main/en/getting_started/flight_reporting.html)).
- Upload the log to the [PX4 Flight Review](http://logs.px4.io/)
- Share the link to the log (Copy and paste the URL of the log)
**Additional details** (if relevant):
- PX4 version (output of `ver all` in MAVLink Shell)
- Flight controller model
- Vehicle type (multicopter, fixed-wing, VTOL, etc.)
- Screenshots or media
placeholder: |
# PASTE HERE THE LINK TO THE LOG
Flight log link:
Version:
Hardware:
validations:
required: false
- type: markdown
attributes:
value: |
## Setup
- type: textarea
attributes:
label: Software Version
description: |
Which version of PX4 are you using?
placeholder: |
# If you don't know the version, paste the output of `ver all` in the MAVLink Shell of QGC
validations:
required: false
- type: input
attributes:
label: Flight controller
description: Specify your flight controller model (what type is it, where was it bought from, ...).
validations:
required: false
- type: dropdown
attributes:
label: Vehicle type
options:
- Multicopter
- Helicopter
- Fixed Wing
- Hybrid VTOL
- Airship/Balloon
- Rover
- Boat
- Submarine
- Other
- type: textarea
attributes:
label: How are the different components wired up (including port information)
description: Details about how all is wired.
- type: textarea
attributes:
label: Additional context
description: Add any other context about the problem here.
.github/ISSUE_TEMPLATE/config.yml
+1 -1
View File
@@ -1,4 +1,4 @@
blank_issues_enabled: false
blank_issues_enabled: true
contact_links:
- name: Support Question
url: https://docs.px4.io/main/en/contribute/support.html#forums-and-chat
.gitmodules
+6
View File
@@ -103,3 +103,9 @@
[submodule "src/drivers/ins/sbgecom/sbgECom"]
path = src/drivers/ins/sbgecom/sbgECom
url = https://github.com/PX4/sbgECom.git
[submodule "src/modules/mc_raptor/blob"]
path = src/modules/mc_raptor/blob
url = https://github.com/rl-tools/px4-blob
[submodule "src/lib/rl_tools/rl_tools"]
path = src/lib/rl_tools/rl_tools
url = https://github.com/rl-tools/rl-tools.git
.vscode/cmake-variants.yaml
Vendored
+10
View File
@@ -6,6 +6,16 @@ CONFIG:
buildType: RelWithDebInfo
settings:
CONFIG: px4_sitl_default
px4_sitl_raptor:
short: px4_sitl_raptor
buildType: RelWithDebInfo
settings:
CONFIG: px4_sitl_raptor
px4_sitl_raptor_debug:
short: px4_sitl_raptor_debug
buildType: Debug
settings:
CONFIG: px4_sitl_raptor
px4_sitl_spacecraft:
short: px4_sitl_spacecraft
buildType: RelWithDebInfo
CMakeLists.txt
+1 -1
View File
@@ -267,7 +267,7 @@ endif()
set(package-contact "px4users@googlegroups.com")
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_C_STANDARD 11)
set(CMAKE_C_STANDARD_REQUIRED ON)
ROMFS/px4fmu_common/init.d-posix/rcS
+9 -9
View File
@@ -126,15 +126,6 @@ then
set AUTOCNF yes
fi
# Allow overriding parameters via env variables: export PX4_PARAM_{name}={value}
env | while IFS='=' read -r line; do
value=${line#*=}
name=${line%%=*}
case $name in
"PX4_PARAM_"*) param set "${name#PX4_PARAM_}" "$value" ;;
esac
done
# multi-instance setup
# shellcheck disable=SC2154
param set MAV_SYS_ID $((px4_instance+1))
@@ -238,6 +229,15 @@ then
exit 1
fi
# Allow overriding parameters via env variables: export PX4_PARAM_{name}={value}
env | while IFS='=' read -r line; do
value=${line#*=}
name=${line%%=*}
case $name in
"PX4_PARAM_"*) param set "${name#PX4_PARAM_}" "$value" ;;
esac
done
dataman start
# only start the simulator if not in replay mode, as both control the lockstep time
ROMFS/px4fmu_common/init.d/airframes/4016_holybro_px4vision
-3
View File
@@ -77,9 +77,6 @@ param set-default NAV_ACC_RAD 2
param set-default RTL_DESCEND_ALT 5
param set-default RTL_RETURN_ALT 5
# Logging Parameters
param set-default SDLOG_PROFILE 131
# Sensors Parameters
param set-default SENS_CM8JL65_CFG 104
param set-default SENS_FLOW_MAXHGT 25
ROMFS/px4fmu_common/init.d/airframes/4020_holybro_px4vision_v1_5
-3
View File
@@ -78,9 +78,6 @@ param set-default NAV_ACC_RAD 2
param set-default RTL_DESCEND_ALT 5
param set-default RTL_RETURN_ALT 5
# Logging Parameters
param set-default SDLOG_PROFILE 131
# Sensors Parameters
param set-default SENS_CM8JL65_CFG 202
param set-default SENS_FLOW_MAXHGT 25
ROMFS/px4fmu_common/init.d/airframes/4050_generic_250
-3
View File
@@ -29,9 +29,6 @@ param set-default MPC_MAN_TILT_MAX 60
param set-default THR_MDL_FAC 0.3
# enable high-rate logging profile (helps with tuning)
param set-default SDLOG_PROFILE 19
param set-default IMU_DGYRO_CUTOFF 50
param set-default IMU_GYRO_CUTOFF 90
ROMFS/px4fmu_common/init.d/airframes/70000_atmos
+3
View File
@@ -20,6 +20,9 @@
. ${R}etc/init.d/rc.sc_defaults
# Overwrite DDS AG IP to `192.168.0.1`
param set-default UXRCE_DDS_AG_IP -1062731775
param set-default CA_AIRFRAME 14
param set-default MAV_TYPE 45
ROMFS/px4fmu_common/init.d/rc.mc_apps
+6
View File
@@ -41,3 +41,9 @@ if param compare -s MC_NN_EN 1
then
mc_nn_control start
fi
if param compare -s MC_RAPTOR_ENABLE 1
then
mc_raptor start
fi
ROMFS/px4fmu_common/init.d/rc.sc_defaults
-3
View File
@@ -8,9 +8,6 @@ set VEHICLE_TYPE spacecraft
# 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
# Disable preflight disarm to not interfere with external launching
param set-default COM_DISARM_PRFLT -1
param set-default CBRK_SUPPLY_CHK 894281
ROMFS/px4fmu_common/init.d/rc.sensors
+6
View File
@@ -237,6 +237,12 @@ then
tla2528 start -X
fi
# Start TMP102 temperature sensor
if param compare SENS_EN_TMP102 1
then
tmp102 start -X
fi
# probe for optional external I2C devices
if param compare SENS_EXT_I2C_PRB 1
then
Tools/check_submodules.sh
+3 -28
View File
@@ -17,37 +17,12 @@ if [[ -f $1"/.git" || -d $1"/.git" ]]; then
SUBMODULE_STATUS=$(git submodule summary "$1")
STATUSRETVAL=$(echo $SUBMODULE_STATUS | grep -A20 -i "$1")
if ! [[ -z "$STATUSRETVAL" ]]; then
echo -e "\033[31mChecked $1 submodule, ACTION REQUIRED:\033[0m"
echo ""
echo -e "Different commits:"
echo -e "\033[33mWarning: $1 submodule has uncommitted changes:\033[0m"
echo -e "$SUBMODULE_STATUS"
echo ""
echo -e "To update submodules to the expected version, run:"
echo -e " \033[94mgit submodule sync --recursive && git submodule update --init --recursive\033[0m"
echo ""
echo -e " *******************************************************************************"
echo -e " * \033[31mIF YOU DID NOT CHANGE THIS FILE (OR YOU DON'T KNOW WHAT A SUBMODULE IS):\033[0m *"
echo -e " * \033[31mHit 'u' and <ENTER> to update ALL submodules and resolve this.\033[0m *"
echo -e " * (performs \033[94mgit submodule sync --recursive\033[0m *"
echo -e " * and \033[94mgit submodule update --init --recursive\033[0m ) *"
echo -e " *******************************************************************************"
echo ""
echo ""
echo -e " Only for EXPERTS:"
echo -e " $1 submodule is not in the recommended version."
echo -e " Hit 'y' and <ENTER> to continue the build with this version. Hit <ENTER> to resolve manually."
echo -e " Use \033[94mgit add $1 && git commit -m 'Updated $1'\033[0m to choose this version (careful!)"
echo ""
read user_cmd
if [ "$user_cmd" == "y" ]; then
echo "Continuing build with manually overridden submodule.."
elif [ "$user_cmd" == "u" ]; then
git submodule sync --recursive -- $1
git submodule update --init --recursive -- $1 || true
git submodule update --init --recursive --force -- $1
echo "Submodule fixed, continuing build.."
else
echo "Build aborted."
exit 1
fi
fi
else
git submodule --quiet sync --recursive --quiet -- $1
Tools/px_uploader.py
+8 -44
View File
@@ -98,40 +98,6 @@ class firmware(object):
desc = {}
image = bytes()
crctab = array.array('I', [
0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d])
crcpad = bytearray(b'\xff\xff\xff\xff')
def __init__(self, path):
@@ -149,17 +115,15 @@ class firmware(object):
def property(self, propname):
return self.desc[propname]
def __crc32(self, bytes, state):
for byte in bytes:
index = (state ^ byte) & 0xff
state = self.crctab[index] ^ (state >> 8)
return state
def crc(self, padlen):
state = self.__crc32(self.image, int(0))
for _ in range(len(self.image), (padlen - 1), 4):
state = self.__crc32(self.crcpad, state)
return state
state = 0xFFFFFFFF
state = zlib.crc32(self.image, state)
padding_length = padlen - len(self.image)
if padding_length > 0:
padding = b'\xff' * padding_length
state = zlib.crc32(padding, state)
return (state ^ 0xFFFFFFFF) & 0xFFFFFFFF
class uploader:
boards/px4/fmu-v6c/raptor.px4board
+95
View File
@@ -0,0 +1,95 @@
CONFIG_BOARD_ARCHITECTURE="cortex-m7"
CONFIG_BOARD_SERIAL_GPS1="/dev/ttyS0"
CONFIG_BOARD_SERIAL_GPS2="/dev/ttyS6"
CONFIG_BOARD_SERIAL_TEL1="/dev/ttyS5"
CONFIG_BOARD_SERIAL_TEL2="/dev/ttyS3"
CONFIG_BOARD_SERIAL_TEL3="/dev/ttyS1"
CONFIG_BOARD_TOOLCHAIN="arm-none-eabi"
CONFIG_BOARD_UAVCAN_TIMER_OVERRIDE=2
CONFIG_COMMON_DIFFERENTIAL_PRESSURE=y
CONFIG_COMMON_DISTANCE_SENSOR=y
CONFIG_COMMON_LIGHT=y
CONFIG_COMMON_MAGNETOMETER=y
CONFIG_COMMON_OPTICAL_FLOW=y
CONFIG_COMMON_TELEMETRY=y
CONFIG_DRIVERS_ACTUATORS_VERTIQ_IO=y
CONFIG_DRIVERS_ADC_BOARD_ADC=y
CONFIG_DRIVERS_BAROMETER_MS5611=y
CONFIG_DRIVERS_BATT_SMBUS=y
CONFIG_DRIVERS_CAMERA_CAPTURE=y
CONFIG_DRIVERS_CAMERA_TRIGGER=y
CONFIG_DRIVERS_CDCACM_AUTOSTART=y
CONFIG_DRIVERS_DSHOT=y
CONFIG_DRIVERS_GNSS_SEPTENTRIO=y
CONFIG_DRIVERS_GPS=y
CONFIG_DRIVERS_HEATER=y
CONFIG_DRIVERS_IMU_BOSCH_BMI055=y
CONFIG_DRIVERS_IMU_BOSCH_BMI088=y
CONFIG_DRIVERS_IMU_INVENSENSE_ICM42688P=y
CONFIG_DRIVERS_POWER_MONITOR_INA226=y
CONFIG_DRIVERS_POWER_MONITOR_INA228=y
CONFIG_DRIVERS_POWER_MONITOR_INA238=y
CONFIG_DRIVERS_PWM_OUT=y
CONFIG_DRIVERS_PX4IO=y
CONFIG_DRIVERS_TONE_ALARM=y
CONFIG_DRIVERS_UAVCAN=y
CONFIG_LIB_RL_TOOLS=y
CONFIG_MODULES_AIRSPEED_SELECTOR=y
CONFIG_MODULES_BATTERY_STATUS=y
CONFIG_MODULES_CAMERA_FEEDBACK=y
CONFIG_MODULES_COMMANDER=y
CONFIG_MODULES_CONTROL_ALLOCATOR=y
CONFIG_MODULES_DATAMAN=y
CONFIG_MODULES_EKF2=y
CONFIG_MODULES_ESC_BATTERY=y
CONFIG_MODULES_EVENTS=y
CONFIG_MODULES_FLIGHT_MODE_MANAGER=y
CONFIG_MODULES_FW_ATT_CONTROL=n
CONFIG_MODULES_FW_AUTOTUNE_ATTITUDE_CONTROL=n
CONFIG_MODULES_FW_LATERAL_LONGITUDINAL_CONTROL=n
CONFIG_MODULES_FW_MODE_MANAGER=n
CONFIG_MODULES_FW_RATE_CONTROL=n
CONFIG_MODULES_GIMBAL=y
CONFIG_MODULES_GYRO_CALIBRATION=y
CONFIG_MODULES_LAND_DETECTOR=y
CONFIG_MODULES_LANDING_TARGET_ESTIMATOR=y
CONFIG_MODULES_LOAD_MON=y
CONFIG_MODULES_LOGGER=y
CONFIG_MODULES_MAG_BIAS_ESTIMATOR=y
CONFIG_MODULES_MANUAL_CONTROL=y
CONFIG_MODULES_MAVLINK=y
CONFIG_MODULES_MC_ATT_CONTROL=y
CONFIG_MODULES_MC_AUTOTUNE_ATTITUDE_CONTROL=y
CONFIG_MODULES_MC_HOVER_THRUST_ESTIMATOR=y
CONFIG_MODULES_MC_POS_CONTROL=y
CONFIG_MODULES_MC_RAPTOR=y
CONFIG_MODULES_MC_RATE_CONTROL=y
CONFIG_MODULES_NAVIGATOR=y
CONFIG_MODULES_RC_UPDATE=y
CONFIG_MODULES_SENSORS=y
CONFIG_MODULES_SIMULATION_SIMULATOR_SIH=y
CONFIG_MODULES_TEMPERATURE_COMPENSATION=y
CONFIG_MODULES_UXRCE_DDS_CLIENT=y
CONFIG_MODULES_VTOL_ATT_CONTROL=n
CONFIG_NUM_MISSION_ITMES_SUPPORTED=1000
CONFIG_SYSTEMCMDS_ACTUATOR_TEST=y
CONFIG_SYSTEMCMDS_BSONDUMP=y
CONFIG_SYSTEMCMDS_DMESG=y
CONFIG_SYSTEMCMDS_HARDFAULT_LOG=y
CONFIG_SYSTEMCMDS_I2CDETECT=y
CONFIG_SYSTEMCMDS_LED_CONTROL=y
CONFIG_SYSTEMCMDS_MFT=y
CONFIG_SYSTEMCMDS_MTD=y
CONFIG_SYSTEMCMDS_NSHTERM=y
CONFIG_SYSTEMCMDS_PARAM=y
CONFIG_SYSTEMCMDS_PERF=y
CONFIG_SYSTEMCMDS_REBOOT=y
CONFIG_SYSTEMCMDS_SD_BENCH=y
CONFIG_SYSTEMCMDS_SYSTEM_TIME=y
CONFIG_SYSTEMCMDS_TOPIC_LISTENER=y
CONFIG_SYSTEMCMDS_TOP=y
CONFIG_SYSTEMCMDS_TUNE_CONTROL=y
CONFIG_SYSTEMCMDS_UORB=y
CONFIG_SYSTEMCMDS_VER=y
CONFIG_SYSTEMCMDS_WORK_QUEUE=y
CONFIG_USE_IFCI_CONFIGURATION=y
boards/px4/sitl/raptor.px4board
+89
View File
@@ -0,0 +1,89 @@
CONFIG_BOARD_ETHERNET=y
CONFIG_BOARD_ROOT_PATH="."
CONFIG_BOARD_TESTING=y
CONFIG_COMMON_SIMULATION=y
CONFIG_DRIVERS_CAMERA_TRIGGER=y
CONFIG_DRIVERS_GNSS_SEPTENTRIO=y
CONFIG_DRIVERS_GPS=y
CONFIG_DRIVERS_OSD_MSP_OSD=y
CONFIG_DRIVERS_TONE_ALARM=y
CONFIG_EKF2_VERBOSE_STATUS=y
CONFIG_EXAMPLES_DYN_HELLO=y
CONFIG_EXAMPLES_FAKE_GPS=y
CONFIG_EXAMPLES_FAKE_IMU=y
CONFIG_EXAMPLES_FAKE_MAGNETOMETER=y
CONFIG_EXAMPLES_HELLO=y
CONFIG_EXAMPLES_PX4_MAVLINK_DEBUG=y
CONFIG_EXAMPLES_PX4_SIMPLE_APP=y
CONFIG_EXAMPLES_WORK_ITEM=y
CONFIG_FIGURE_OF_EIGHT=y
CONFIG_LIB_RL_TOOLS=y
CONFIG_MAVLINK_DIALECT="development"
CONFIG_MODE_NAVIGATOR_VTOL_TAKEOFF=y
CONFIG_MODULES_AIRSHIP_ATT_CONTROL=y
CONFIG_MODULES_AIRSPEED_SELECTOR=y
CONFIG_MODULES_ATTITUDE_ESTIMATOR_Q=y
CONFIG_MODULES_CAMERA_FEEDBACK=y
CONFIG_MODULES_COMMANDER=y
CONFIG_MODULES_CONTROL_ALLOCATOR=y
CONFIG_MODULES_DATAMAN=y
CONFIG_MODULES_EKF2=y
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_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
CONFIG_MODULES_GYRO_FFT=y
CONFIG_MODULES_LAND_DETECTOR=y
CONFIG_MODULES_LANDING_TARGET_ESTIMATOR=y
CONFIG_MODULES_LOAD_MON=y
CONFIG_MODULES_LOCAL_POSITION_ESTIMATOR=y
CONFIG_MODULES_LOGGER=y
CONFIG_MODULES_MAG_BIAS_ESTIMATOR=y
CONFIG_MODULES_MANUAL_CONTROL=y
CONFIG_MODULES_MAVLINK=y
CONFIG_MODULES_MC_ATT_CONTROL=y
CONFIG_MODULES_MC_AUTOTUNE_ATTITUDE_CONTROL=y
CONFIG_MODULES_MC_HOVER_THRUST_ESTIMATOR=y
CONFIG_MODULES_MC_POS_CONTROL=y
CONFIG_MODULES_MC_RAPTOR=y
CONFIG_MODULES_MC_RATE_CONTROL=y
CONFIG_MODULES_NAVIGATOR=y
CONFIG_MODULES_PAYLOAD_DELIVERER=y
CONFIG_MODULES_RC_UPDATE=y
CONFIG_MODULES_REPLAY=y
CONFIG_MODULES_ROVER_ACKERMANN=y
CONFIG_MODULES_ROVER_DIFFERENTIAL=y
CONFIG_MODULES_ROVER_MECANUM=y
CONFIG_MODULES_SENSORS=y
CONFIG_MODULES_SIMULATION_GZ_BRIDGE=y
CONFIG_MODULES_SIMULATION_GZ_MSGS=y
CONFIG_MODULES_SIMULATION_GZ_PLUGINS=y
CONFIG_MODULES_SIMULATION_SENSOR_AGP_SIM=y
CONFIG_MODULES_SPACECRAFT=n
CONFIG_MODULES_TEMPERATURE_COMPENSATION=y
CONFIG_MODULES_UUV_ATT_CONTROL=y
CONFIG_MODULES_UUV_POS_CONTROL=y
CONFIG_MODULES_UXRCE_DDS_CLIENT=y
CONFIG_MODULES_VTOL_ATT_CONTROL=y
CONFIG_NUM_MISSION_ITMES_SUPPORTED=10000
CONFIG_PLATFORM_POSIX=y
CONFIG_SYSTEMCMDS_ACTUATOR_TEST=y
CONFIG_SYSTEMCMDS_BSONDUMP=y
CONFIG_SYSTEMCMDS_DYN=y
CONFIG_SYSTEMCMDS_FAILURE=y
CONFIG_SYSTEMCMDS_LED_CONTROL=y
CONFIG_SYSTEMCMDS_PARAM=y
CONFIG_SYSTEMCMDS_PERF=y
CONFIG_SYSTEMCMDS_SD_BENCH=y
CONFIG_SYSTEMCMDS_SHUTDOWN=y
CONFIG_SYSTEMCMDS_SYSTEM_TIME=y
CONFIG_SYSTEMCMDS_TOPIC_LISTENER=y
CONFIG_SYSTEMCMDS_TUNE_CONTROL=y
CONFIG_SYSTEMCMDS_UORB=y
CONFIG_SYSTEMCMDS_VER=y
CONFIG_SYSTEMCMDS_WORK_QUEUE=y
docs/assets/advanced/neural_networks/raptor/method.jpg
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 550 KiB

docs/assets/advanced/neural_networks/raptor/results_figure_eight.svg
+1
View File
File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 81 KiB

docs/assets/advanced/neural_networks/raptor/results_line.svg
+1
View File
File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 57 KiB

docs/assets/advanced/neural_networks/raptor/visual_abstract.jpg
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 204 KiB

docs/assets/config/actuators/qgc_actuators_gimbal.png
BIN
View File
Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 5.5 KiB

After

Width:  |  Height:  |  Size: 37 KiB

docs/assets/hardware/gps/ark/ark_g5_rtk_gps.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 210 KiB

docs/en/SUMMARY.md
+9 -4
View File
@@ -128,7 +128,7 @@
- [LED Meanings](getting_started/led_meanings.md)
- [Tune/Sound Meanings](getting_started/tunes.md)
- [QGroundControl Flight-Readiness Status](flying/pre_flight_checks.md)
- [Asset Tracking](debug/asset_tracking.md)
- [Hardware Selection & Setup](hardware/drone_parts.md)
- [Flight Controllers (Autopilots)](flight_controller/index.md)
- [Flight Controller Selection](getting_started/flight_controller_selection.md)
@@ -271,6 +271,8 @@
- [Holybro M8N & M9N GPS](gps_compass/gps_holybro_m8n_m9n.md)
- [Sky-Drones SmartAP GPS](gps_compass/gps_smartap.md)
- [RTK GNSS](gps_compass/rtk_gps.md)
- [ARK G5 RTK GPS](dronecan/ark_g5_rtk_gps.md)
- [ARK G5 RTK HEADING GPS](dronecan/ark_g5_rtk_heading_gps.md)
- [ARK RTK GPS (CAN)](dronecan/ark_rtk_gps.md)
- [ARK RTK GPS L1 L5 (CAN)](dronecan/ark_rtk_gps_l1_l2.md)
- [ARK X20 RTK GPS (CAN)](dronecan/ark_x20_rtk_gps.md)
@@ -820,9 +822,11 @@
- [Camera Integration/Architecture](camera/camera_architecture.md)
- [Computer Vision](advanced/computer_vision.md)
- [Motion Capture (VICON, Optitrack, NOKOV)](tutorials/motion-capture.md)
- [Neural Networks](advanced/neural_networks.md)
- [Neural Network Module Utilities](advanced/nn_module_utilities.md)
- [TensorFlow Lite Micro (TFLM)](advanced/tflm.md)
- [Neural Networks](neural_networks/index.md)
- [MC NN Control Module (Generic)](neural_networks/mc_neural_network_control.md)
- [Neural Network Module Utilities](neural_networks/nn_module_utilities.md)
- [TensorFlow Lite Micro (TFLM)](neural_networks/tflm.md)
- [RAPTOR Adaptive RL NN Module](neural_networks/raptor.md)
- [Installing driver for Intel RealSense R200](advanced/realsense_intel_driver.md)
- [Switching State Estimators](advanced/switching_state_estimators.md)
- [Out-of-Tree Modules](advanced/out_of_tree_modules.md)
@@ -902,6 +906,7 @@
- [Licenses](contribute/licenses.md)
- [Releases](releases/index.md)
- [main (alpha)](releases/main.md)
- [1.17 (alpha)](releases/1.17.md)
- [1.16 (stable)](releases/1.16.md)
- [1.15](releases/1.15.md)
- [1.14](releases/1.14.md)
docs/en/advanced/gimbal_control.md
+1 -1
View File
@@ -74,7 +74,7 @@ For example, you might have the following settings to assign the gimbal roll, pi
![Gimbal Actuator config](../../assets/config/actuators/qgc_actuators_gimbal.png)
The PWM values to use for the disarmed, maximum and minimum values can be determined in the same way as other servo, using the [Actuator Test sliders](../config/actuators.md#actuator-testing) to confirm that each slider moves the appropriate axis, and changing the values so that the gimbal is in the appropriate position at the disarmed, low and high position in the slider.
The PWM values to use for the disarmed, maximum, center and minimum values can be determined in the same way as other servo, using the [Actuator Test sliders](../config/actuators.md#actuator-testing) to confirm that each slider moves the appropriate axis, and changing the values so that the gimbal is in the appropriate position at the disarmed, low, center and high position in the slider.
The values may also be provided in gimbal documentation.
## Gimbal Control in Missions
docs/en/advanced/neural_networks.md
+1 -119
View File
@@ -1,119 +1 @@
# Neural Networks
<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />
::: warning
This is an experimental module.
Use at your own risk.
:::
The Multicopter Neural Network (NN) module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) is an example module that allows you to experiment with using a pre-trained neural network on PX4.
It might be used, for example, to experiment with controllers for non-traditional drone morphologies, computer vision tasks, and so on.
The module integrates a pre-trained neural network based on the [TensorFlow Lite Micro (TFLM)](../advanced/tflm.md) module.
The module is trained for the [X500 V2](../frames_multicopter/holybro_x500v2_pixhawk6c.md) multicopter frame.
While the controller is fairly robust, and might work on other platforms, we recommend [Training your own Network](#training-your-own-network) if you use a different vehicle.
Note that after training the network you will need to update and rebuild PX4.
TLFM is a mature inference library intended for use on embedded devices.
It has support for several architectures, so there is a high likelihood that you can build it for the board you want to use.
If not, there are other possible NN frameworks, such as [Eigen](https://eigen.tuxfamily.org/index.php?title=Main_Page) and [Executorch](https://pytorch.org/executorch-overview).
This document explains how you can include the module in your PX4 build, and provides a broad overview of how it works.
The other documents in the section provide more information about the integration, allowing you to replace the NN with a version trained on different data, or even to replace the TLFM library altogether.
If you are looking for more resources to learn about the module, a website has been created with links to a youtube video and a workshop paper. A full master's thesis will be added later. [A Neural Network Mode for PX4 on Embedded Flight Controllers](https://ntnu-arl.github.io/px4-nns/).
## Neural Network PX4 Firmware
::: warning
This module requires Ubuntu 24.04 or newer (it is not supported in Ubuntu 22.04).
:::
The module has been tested on a number of configurations, which can be build locally using the commands:
```sh
make px4_sitl_neural
```
```sh
make px4_fmu-v6c_neural
```
```sh
make mro_pixracerpro_neural
```
You can add the module to other board configurations by modifying their `default.px4board file` configuration to include these lines:
```sh
CONFIG_LIB_TFLM=y
CONFIG_MODULES_MC_NN_CONTROL=y
```
:::tip
The `mc_nn_control` module takes up roughly 50KB, and many of the `default.px4board file` are already close to filling all the flash on their boards. To make room for the neural control module you can remove the include statements for other modules, such as FW, rover, VTOL and UUV.
:::
## Example Module Overview
The example module replaces the entire controller structure as well as the control allocator, as shown in the diagram below:
![neural_control](../../assets/advanced/neural_control.png)
In the [controller diagram](../flight_stack/controller_diagrams.md) you can see the [uORB message](../middleware/uorb.md) flow.
We hook into this flow by subscribing to messages at particular points, using our neural network to calculate outputs, and then publishing them into the next point in the flow.
We also need to stop the module publishing the topic to be replaced, which is covered in [Neural Network Module: System Integration](nn_module_utilities.md)
### Input
The input can be changed to whatever you want.
Set up the input you want to use during training and then provide the same input in PX4.
In the Neural Control module the input is an array of 15 numbers, and consists of these values in this order:
- [3] Local position error. (goal position - current position)
- [6] The first 2 rows of a 3 dimensional rotation matrix.
- [3] Linear velocity
- [3] Angular velocity
All the input values are collected from uORB topics and transformed into the correct representation in the `PopulateInputTensor()` function.
PX4 uses the NED frame representation, while the Aerial Gym Simulator, in which the NN was trained, uses the ENU representation.
Therefore two rotation matrices are created in the function and all the inputs are transformed from the NED representation to the ENU one.
![ENU-NED](../../assets/advanced/ENU-NED.png)
ENU and NED are just rotation representations, the translational difference is only there so both can be seen in the same figure.
### Output
The output consists of 4 values, the motor forces, one for each motor.
These are transformed in the `RescaleActions()` function.
This is done because PX4 expects normalized motor commands while the Aerial Gym Simulator uses physical values.
So the output from the network needs to be normalized before they can be sent to the motors in PX4.
The commands are published to the [ActuatorMotors](../msg_docs/ActuatorMotors.md) topic.
The publishing is handled in `PublishOutput(float* command_actions)` function.
:::tip
If the neural control mode is too aggressive or unresponsive the [MC_NN_THRST_COEF](../advanced_config/parameter_reference.md#MC_NN_THRST_COEF) parameter can be tuned.
Decrease it for more thrust.
:::
## Training your own Network
The network is currently trained for the [X500 V2](../frames_multicopter/holybro_x500v2_pixhawk6c.md).
But the controller is somewhat robust, so it could work directly on other platforms, but performing system identification and training a new network is recommended.
Since the Aerial Gym Simulator is open-source you can download it and train your own networks as long as you have access to an NVIDIA GPU.
If you want to train a control network optimized for your platform you can follow the instructions in the [Aerial Gym Documentation](https://ntnu-arl.github.io/aerial_gym_simulator/9_sim2real/).
You should do one system identification flight for this and get an approximate inertia matrix for your platform.
On the `sys-id` flight you need ESC telemetry, you can read more about that in [DSHOT](../peripherals/dshot.md).
Then do the following steps:
- Do a hover flight
- Read of the logs what RPM is required for the drone to hover.
- Use the weight of each motor, length of the motor arms, total weight of the platform with battery to calculate an approximate inertia matrix for the platform.
- Insert these values into the Aerial Gym configuration and train your network.
- Convert the network as explained in [TFLM](tflm.md).
<Redirect to="../neural_networks/mc_neural_network_control" />
docs/en/can/index.md
+4
View File
@@ -10,6 +10,10 @@ CAN it is designed to be democratic and uses differential signaling.
For this reason it is very robust even over longer cable lengths (on large vehicles), and avoids a single point of failure.
CAN also allows status feedback from peripherals and convenient firmware upgrades over the bus.
PX4 has the ability to track and log detailed information from CAN devices, including firmware versions, hardware versions, and serial numbers.
This enables unique identification and lifecycle tracking of hardware connected to the flight controller.
See [Asset Tracking](../debug/asset_tracking.md) for more information.
PX4 supports two software protocols for communicating with CAN devices:
- [DroneCAN](../dronecan/index.md): PX4 recommends this for most common setups.
docs/en/config/safety.md
+7 -11
View File
@@ -121,21 +121,22 @@ PX4 and the receiver may also need to be configured in order to _detect RC loss_
![Safety - RC Loss (QGC)](../../assets/qgc/setup/safety/safety_rc_loss.png)
The QGCroundControl Safety UI allows you to set the [failsafe action](#failsafe-actions) and [RC Loss timeout](#COM_RC_LOSS_T).
Users that want to disable the RC loss failsafe in specific automatic modes (mission, hold, offboard) can do so using the parameter [COM_RCL_EXCEPT](#COM_RCL_EXCEPT).
The QGCroundControl Safety UI allows you to set the [failsafe action](#failsafe-actions) and [manual control loss timeout](#COM_RC_LOSS_T).
Users that want to disable this failsafe in specific modes can do so using the parameter [COM_RCL_EXCEPT](#COM_RCL_EXCEPT).
Additional (and underlying) parameter settings are shown below.
| Parameter | Setting | Description |
| ----------------------------------------------------------------------------------------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <a id="COM_RC_LOSS_T"></a>[COM_RC_LOSS_T](../advanced_config/parameter_reference.md#COM_RC_LOSS_T) | Manual Control Loss Timeout | Time after last setpoint received from the selected manual control source after which manual control is considered lost. This must be kept short because the vehicle will continue to fly using the old manual control setpoint until the timeout triggers. |
| <a id="COM_RC_LOSS_T"></a>[COM_RC_LOSS_T](../advanced_config/parameter_reference.md#COM_RC_LOSS_T) | Manual Control Loss Timeout | Time after last setpoint received from the selected manual control source after which manual control is considered lost. This must be kept short because the vehicle will continue to fly using the last known stick position until the timeout triggers. |
| <a id="COM_FAIL_ACT_T"></a>[COM_FAIL_ACT_T](../advanced_config/parameter_reference.md#COM_FAIL_ACT_T) | Failsafe Reaction Delay | Delay in seconds between failsafe condition being triggered (`COM_RC_LOSS_T`) and failsafe action (RTL, Land, Hold). In this state the vehicle waits in hold mode for the manual control source to reconnect. This might be set longer for long-range flights so that intermittent connection loss doesn't immediately invoke the failsafe. It can be to zero so that the failsafe triggers immediately. |
| <a id="NAV_RCL_ACT"></a>[NAV_RCL_ACT](../advanced_config/parameter_reference.md#NAV_RCL_ACT) | Failsafe Action | Disabled, Loiter, Return, Land, Disarm, Terminate. |
| <a id="COM_RCL_EXCEPT"></a>[COM_RCL_EXCEPT](../advanced_config/parameter_reference.md#COM_RCL_EXCEPT) | RC Loss Exceptions | Set the modes in which manual control loss is ignored: Mission, Hold, Offboard. |
| <a id="COM_RCL_EXCEPT"></a>[COM_RCL_EXCEPT](../advanced_config/parameter_reference.md#COM_RCL_EXCEPT) | RC Loss Exceptions | Set modes in which manual control loss is ignored. |
## Data Link Loss Failsafe
The Data Link Loss failsafe is triggered if a telemetry link (connection to ground station) is lost.
The Data Link Loss failsafe is triggered if the connection to the last MAVLink ground station like QGroundControl is lost.
Users that want to disable this failsafe in specific modes can do so using the parameter [COM_DLL_EXCEPT](#COM_DLL_EXCEPT).
![Safety - Data Link Loss (QGC)](../../assets/qgc/setup/safety/safety_data_link_loss.png)
@@ -145,12 +146,7 @@ The settings and underlying parameters are shown below.
| ---------------------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| Data Link Loss Timeout | [COM_DL_LOSS_T](../advanced_config/parameter_reference.md#COM_DL_LOSS_T) | Amount of time after losing the data connection before the failsafe will trigger. |
| Failsafe Action | [NAV_DLL_ACT](../advanced_config/parameter_reference.md#NAV_DLL_ACT) | Disabled, Hold mode, Return mode, Land mode, Disarm, Terminate. |
The following settings also apply, but are not displayed in the QGC UI.
| Setting | Parameter | Description |
| ----------------------------------------------------------- | -------------------------------------------------------------------------- | ---------------------------------------------------- |
| <a id="COM_DLL_EXCEPT"></a>Mode exceptions for DLL failsafe | [COM_DLL_EXCEPT](../advanced_config/parameter_reference.md#COM_DLL_EXCEPT) | Set modes where DL loss will not trigger a failsafe. |
| <a id="COM_DLL_EXCEPT"></a>Mode exceptions for DLL failsafe | [COM_DLL_EXCEPT](../advanced_config/parameter_reference.md#COM_DLL_EXCEPT) | Set modes in which data link loss is ignored. |
## Geofence Failsafe
docs/en/debug/asset_tracking.md
+68
View File
@@ -0,0 +1,68 @@
# Asset Tracking
<Badge type="tip" text="main (planned for: PX4 v1.18)" />
PX4 can track and log detailed information about external hardware devices connected to the flight controller.
This enables unique identification of vehicle parts throughout their operational lifetime using device IDs, serial numbers, and version information.
::: info
Asset tracking is currently implemented for [DroneCAN](../dronecan/index.md) devices only.
:::
## Overview
Asset tracking allows you to determine exactly which hardware is installed on a vehicle, providing serial number, version, and other information.
This makes it easier to track and maintain specific vehicle parts across multiple vehicles, to quickly see what versions you're running when debugging, and log component information for regulatory audits.
Asset tracking automatically collects and logs the following metadata from external devices:
- **Device identification**: Vendor name, model name, device type
- **Version information**: Firmware version, hardware version
- **Unique identifiers**: Serial number, device ID
- **Device capabilities**: ESC, GPS, magnetometer, barometer, etc.
This information is published via the [`device_information`](../msg_docs/DeviceInformation.md) uORB topic and logged to flight logs.
This enables fleet management, maintenance tracking, and troubleshooting.
## Viewing Device Information
### Real-Time Monitoring
You can view device information in real-time using the [MAVLink Shell](../debug/mavlink_shell.md) or console:
```sh
listener device_information
```
Example output for a CAN GPS module:
```plain
TOPIC: device_information
device_information
timestamp: 16258961403 (0.216525 seconds ago)
device_id: 8944643 (Type: 0x88, UAVCAN:0 (0x7C))
device_type: 5
vendor_name: "cubepilot"
model_name: "here4"
firmware_version: "1.14.3006590"
hardware_version: "4.19"
serial_number: "1c00410018513331"
```
Device information is published in a round-robin fashion for each detected device, at a rate of approximately 1 Hz.
### Multi-Capability Devices
Devices with multiple sensors (e.g., a CAN GPS/magnetometer combo module like the HERE4) register separate device information entries for each capability.
Each entry shares the same serial number and base metadata but has a different `device_id` corresponding to the specific sensor capability.
## Flight Log Analysis
Device information is automatically logged to flight logs.
You can extract it using [pyulog](../log/flight_log_analysis.md#pyulog), though note that fields like vendor name, model name, and serial number are stored as `char` arrays and require additional parsing.
## See Also
- [CAN (DroneCAN & Cyphal)](../can/index.md) — CAN bus configuration and setup
- [DroneCAN](../dronecan/index.md) — DroneCAN-specific documentation
- [Flight Log Analysis](../log/flight_log_analysis.md) — Flight log analysis
docs/en/dronecan/ark_g5_rtk_gps.md
+112
View File
@@ -0,0 +1,112 @@
# ARK G5 RTK GPS
::: info
This GPS module is made in the USA and NDAA compliant.
:::
[ARK G5 RTK GPS](https://arkelectron.com/product/ark-g5-rtk-gps/) is a [DroneCAN](index.md) quad-band [RTK GPS](../gps_compass/rtk_gps.md).
The module incorporates the [Septentrio mosaic-G5 P3 Ultra-compact high-precision GPS/GNSS receiver module](https://www.u-blox.com/en/product/zed-x20p-module), magnetometer, barometer, IMU, and buzzer module.
![ARK G5 RTK GPS](../../assets/hardware/gps/ark/ark_g5_rtk_gps.png)
## Where to Buy
Order this module from:
- [ARK Electronics](https://arkelectron.com/product/ark-g5-rtk-gps/) (US)
## Hardware Specifications
- [DroneCAN](index.md) RTK GNSS, Magnetometer, Barometer, IMU, and Buzzer Module
- [Dronecan Firmware Updating](../dronecan/index.md#firmware-update)
- Sensors
- [Septentrio mosaic-G5 P3 Ultra-compact high-precision GPS/GNSS receiver module](https://www.septentrio.com/en/products/gnss-receivers/gnss-receiver-modules/mosaic-G5-P3)
- All-band all constellation GNSS receiver
- All-in-view satellite tracking: multi-constellation, quad-band GNSS module receiver
- Full raw data with positioning measurements and Galileo HAS positioning service compatibility
- Best-in-class RTK cm-level positioning accuracy
- Advanced GNSS+ algorithms
- 20Hz update rate
- [ST IIS2MDC Magnetometer](https://www.st.com/en/mems-and-sensors/iis2mdc.html)
- [Bosch BMP390 Barometer](https://www.bosch-sensortec.com/products/environmental-sensors/pressure-sensors/bmp390/)
- [Invensense ICM-42688-P 6-Axis IMU](https://invensense.tdk.com/products/motion-tracking/6-axis/icm-42688-p/)
- STM32F412VGH6 MCU
- Safety Button
- Buzzer
- Two CAN Connectors (Pixhawk Connector Standard 4-pin JST GH)
- G5 "UART 2" Connector
- 4-pin JST GH
- TX, RX, PPS, GND
- G5 USB C
- Debug Connector (Pixhawk Connector Standard 6-pin JST SH)
- LED Indicators
- GPS Fix
- RTK Status
- RGB system status
- USA Built
- NDAA Compliant
- Power Requirements
- 5V
- 270mA
- Dimensions
- Without Antenna
- 48.0mm x 40.0mm x 15.4mm
- 13.0g
- With Antenna
- 48.0mm x 40.0mm x 51.0mm
- 43.5g
- Includes
- CAN Cable (Pixhawk Connector Standard 4-pin)
- Full-Frequency Helical GPS Antenna
## Hardware Setup
### Wiring
The ARK G5 RTK GPS is connected to the CAN bus using a [Pixhawk connector standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-009%20Pixhawk%20Connector%20Standard.pdf) 4-pin JST GH cable.
For more information, refer to the [CAN Wiring](../can/index.md#wiring) instructions.
### Mounting
The recommended mounting orientation is with the connectors on the board pointing towards the **back of vehicle**.
The sensor can be mounted anywhere on the frame, but you will need to specify its position, relative to vehicle centre of gravity, during [PX4 Configuration](#px4-configuration).
## Firmware Setup
The Septentrio G5 module firmware can be updated using the Septentrio [RxTools](https://www.septentrio.com/en/products/gps-gnss-receiver-software/rxtools) application.
## Flight Controller Setup
### Enabling DroneCAN
In order to use the ARK G5 RTK GPS, connect it to the Pixhawk CAN bus and enable the DroneCAN driver by setting parameter [UAVCAN_ENABLE](../advanced_config/parameter_reference.md#UAVCAN_ENABLE) to `2` for dynamic node allocation (or `3` if using [DroneCAN ESCs](../dronecan/escs.md)).
The steps are:
- In _QGroundControl_ set the parameter [UAVCAN_ENABLE](../advanced_config/parameter_reference.md#UAVCAN_ENABLE) to `2` or `3` and reboot (see [Finding/Updating Parameters](../advanced_config/parameters.md)).
- Connect ARK G5 RTK GPS CAN to the Pixhawk CAN.
Once enabled, the module will be detected on boot.
There is also CAN built-in bus termination via [CANNODE_TERM](../advanced_config/parameter_reference.md#CANNODE_TERM)
### PX4 Configuration
You need to set necessary [DroneCAN](index.md) parameters and define offsets if the sensor is not centred within the vehicle:
- Enable [UAVCAN_SUB_GPS](../advanced_config/parameter_reference.md#UAVCAN_SUB_GPS), [UAVCAN_SUB_MAG](../advanced_config/parameter_reference.md#UAVCAN_SUB_MAG), and [UAVCAN_SUB_BARO](../advanced_config/parameter_reference.md#UAVCAN_SUB_BARO).
- The parameters [EKF2_GPS_POS_X](../advanced_config/parameter_reference.md#EKF2_GPS_POS_X), [EKF2_GPS_POS_Y](../advanced_config/parameter_reference.md#EKF2_GPS_POS_Y) and [EKF2_GPS_POS_Z](../advanced_config/parameter_reference.md#EKF2_GPS_POS_Z) can be set to account for the offset of the ARK G5 RTK GPS from the vehicle's centre of gravity.
## LED Meanings
The GPS status lights are located to the right of the connectors:
- Blinking green is GPS fix
- Blinking blue is received corrections and RTK Float
- Solid blue is RTK Fixed
## See Also
- [ARK G5 RTK GPS Documentation](https://docs.arkelectron.com/gps/ark-g5-rtk-gps) (ARK Docs)
docs/en/dronecan/ark_g5_rtk_heading_gps.md
+150
View File
@@ -0,0 +1,150 @@
# ARK G5 RTK HEADING GPS
::: info
This GPS module is made in the USA and NDAA compliant.
:::
[ARK G5 RTK HEADING GPS](https://arkelectron.com/product/ark-g5-rtk-gps/) is a [DroneCAN](index.md) quad-band dual antenna [RTK GPS](../gps_compass/rtk_gps.md) that additionally provides vehicle yaw information from GPS.
The module incorporates the [Septentrio mosaic-G5 P3H Ultra-compact high-precision GPS/GNSS receiver module with heading capability](https://www.septentrio.com/en/products/gnss-receivers/gnss-receiver-modules/mosaic-G5-P3H), magnetometer, barometer, IMU, and buzzer module.
![ARK G5 RTK HEADING GPS](../../assets/hardware/gps/ark/ark_g5_rtk_gps.png)
## Where to Buy
Order this module from:
- [ARK Electronics](https://arkelectron.com/product/ark-g5-rtk-heading-gps/) (US)
## Hardware Specifications
- [DroneCAN](index.md) RTK GNSS, Magnetometer, Barometer, IMU, and Buzzer Module
- [Dronecan Firmware Updating](../dronecan/index.md#firmware-update)
- Sensors
- [Septentrio mosaic-G5 P3H Ultra-compact high-precision GPS/GNSS receiver module with heading capability](https://www.septentrio.com/en/products/gnss-receivers/gnss-receiver-modules/mosaic-G5-P3H)
- All-band all constellation GNSS receiver
- All-in-view satellite tracking: multi-constellation, quad-band GNSS module receiver
- Full raw data with positioning measurements and Galileo HAS positioning service compatibility
- Best-in-class RTK cm-level positioning accuracy
- Advanced GNSS+ algorithms
- 20Hz update rate
- [ST IIS2MDC Magnetometer](https://www.st.com/en/mems-and-sensors/iis2mdc.html)
- [Bosch BMP390 Barometer](https://www.bosch-sensortec.com/products/environmental-sensors/pressure-sensors/bmp390/)
- [Invensense ICM-42688-P 6-Axis IMU](https://invensense.tdk.com/products/motion-tracking/6-axis/icm-42688-p/)
- STM32F412VGH6 MCU
- Safety Button
- Buzzer
- Two CAN Connectors (Pixhawk Connector Standard 4-pin JST GH)
- G5 "UART 2" Connector
- 4-pin JST GH
- TX, RX, PPS, GND
- G5 USB C
- Debug Connector (Pixhawk Connector Standard 6-pin JST SH)
- LED Indicators
- GPS Fix
- RTK Status
- RGB system status
- USA Built
- NDAA Compliant
- Power Requirements
- 5V
- 270mA
- Dimensions
- Without Antenna
- 48.0mm x 40.0mm x 15.4mm
- 13.0g
- With Antenna
- 48.0mm x 40.0mm x 51.0mm
- 43.5g
- Includes
- CAN Cable (Pixhawk Connector Standard 4-pin)
- Full-Frequency Helical GPS Antenna
## Hardware Setup
### Wiring
The ARK G5 RTK HEADING GPS is connected to the CAN bus using a [Pixhawk connector standard](https://github.com/pixhawk/Pixhawk-Standards/blob/master/DS-009%20Pixhawk%20Connector%20Standard.pdf) 4-pin JST GH cable.
For more information, refer to the [CAN Wiring](../can/index.md#wiring) instructions.
### Mounting
The recommended mounting orientation is with the connectors on the board pointing towards the **back of vehicle**.
The sensor can be mounted anywhere on the frame, but you will need to specify its position, relative to vehicle centre of gravity, during [PX4 configuration](#px4-configuration).
## Firmware Setup
The Septentrio G5 module firmware can be updated using the Septentrio [RxTools](https://www.septentrio.com/en/products/gps-gnss-receiver-software/rxtools) application.
## Flight Controller Setup
### Enabling DroneCAN
In order to use the ARK G5 RTK HEADING GPS, connect it to the Pixhawk CAN bus and enable the DroneCAN driver by setting parameter [UAVCAN_ENABLE](../advanced_config/parameter_reference.md#UAVCAN_ENABLE) to `2` for dynamic node allocation (or `3` if using [DroneCAN ESCs](../dronecan/escs.md)).
The steps are:
- In _QGroundControl_ set the parameter [UAVCAN_ENABLE](../advanced_config/parameter_reference.md#UAVCAN_ENABLE) to `2` or `3` and reboot (see [Finding/Updating Parameters](../advanced_config/parameters.md)).
- Connect ARK G5 RTK HEADING GPS CAN to the Pixhawk CAN.
Once enabled, the module will be detected on boot.
There is also CAN built-in bus termination via [CANNODE_TERM](../advanced_config/parameter_reference.md#CANNODE_TERM)
### PX4 Configuration
You need to set necessary [DroneCAN](index.md) parameters and define offsets if the sensor is not centred within the vehicle:
- Enable GPS yaw fusion by setting bit 3 of [EKF2_GPS_CTRL](../advanced_config/parameter_reference.md#EKF2_GPS_CTRL) to true.
- Enable GPS blending to ensure the heading is always published by setting [SENS_GPS_MASK](../advanced_config/parameter_reference.md#SENS_GPS_MASK) to 7 (all three bits checked).
- Enable [UAVCAN_SUB_GPS](../advanced_config/parameter_reference.md#UAVCAN_SUB_GPS), [UAVCAN_SUB_MAG](../advanced_config/parameter_reference.md#UAVCAN_SUB_MAG), and [UAVCAN_SUB_BARO](../advanced_config/parameter_reference.md#UAVCAN_SUB_BARO).
- The parameters [EKF2_GPS_POS_X](../advanced_config/parameter_reference.md#EKF2_GPS_POS_X), [EKF2_GPS_POS_Y](../advanced_config/parameter_reference.md#EKF2_GPS_POS_Y) and [EKF2_GPS_POS_Z](../advanced_config/parameter_reference.md#EKF2_GPS_POS_Z) can be set to account for the offset of the ARK G5 RTK HEADING GPS from the vehicle's centre of gravity.
### Parameter references
This GPS is using ARK's private driver, the prameters below only exist on the firmware we ship the GPS with. You can set these params either in QGC or using the DroneCAN GUI Tool.
#### SEP_OFFS_YAW (float)
Heading offset angle for dual antenna GPS setups that support heading estimation.
Set this to 0 if the antennas are parallel to the forward-facing direction of the vehicle and the Rover/ANT2 antenna is in front.
The offset angle increases clockwise.
Set this to 90 if the ANT2 antenna is placed on the right side of the vehicle and the Moving Base/MAIN antenna is on the left side.
- Default: 0
- Min: -360
- Max: 360
- Unit: degree
#### SEP_OFFS_PITCH (float)
Vertical offsets can be compensated for by adjusting the Pitch offset.
Note that this can be interpreted as the "roll" angle in case the antennas are aligned along the perpendicular axis. This occurs in situations where the two antenna ARPs may not be exactly at the same height in the vehicle reference frame. Since pitch is defined as the right-handed rotation about the vehicle Y axis, a situation where the main antenna is mounted lower than the aux antenna (assuming the default antenna setup) will result in a positive pitch.
- Default: 0
- Min: -90
- Max: 90
- Unit: degree
#### SEP_OUT_RATE (enum)
Configures the output rate for GNSS data messages.
- -1: OnChange (Default)
- 50: 50 ms
- 100: 100 ms
- 200: 200 ms
- 500: 500 ms
## LED Meanings
The GPS status lights are located to the right of the connectors:
- Blinking green is GPS fix
- Blinking blue is received corrections and RTK Float
- Solid blue is RTK Fixed
## See Also
- [ARK G5 RTK HEADING GPS Documentation](https://docs.arkelectron.com/gps/ark-g5-rtk-gps) (ARK Docs)
docs/en/dronecan/index.md
+2
View File
@@ -27,6 +27,8 @@ Connecting peripherals over DroneCAN has many benefits:
- Wiring is less complicated as you can have a single bus for connecting all your ESCs and other DroneCAN peripherals.
- Setup is easier as you configure ESC numbering by manually spinning each motor.
- It allows users to configure and update the firmware of all CAN-connected devices centrally through PX4.
- PX4 automatically tracks device information (vendor, model, versions, serial numbers) for maintenance and fleet management.
See [Asset Tracking](../debug/asset_tracking.md).
## Supported Hardware
docs/en/features_fw/gain_compression.md
+1 -1
View File
@@ -1,6 +1,6 @@
# Gain compression
<Badge type="tip" text="main (planned for: PX4 v1.17)" />
<Badge type="tip" text="PX4 v1.17" />
Automatic gain compression reduces the gains of the angular-rate PID whenever oscillations are detected.
It monitors the angular-rate controller output through a band-pass filter to identify these oscillations.
docs/en/flight_controller/micoair743-lite.md
+1 -1
View File
@@ -1,6 +1,6 @@
# MicoAir743-Lite
<Badge type="tip" text="main (planned for: PX4 v1.17)" />
<Badge type="tip" text="PX4 v1.17" />
:::warning
PX4 does not manufacture this (or any) autopilot.
docs/en/flight_controller/radiolink_pix6.md
+1 -1
View File
@@ -1,6 +1,6 @@
# RadiolinkPIX6 Flight Controller
<Badge type="tip" text="main (planned for: PX4 v1.17)" />
<Badge type="tip" text="PX4 v1.17" />
:::warning
PX4 does not manufacture this (or any) autopilot.
docs/en/flight_controller/x-mav_ap-h743r1.md
+18 -16
View File
@@ -1,6 +1,6 @@
# AP-H743-R1
# AP-H743-R1 Flight Controller
<Badge type="tip" text="main (planned for: PX4 v1.17)" />
<Badge type="tip" text="PX4 v1.17" />
:::warning
PX4 does not manufacture this (or any) autopilot.
@@ -50,6 +50,7 @@ These flight controllers are [manufacturer supported](../flight_controller/autop
Order from [X-MAV](https://www.x-mav.cn/).
## Radio Control
A Radio Control (RC) system is required if you want to manually control your vehicle (PX4 does not require a radio system for autonomous flight modes).
You will need to select a compatible transmitter/receiver and then bind them so that they communicate (read the instructions that come with your specific transmitter/receiver).
@@ -59,14 +60,14 @@ CRSF receiver must be wired to a spare port (UART) on the Flight Controller. The
## Serial Port Mapping
| UART | Device | Port |
| ------ | ---------- | ------------- |
| USART1 | /dev/ttyS0 | GPS |
| USART2 | /dev/ttyS1 | GPS2 |
| USART3 | /dev/ttyS2 | TELEM1 |
| UART4 | /dev/ttyS3 | TELEM2 |
| UART7 | /dev/ttyS4 | TELEM3 |
| UART8 | /dev/ttyS5 | SERIAL4 |
| UART | Device | Port |
| ------ | ---------- | ------- |
| USART1 | /dev/ttyS0 | GPS |
| USART2 | /dev/ttyS1 | GPS2 |
| USART3 | /dev/ttyS2 | TELEM1 |
| UART4 | /dev/ttyS3 | TELEM2 |
| UART7 | /dev/ttyS4 | TELEM3 |
| UART8 | /dev/ttyS5 | SERIAL4 |
## PWM Output
@@ -133,13 +134,14 @@ The complete set of supported configurations can be found in the [Airframe Refer
## Debug Port
### SWD
The [SWD interface](../debug/swd_debug.md) operate on the **FMU-DEBUG** port (`FMU-DEBUG`).
The debug port (`FMU-DEBUG`) uses a [JST SM04B-GHS-TB](https://www.digikey.com/en/products/detail/jst-sales-america-inc/SM04B-GHS-TB/807788) connector and has the following pinout:
| Pin | Signal | Volt |
| ------- | -------------- | ----- |
| 1 (red) | 5V+ | +5V |
| 2 (blk) | FMU_SWDIO | +3.3V |
| 3 (blk) | FMU_SWCLK | +3.3V |
| 4 (blk) | GND | GND |
| Pin | Signal | Volt |
| ------- | --------- | ----- |
| 1 (red) | 5V+ | +5V |
| 2 (blk) | FMU_SWDIO | +3.3V |
| 3 (blk) | FMU_SWCLK | +3.3V |
| 4 (blk) | GND | GND |
docs/en/flight_modes_fw/hold.md
+68 -9
View File
@@ -2,11 +2,14 @@
<img src="../../assets/site/position_fixed.svg" title="Position fix required (e.g. GPS)" width="30px" />
The _Hold_ flight mode causes the vehicle to loiter (circle) around its current GPS position and maintain its current altitude.
The _Hold_ flight mode causes the vehicle to loiter around its current GPS position and maintain its current altitude.
The mode supports a [number of distinct loiter modes](#loiter-modes), which are triggered using different QGC controls or MAVLink commands.
These allow loitering with circular and figure 8 flight paths.
:::tip
_Hold mode_ can be used to pause a mission or to help you regain control of a vehicle in an emergency.
It is usually activated with a pre-programmed switch.
It is usually activated with a pre-programmed RC switch.
:::
::: info
@@ -24,24 +27,80 @@ It is usually activated with a pre-programmed switch.
:::
## Technical Summary
## Loiter modes
The aircraft circles around the GPS hold position at the current altitude.
The vehicle will first ascend to [NAV_MIN_LTR_ALT](#NAV_MIN_LTR_ALT) if the mode is engaged below this altitude.
### Default Loiter
RC stick movement is ignored.
The aircraft circles around the position at which the mode was triggered and maintain its current altitude.
The loiter radius is set by the parameter [NAV_LOITER_RAD](#NAV_LOITER_RAD).
Note that if the vehicle altitude is below [NAV_MIN_LTR_ALT](#NAV_MIN_LTR_ALT), it will ascend to that minimum altitude before circling.
### Parameters
The default loiter mode is entered when you switch to Hold mode without explicitly specifying any loiter behaviour.
For example, if you switch to Hold mode using an RC switch, select **Hold** on the QGC flight mode selector, or activate the mode using the MAVLink [MAV_CMD_DO_SET_MODE](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_SET_MODE) command.
### Orbit Loiter Mode
<Badge type="tip" text="PX4 v1.12" />
The aircraft travels towards a _specified_ orbit center position, then circles it with a given direction and radius.
This behaviour can be accessed in QGroundControl by clicking on the map in Fly view, selecting **Orbit at Location**, and configuring the radius.
The behavior can be triggered using the MAVLink [MAV_CMD_DO_ORBIT](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_ORBIT) command.
Note that PX4 respects the specified centre point (`param5`, `param6`, `param7`), and the radius and direction (`param1`).
PX4 ignores `param3` (Yaw behaviour) and `param4` (Orbits).
The value of `param2` (velocity) is also ignored, but the speed can be controlled using the [MAV_CMD_DO_CHANGE_SPEED](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_CHANGE_SPEED) command (constrained between `FW_AIRSPD_MAX` and `FW_AIRSPD_MIN`).
PX4 outputs orbit status using the [ORBIT_EXECUTION_STATUS](https://mavlink.io/en/messages/common.html#ORBIT_EXECUTION_STATUS) message.
### Figure 8 Loiter Mode
<Badge type="tip" text="PX4 v1.15" /> <Badge type="warning" text="Experimental" />
The aircraft flys towards the closest point on a specified figure 8 path and then follows it.
The path is defined by the figure 8 centre position, orientation, and radius of two circles.
The feature is experimental, and is not present in PX4 firmware by default (on most flight controller boards).
It can be included by setting the `CONFIG_FIGURE_OF_EIGHT` key in the [PX4 board configuration](../hardware/porting_guide_config.md#px4-board-configuration-kconfig) for your board and rebuilding.
For example, this is enabled on the [default.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/auterion/fmu-v6s/default.px4board#L46) file for the `auterion/fmu-v6s` board.
The behavior can be triggered using the MAVLink [MAV_CMD_DO_FIGURE_EIGHT](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_FIGURE_EIGHT) command (PX4 respects all the parameters).
PX4 outputs the figure 8 status using the [FIGURE_EIGHT_EXECUTION_STATUS](https://mavlink.io/en/messages/common.html#FIGURE_EIGHT_EXECUTION_STATUS) message.
::: info
Figure 8 loitering is not currently supported by QGC: [QGC#12778: Need Support Figure of eight (8 figure) loitering by QGC](https://github.com/mavlink/qgroundcontrol/issues/12778).
:::
Figure 8 loitering is also available in the simulator.
You can test it in [Gazebo](../sim_gazebo_gz/index.md) using a fixed wing frame:
```sh
make px4_sitl gz_rc_cessna
```
## Parameters
Hold mode behaviour can be configured using the parameters below.
| Parameter | Description |
| -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| [NAV_LOITER_RAD](../advanced_config/parameter_reference.md#NAV_LOITER_RAD) | The radius of the loiter circle. |
| <a id="NAV_LOITER_RAD"></a>[NAV_LOITER_RAD](../advanced_config/parameter_reference.md#NAV_LOITER_RAD) | The radius of the loiter circle. |
| <a id="NAV_MIN_LTR_ALT"></a>[NAV_MIN_LTR_ALT](../advanced_config/parameter_reference.md#NAV_MIN_LTR_ALT) | Minimum height for loiter mode (vehicle will ascend to this altitude if mode is engaged at a lower altitude). |
## MAVLink Commands
The following commands are relevant to this mode:
- [MAV_CMD_DO_ORBIT](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_ORBIT) - Switch to Hold mode and start the specified [Orbit loiter](#orbit-loiter-mode).
Params 2 (velocity), 3 (yaw), 4 (orbits) are ignored.
[ORBIT_EXECUTION_STATUS](https://mavlink.io/en/messages/common.html#ORBIT_EXECUTION_STATUS) is emitted.
- [MAV_CMD_DO_FIGURE_EIGHT](https://mavlink.io/en/messages/common.html#MAV_CMD_DO_FIGURE_EIGHT) - Switch to Hold mode and start the specified [Figure 8 loiter](#figure-8-loiter-mode).
All params are respected.
[FIGURE_EIGHT_EXECUTION_STATUS](https://mavlink.io/en/messages/common.html#FIGURE_EIGHT_EXECUTION_STATUS) is emitted.
Note, other commands may be supported.
## See Also
[Hold Mode (MC)](../flight_modes_mc/hold.md)
- [Hold Mode (MC)](../flight_modes_mc/hold.md)
<!-- this maps to AUTO_LOITER in flight mode state machine -->
docs/en/flight_modes_fw/takeoff.md
+2 -2
View File
@@ -49,8 +49,8 @@ If the local position is invalid or becomes invalid while executing the takeoff,
::: info
- Takeoff towards a target position was added in <Badge type="tip" text="main (planned for: PX4 v1.17)" />.
- Holding wings level and ascending to clearance attitude when local position is invalid during takeoff was added in <Badge type="tip" text="main (planned for: PX4 v1.17)" />.
- Takeoff towards a target position was added in <Badge type="tip" text="PX4 v1.17" />.
- Holding wings level and ascending to clearance attitude when local position is invalid during takeoff was added in <Badge type="tip" text="PX4 v1.17" />.
- QGroundControl does not support `MAV_CMD_NAV_TAKEOFF` (at time of writing).
:::
docs/en/gps_compass/rtk_gps.md
+48 -40
View File
@@ -20,52 +20,59 @@ The RTK compatible devices below that are expected to work with PX4 (it omits di
The table indicates devices that also output yaw, and that can provide yaw when two on-vehicle units are used.
It also highlights devices that connect via the CAN bus, and those which support PPK (Post-Processing Kinematic).
| Device | GPS | Compass | [DroneCAN](../dronecan/index.md) | [GPS Yaw](#configuring-gps-as-yaw-heading-source) | PPK |
| :-------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------: | :------: | :------------------------------: | :-----------------------------------------------: | :-: |
| [ARK RTK GPS](../dronecan/ark_rtk_gps.md) | F9P | BMM150 | ✓ | [Dual F9P][DualF9P] |
| [ARK RTK GPS L1 L5](../dronecan/ark_rtk_gps_l1_l2.md) | F9P | BMM150 | ✓ | |
| [ARK MOSAIC-X5 RTK GPS](../dronecan/ark_mosaic__rtk_gps.md) | Mosaic-X5 | IIS2MDC | ✓ | [Septentrio Dual Antenna][SeptDualAnt] |
| [ARK X20 RTK GPS](../dronecan/ark_x20_rtk_gps.md) | X20P | BMP390 | ✓ | |
| [CUAV C-RTK GPS](../gps_compass/rtk_gps_cuav_c-rtk.md) | M8P/M8N | ✓ | | |
| [CUAV C-RTK2](../gps_compass/rtk_gps_cuav_c-rtk2.md) | F9P | ✓ | | [Dual F9P][DualF9P] |
| [CUAV C-RTK 9Ps GPS](../gps_compass/rtk_gps_cuav_c-rtk-9ps.md) | F9P | RM3100 | | [Dual F9P][DualF9P] |
| [CUAV C-RTK2 PPK/RTK GNSS](../gps_compass/rtk_gps_cuav_c-rtk.md) | F9P | RM3100 | | | ✓ |
| [CubePilot Here+ RTK GPS](../gps_compass/rtk_gps_hex_hereplus.md) | M8P | HMC5983 | | |
| [CubePilot Here3 CAN GNSS GPS (M8N)](https://www.cubepilot.org/#/here/here3) | M8P | ICM20948 | ✓ | |
| [Drotek SIRIUS RTK GNSS ROVER (F9P)](https://store-drotek.com/911-sirius-rtk-gnss-rover-f9p.html) | F9P | RM3100 | | [Dual F9P][DualF9P] |
| [DATAGNSS NANO HRTK Receiver](../gps_compass/rtk_gps_datagnss_nano_hrtk.md) | [D10P](https://docs.datagnss.com/gnss/gnss_module/D10P_RTK) | IST8310 | | ✘ |
| [DATAGNSS GEM1305 RTK Receiver](../gps_compass/rtk_gps_gem1305.md) | TAU951M | IST8310 | | ✘ |
| [Femtones MINI2 Receiver](../gps_compass/rtk_gps_fem_mini2.md) | FB672, FB6A0 | ✓ | | |
| [Freefly RTK GPS](../gps_compass/rtk_gps_freefly.md) | F9P | IST8310 | | |
| [Holybro H-RTK ZED-F9P RTK Rover (DroneCAN variant)](../dronecan/holybro_h_rtk_zed_f9p_gps.md) | F9P | RM3100 | ✓ | [Dual F9P][DualF9P] |
| [Holybro H-RTK ZED-F9P RTK Rover](https://holybro.com/collections/h-rtk-gps/products/h-rtk-zed-f9p-rover) | F9P | RM3100 | | [Dual F9P][DualF9P] |
| [Holybro H-RTK F9P Ultralight](https://holybro.com/products/h-rtk-f9p-ultralight) | F9P | IST8310 | | [Dual F9P][DualF9P] |
| [Holybro H-RTK F9P Helical or Base](../gps_compass/rtk_gps_holybro_h-rtk-f9p.md) | F9P | IST8310 | | [Dual F9P][DualF9P] |
| [Holybro DroneCAN H-RTK F9P Helical](https://holybro.com/products/dronecan-h-rtk-f9p-helical) | F9P | BMM150 | ✓ | [Dual F9P][DualF9P] |
| [Holybro H-RTK F9P Rover Lite](../gps_compass/rtk_gps_holybro_h-rtk-f9p.md) | F9P | IST8310 | | | |
| [Holybro DroneCAN H-RTK F9P Rover](https://holybro.com/products/dronecan-h-rtk-f9p-rover) | F9P | BMM150 | | [Dual F9P][DualF9P] |
| [Holybro H-RTK M8P GNSS](../gps_compass/rtk_gps_holybro_h-rtk-m8p.md) | M8P | IST8310 | |
| [Holybro H-RTK Unicore UM982 GPS](../gps_compass/rtk_gps_holybro_unicore_um982.md) | UM982 | IST8310 | | [Unicore Dual Antenna][UnicoreDualAnt] |
| [LOCOSYS Hawk R1](../gps_compass/rtk_gps_locosys_r1.md) | MC-1612-V2b | | | |
| [LOCOSYS Hawk R2](../gps_compass/rtk_gps_locosys_r2.md) | MC-1612-V2b | IST8310 | | |
| [mRo u-blox ZED-F9 RTK L1/L2 GPS](https://store.mrobotics.io/product-p/m10020d.htm) | F9P | ✓ | | [Dual F9P][DualF9P] |
| [Navisys L1/L2 ZED-F9P RTK - Base only](https://www.navisys.com.tw/productdetail?name=GR901&class=RTK) | F9P | | | |
| [RaccoonLab L1/L2 ZED-F9P][RaccoonLab L1/L2 ZED-F9P] | F9P | RM3100 | ✓ | | |
| [RaccoonLab L1/L2 ZED-F9P with external antenna][RaccnLabL1L2ZED-F9P ext_ant] | F9P | RM3100 | ✓ | |
| [Septentrio AsteRx-m3 Pro](../gps_compass/septentrio_asterx-rib.md) | AsteRx | ✓ | | [Septentrio Dual Antenna][SeptDualAnt] | ✓ |
| [Septentrio mosaic-go](../gps_compass/septentrio_mosaic-go.md) | mosaic X5 / mosaic H | ✓ | | [Septentrio Dual Antenna][SeptDualAnt] | ✓ |
| [SIRIUS RTK GNSS ROVER (F9P)](https://store-drotek.com/911-sirius-rtk-gnss-rover-f9p.html) | F9P | ✓ | | [Dual F9P][DualF9P] |
| [SparkFun GPS-RTK2 Board - ZED-F9P](https://www.sparkfun.com/products/15136) | F9P | ✓ | | [Dual F9P][DualF9P] |
| [Trimble MB-Two](../gps_compass/rtk_gps_trimble_mb_two.md) | F9P | ✓ | | ✓ | |
| Device | GPS | Compass | [DroneCAN] | [GPS Yaw] | PPK |
| :-------------------------------------------------------------------------------------------------------- | :------------------: | :------: | :--------: | :-----------------------: | :-: |
| [ARK G5 RTK GPS](../dronecan/ark_g5_rtk_gps.md) | [mosaic-G5 P3] | IIS2MDC | ✓ | | |
| [ARK G5 RTK HEADING GPS](../dronecan/ark_g5_rtk_heading_gps.md) | [mosaic-G5 P3H] | IIS2MDC | ✓ | [Heading Capability][mosaic-G5 P3H] | |
| [ARK RTK GPS](../dronecan/ark_rtk_gps.md) | F9P | BMM150 | ✓ | [Dual F9P] | |
| [ARK RTK GPS L1 L5](../dronecan/ark_rtk_gps_l1_l2.md) | F9P | BMM150 | ✓ | | |
| [ARK MOSAIC-X5 RTK GPS](../dronecan/ark_mosaic__rtk_gps.md) | Mosaic-X5 | IIS2MDC | ✓ | [Septentrio Dual Antenna] | |
| [ARK X20 RTK GPS](../dronecan/ark_x20_rtk_gps.md) | X20P | IIS2MDC | ✓ | | |
| [CUAV C-RTK GPS](../gps_compass/rtk_gps_cuav_c-rtk.md) | M8P/M8N | ✓ | | | |
| [CUAV C-RTK2](../gps_compass/rtk_gps_cuav_c-rtk2.md) | F9P | ✓ | | [Dual F9P] | |
| [CUAV C-RTK 9Ps GPS](../gps_compass/rtk_gps_cuav_c-rtk-9ps.md) | F9P | RM3100 | | [Dual F9P] | |
| [CUAV C-RTK2 PPK/RTK GNSS](../gps_compass/rtk_gps_cuav_c-rtk.md) | F9P | RM3100 | | | ✓ |
| [CubePilot Here+ RTK GPS](../gps_compass/rtk_gps_hex_hereplus.md) | M8P | HMC5983 | | | |
| [CubePilot Here3 CAN GNSS GPS (M8N)](https://www.cubepilot.org/#/here/here3) | M8P | ICM20948 | ✓ | | |
| [Drotek SIRIUS RTK GNSS ROVER (F9P)](https://store-drotek.com/911-sirius-rtk-gnss-rover-f9p.html) | F9P | RM3100 | | [Dual F9P] | |
| [DATAGNSS NANO HRTK Receiver](../gps_compass/rtk_gps_datagnss_nano_hrtk.md) | [D10P] | IST8310 | | ✘ | |
| [DATAGNSS GEM1305 RTK Receiver](../gps_compass/rtk_gps_gem1305.md) | TAU951M | IST8310 | | ✘ | |
| [Femtones MINI2 Receiver](../gps_compass/rtk_gps_fem_mini2.md) | FB672, FB6A0 | ✓ | | | |
| [Freefly RTK GPS](../gps_compass/rtk_gps_freefly.md) | F9P | IST8310 | | | |
| [Holybro H-RTK ZED-F9P RTK Rover (DroneCAN variant)](../dronecan/holybro_h_rtk_zed_f9p_gps.md) | F9P | RM3100 | ✓ | [Dual F9P] | |
| [Holybro H-RTK ZED-F9P RTK Rover](https://holybro.com/collections/h-rtk-gps/products/h-rtk-zed-f9p-rover) | F9P | RM3100 | | [Dual F9P] | |
| [Holybro H-RTK F9P Ultralight](https://holybro.com/products/h-rtk-f9p-ultralight) | F9P | IST8310 | | [Dual F9P] | |
| [Holybro H-RTK F9P Helical or Base](../gps_compass/rtk_gps_holybro_h-rtk-f9p.md) | F9P | IST8310 | | [Dual F9P] | |
| [Holybro DroneCAN H-RTK F9P Helical](https://holybro.com/products/dronecan-h-rtk-f9p-helical) | F9P | BMM150 | ✓ | [Dual F9P] | |
| [Holybro H-RTK F9P Rover Lite](../gps_compass/rtk_gps_holybro_h-rtk-f9p.md) | F9P | IST8310 | | | |
| [Holybro DroneCAN H-RTK F9P Rover](https://holybro.com/products/dronecan-h-rtk-f9p-rover) | F9P | BMM150 | | [Dual F9P] | |
| [Holybro H-RTK M8P GNSS](../gps_compass/rtk_gps_holybro_h-rtk-m8p.md) | M8P | IST8310 | | | |
| [Holybro H-RTK Unicore UM982 GPS](../gps_compass/rtk_gps_holybro_unicore_um982.md) | UM982 | IST8310 | | [Unicore Dual Antenna] | |
| [LOCOSYS Hawk R1](../gps_compass/rtk_gps_locosys_r1.md) | MC-1612-V2b | | | | |
| [LOCOSYS Hawk R2](../gps_compass/rtk_gps_locosys_r2.md) | MC-1612-V2b | IST8310 | | | |
| [mRo u-blox ZED-F9 RTK L1/L2 GPS](https://store.mrobotics.io/product-p/m10020d.htm) | F9P | ✓ | | [Dual F9P] | |
| [Navisys L1/L2 ZED-F9P RTK - Base only](https://www.navisys.com.tw/productdetail?name=GR901&class=RTK) | F9P | | | | |
| [RaccoonLab L1/L2 ZED-F9P][RaccoonLab L1/L2 ZED-F9P] | F9P | RM3100 | ✓ | | |
| [RaccoonLab L1/L2 ZED-F9P with external antenna][RaccnLabL1L2ZED-F9P ext_ant] | F9P | RM3100 | ✓ | | |
| [Septentrio AsteRx-m3 Pro](../gps_compass/septentrio_asterx-rib.md) | AsteRx | ✓ | | [Septentrio Dual Antenna] | ✓ |
| [Septentrio mosaic-go](../gps_compass/septentrio_mosaic-go.md) | mosaic X5 / mosaic H | ✓ | | [Septentrio Dual Antenna] | ✓ |
| [SIRIUS RTK GNSS ROVER (F9P)](https://store-drotek.com/911-sirius-rtk-gnss-rover-f9p.html) | F9P | ✓ | | [Dual F9P] | |
| [SparkFun GPS-RTK2 Board - ZED-F9P](https://www.sparkfun.com/products/15136) | F9P | ✓ | | [Dual F9P] | |
| [Trimble MB-Two](../gps_compass/rtk_gps_trimble_mb_two.md) | F9P | ✓ | | ✓ | |
<!-- links used in above table -->
[RaccnLabL1L2ZED-F9P ext_ant]: https://docs.raccoonlab.co/guide/gps_mag_baro/gnss_external_antenna_f9p_v320.html
[RaccoonLab L1/L2 ZED-F9P]: https://docs.raccoonlab.co/guide/gps_mag_baro/gps_l1_l2_zed_f9p.html
[DualF9P]: ../gps_compass/u-blox_f9p_heading.md
[SeptDualAnt]: ../gps_compass/septentrio.md#gnss-based-heading
[UnicoreDualAnt]: ../gps_compass/rtk_gps_holybro_unicore_um982.md#enable-gps-heading-yaw
[Dual F9P]: ../gps_compass/u-blox_f9p_heading.md
[Septentrio Dual Antenna]: ../gps_compass/septentrio.md#gnss-based-heading
[Unicore Dual Antenna]: ../gps_compass/rtk_gps_holybro_unicore_um982.md#enable-gps-heading-yaw
[DATAGNSS GEM1305 RTK]: ../gps_compass/rtk_gps_gem1305.md
[DroneCAN]: ../dronecan/index.md
[GPS Yaw]: #configuring-gps-as-yaw-heading-source
[mosaic-G5 P3]: https://www.septentrio.com/en/products/gnss-receivers/gnss-receiver-modules/mosaic-G5-P3
[mosaic-G5 P3H]: https://www.septentrio.com/en/products/gnss-receivers/gnss-receiver-modules/mosaic-G5-P3H
[D10P]: https://docs.datagnss.com/gnss/gnss_module/D10P_RTK
Notes:
@@ -143,6 +150,7 @@ The RTK GPS connection is essentially plug and play:
![survey-in](../../assets/qgc/setup/rtk/qgc_rtk_survey-in.png)
1. Once Survey-in completes:
- The RTK GPS icon changes to white and _QGroundControl_ starts to stream position data to the vehicle:
![RTK streaming](../../assets/qgc/setup/rtk/qgc_rtk_streaming.png)
docs/en/middleware/uxrce_dds.md
+2 -2
View File
@@ -321,7 +321,7 @@ The configuration can be done using the [UXRCE-DDS parameters](../advanced_confi
- [UXRCE_DDS_SYNCT](../advanced_config/parameter_reference.md#UXRCE_DDS_SYNCT): Bridge time synchronization enable.
The uXRCE-DDS client module can synchronize the timestamp of the messages exchanged over the bridge.
This is the default configuration. In certain situations, for example during [simulations](../ros2/user_guide.md#ros-gazebo-and-px4-time-synchronization), this feature may be disabled.
- <Badge type="tip" text="PX4 v1.17" /> [`UXRCE_DDS_NS_IDX`](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX): Index-based namespace definition
- [UXRCE_DDS_NS_IDX](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) <Badge type="tip" text="PX4 v1.17" />: Index-based namespace definition
Setting this parameter to any value other than `-1` creates a namespace with the prefix `uav_` and the specified value, e.g. `uav_0`, `uav_1`, etc.
See [namespace](#customizing-the-namespace) for methods to define richer or arbitrary namespaces.
@@ -426,7 +426,7 @@ will generate topics under the namespaces:
:::
- A simple index-based namespace can be applied by setting the parameter [`UXRCE_DDS_NS_IDX`](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) to a value between 0 and 9999.
- A simple index-based namespace can be applied by setting the parameter [`UXRCE_DDS_NS_IDX`](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) <Badge type="tip" text="PX4 v1.17" /> to a value between 0 and 9999.
This will generate a namespace such as `/uav_0`, `/uav_1`, and so on.
This technique is ideal if vehicles must be persistently associated with namespaces because their clients are automatically started through PX4.
docs/en/neural_networks/index.md
+21
View File
@@ -0,0 +1,21 @@
# Neural Network Control
PX4 supports the following mechanisms for using neural networks for multirotor control:
- [MC Neural Networks Control](../neural_networks/mc_neural_network_control.md)<Badge type="warning" text="Experimental" /> — A generic neural network module that you can modify to use different underlying neural network and training models and compile into the firmware.
- [RAPTOR: A Neural Network Module for Adaptive Quadrotor Control](../neural_networks/raptor.md)<Badge type="warning" text="Experimental" /> — An adaptive RL NN module that works well with different Quad configurations without additional training.
Generally you will select the former if you wish to experiment with custom neural network architectures and train them using PyTorch or TensorFlow, and the latter if you want to use a pre-trained neural-network controller that works out-of-the-box (without training for your particular platform) or if you train your own policies using [RLtools](https://rl.tools).
Note that both modules are experimental and provided for experimentation.
The table below provides more detail on the differences.
| Use Case | [`mc_raptor`](../neural_networks/raptor.md) | [`mc_nn_control`](../neural_networks/mc_neural_network_control.md) |
| ---------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------ |
| Pre-trained policy that adapts to any quadrotor without training | ✓ RAPTOR | ✘ |
| Train policy in PyTorch/TF | ✘ | ✓ TF Lite |
| Train policy in RLtools | ✓ | ✘ |
| Use manual control (remote) with NN policy | ✘ GPS/MoCap | ✓ Manual attitude commands |
| Load policy checkpoints from SD card | ✓ Upload via MAVLink FTP | ✘ Compiled into firmware |
| Offboard setpoints | ✓ MAVLink | ✘ |
| Internal Trajectory Generator | ✓ (Position, Lissajous) | ✘ |
docs/en/neural_networks/mc_neural_network_control.md
+119
View File
@@ -0,0 +1,119 @@
# MC Neural Networks Control
<Badge type="tip" text="PX4 v1.17" /> <Badge type="warning" text="Experimental" />
::: warning
This is an experimental module.
Use at your own risk.
:::
The Multicopter Neural Network (NN) module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) is an example module that allows you to experiment with using a pre-trained neural network on PX4.
It might be used, for example, to experiment with controllers for non-traditional drone morphologies, computer vision tasks, and so on.
The module integrates a pre-trained neural network based on the [TensorFlow Lite Micro (TFLM)](./tflm.md) module.
The module is trained for the [X500 V2](../frames_multicopter/holybro_x500v2_pixhawk6c.md) multicopter frame.
While the controller is fairly robust, and might work on other platforms, we recommend [Training your own Network](#training-your-own-network) if you use a different vehicle.
Note that after training the network you will need to update and rebuild PX4.
TLFM is a mature inference library intended for use on embedded devices.
It has support for several architectures, so there is a high likelihood that you can build it for the board you want to use.
If not, there are other possible NN frameworks, such as [Eigen](https://eigen.tuxfamily.org/index.php?title=Main_Page) and [Executorch](https://pytorch.org/executorch-overview).
This document explains how you can include the module in your PX4 build, and provides a broad overview of how it works.
The other documents in the section provide more information about the integration, allowing you to replace the NN with a version trained on different data, or even to replace the TLFM library altogether.
If you are looking for more resources to learn about the module, a website has been created with links to a youtube video and a workshop paper. A full master's thesis will be added later. [A Neural Network Mode for PX4 on Embedded Flight Controllers](https://ntnu-arl.github.io/px4-nns/).
## Neural Network PX4 Firmware
::: warning
This module requires Ubuntu 24.04 or newer (it is not supported in Ubuntu 22.04).
:::
The module has been tested on a number of configurations, which can be build locally using the commands:
```sh
make px4_sitl_neural
```
```sh
make px4_fmu-v6c_neural
```
```sh
make mro_pixracerpro_neural
```
You can add the module to other board configurations by modifying their `default.px4board file` configuration to include these lines:
```sh
CONFIG_LIB_TFLM=y
CONFIG_MODULES_MC_NN_CONTROL=y
```
:::tip
The `mc_nn_control` module takes up roughly 50KB, and many of the `default.px4board file` are already close to filling all the flash on their boards. To make room for the neural control module you can remove the include statements for other modules, such as FW, rover, VTOL and UUV.
:::
## Example Module Overview
The example module replaces the entire controller structure as well as the control allocator, as shown in the diagram below:
![neural_control](../../assets/advanced/neural_control.png)
In the [controller diagram](../flight_stack/controller_diagrams.md) you can see the [uORB message](../middleware/uorb.md) flow.
We hook into this flow by subscribing to messages at particular points, using our neural network to calculate outputs, and then publishing them into the next point in the flow.
We also need to stop the module publishing the topic to be replaced, which is covered in [Neural Network Module: System Integration](nn_module_utilities.md)
### Input
The input can be changed to whatever you want.
Set up the input you want to use during training and then provide the same input in PX4.
In the Neural Control module the input is an array of 15 numbers, and consists of these values in this order:
- [3] Local position error. (goal position - current position)
- [6] The first 2 rows of a 3 dimensional rotation matrix.
- [3] Linear velocity
- [3] Angular velocity
All the input values are collected from uORB topics and transformed into the correct representation in the `PopulateInputTensor()` function.
PX4 uses the NED frame representation, while the Aerial Gym Simulator, in which the NN was trained, uses the ENU representation.
Therefore two rotation matrices are created in the function and all the inputs are transformed from the NED representation to the ENU one.
![ENU-NED](../../assets/advanced/ENU-NED.png)
ENU and NED are just rotation representations, the translational difference is only there so both can be seen in the same figure.
### Output
The output consists of 4 values, the motor forces, one for each motor.
These are transformed in the `RescaleActions()` function.
This is done because PX4 expects normalized motor commands while the Aerial Gym Simulator uses physical values.
So the output from the network needs to be normalized before they can be sent to the motors in PX4.
The commands are published to the [ActuatorMotors](../msg_docs/ActuatorMotors.md) topic.
The publishing is handled in `PublishOutput(float* command_actions)` function.
:::tip
If the neural control mode is too aggressive or unresponsive the [MC_NN_THRST_COEF](../advanced_config/parameter_reference.md#MC_NN_THRST_COEF) parameter can be tuned.
Decrease it for more thrust.
:::
## Training your own Network
The network is currently trained for the [X500 V2](../frames_multicopter/holybro_x500v2_pixhawk6c.md).
But the controller is somewhat robust, so it could work directly on other platforms, but performing system identification and training a new network is recommended.
Since the Aerial Gym Simulator is open-source you can download it and train your own networks as long as you have access to an NVIDIA GPU.
If you want to train a control network optimized for your platform you can follow the instructions in the [Aerial Gym Documentation](https://ntnu-arl.github.io/aerial_gym_simulator/9_sim2real/).
You should do one system identification flight for this and get an approximate inertia matrix for your platform.
On the `sys-id` flight you need ESC telemetry, you can read more about that in [DSHOT](../peripherals/dshot.md).
Then do the following steps:
- Do a hover flight
- Read of the logs what RPM is required for the drone to hover.
- Use the weight of each motor, length of the motor arms, total weight of the platform with battery to calculate an approximate inertia matrix for the platform.
- Insert these values into the Aerial Gym configuration and train your network.
- Convert the network as explained in [TFLM](tflm.md).
docs/en/advanced/nn_module_utilities.md → docs/en/neural_networks/nn_module_utilities.md
+2 -2
View File
@@ -2,7 +2,7 @@
The neural control module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) implements an end-to-end controller utilizing neural networks.
The parts of the module directly concerned with generating the code for the trained neural network and integrating it into the module are covered in [TensorFlow Lite Micro (TFLM)](../advanced/tflm.md).
The parts of the module directly concerned with generating the code for the trained neural network and integrating it into the module are covered in [TensorFlow Lite Micro (TFLM)](./tflm.md).
This page covers the changes that were made to integrate the module into PX4, both within the module, and in larger system configuration.
::: tip
@@ -75,7 +75,7 @@ Which timing library is included and used is based on wether PX4 is built with N
## Changing the setpoint
The module uses the [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) message’s position fields to define its target.
The module uses the [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) message's position fields to define its target.
To follow a trajectory, you can send updated setpoints.
For an example of how to do this in a PX4 module, see the [mc_nn_testing](https://github.com/SindreMHegre/PX4-Autopilot-public/tree/main/src/modules/mc_nn_testing) module in this fork.
Note that this is not included in upstream PX4.
docs/en/neural_networks/raptor.md
+221
View File
@@ -0,0 +1,221 @@
# RAPTOR: A Neural Network Module for Adaptive Quadrotor Control
<Badge type="tip" text="main (planned for PX4 v1.18)" /> <Badge type="info" text="Multicopter" /> <Badge type="warning" text="Experimental" />
::: warning
This is an experimental module.
Use at your own risk.
:::
RAPTOR is a tiny reinforcement-learning based neural network module for quadrotor control that can be used to control a wide variety of quadrotors without retuning.
This topic provides an overview of the fundamental concepts, and explains how you can use the module in simulation and real hardware.
## Overview
![Visual Abstract](../../assets/advanced/neural_networks/raptor/visual_abstract.jpg)
RAPTOR is an adaptive policy for end-to-end quadrotor control.
It is motivated by the human ability to adapt learned behaviours to similar situations.
For example, while humans may initially require many hours of driving experience to be able to smoothly control the car and blend into traffic, when faced with a new vehicle they do not need to re-learn how to drive — they only need to experience a few rough braking/acceleration/steering responses to adjust their previously learned behavior.
Reinforcement Learning (RL) is a machine learning technique that uses trial and error to learn decision making/control behaviors, which is similar to the way that humans learn to drive.
RL is interesting for controlling robots (and particularly UAVs) because it overcomes some fundamental limitations of classic, modular control architectures (information loss at module boundaries, requirement for expert tuning, etc).
RL has been very successful in [high-performance quadrotor flight](https://doi.org/10.1038/s41586-023-06419-4), but previous designs have not been particularly adaptable to new frames and vehicle types.
RAPTOR fills this gap and demonstrates a single, tiny neural-network control policy that can control a wide variety of quadrotors (tested on real quadrotors from 32 g to 2.4 kg).
For more details please refer to this video:
<lite-youtube videoid="hVzdWRFTX3k" title="RAPTOR: A Foundation Policy for Quadrotor Control"/>
The method we developed for training the RAPTOR policy is called Meta-Imitation Learning:
![Diagram showing the Method Overview](../../assets/advanced/neural_networks/raptor/method.jpg)
You can torture test the RAPTOR policy in your browser at [https://raptor.rl.tools](https://raptor.rl.tools) or in the embedded app here:
<iframe src="https://rl-tools.github.io/raptor.rl.tools?raptor=false" width="100%" height="1000" style="border: none;"></iframe>
For more information please refer to the paper at [https://arxiv.org/abs/2509.11481](https://arxiv.org/abs/2509.11481).
## Structure
The RAPTOR control policy is an end-to-end policy that takes position, orientation, linear velocity and angular velocity as inputs and outputs motor commands (`actuator_motors`).
To integrate it into PX4 we use the external mode registration facilities in PX4 (which also works well for internal modes as demonstrated in `mc_nn_control`).
Because of this architecture the `mc_raptor` module is completely decoupled from all other PX4 logic.
By default, the RAPTOR module expects setpoints via `trajectory_setpoint` messages.
If no `trajectory_setpoint` messages are received or if no `trajectory_setpoint` is received within 200 ms, the current position and orientation (with zero velocity) is used as the setpoint.
Since feeding setpoints reliably via telemetry is still a challenge, we also implement a simple option to generate internal reference trajectories (controlled through the `MC_RAPTOR_INTREF` parameter) for demonstration and benchmarking purposes.
## Features
- Tiny neural network (just 2084 parameters) => minimal CPU usage
- Easily maintainable
- Simple CMake setup
- Self-contained (no interference with other modules)
- Single, simple and well-maintained dependency (RLtools)
- Loading neural network parameters from SD card
- Minimal flash usage (for possible inclusion into default build configurations)
- Easy development: Train new neural network and just upload it via MAVLink FTP without requiring to re-flash the firmware
- Tested on 10+ different real platforms (including flexible frames, brushed motors)
- Actively developed and maintained
## Usage
### SITL
Build PX4 SITL with Raptor, disable QGC requirement, and adjust the `IMU_GYRO_RATEMAX` to match the simulation IMU rate
```sh
make px4_sitl_raptor gz_x500
param set NAV_DLL_ACT 0
param set COM_DISARM_LAND -1 # When taking off in offboard the landing detector can cause mid-air disarms
param set IMU_GYRO_RATEMAX 250 # Just for SITL. Tested with IMU_GYRO_RATEMAX=400 on real FCUs
param set MC_RAPTOR_ENABLE 1 # Enable the mc_raptor module
param save
```
Upload the RAPTOR checkpoint to the "SD card": Separate terminal
```bash
mavproxy.py --master udp:127.0.0.1:14540
ftp mkdir /raptor # for the real FMU use: /fs/microsd/raptor
ftp put src/modules/mc_raptor/blob/policy.tar /raptor/policy.tar
```
Restart (<kbd>Ctrl+C</kbd>)
```sh
make px4_sitl_raptor gz_x500
commander takeoff
commander status
```
Note the external mode ID of `RAPTOR` in the status report
```sh
commander mode ext{RAPTOR_MODE_ID}
```
#### Internal Reference Trajectory Generation
In our experience, feeding the `trajectory_setpoint` via MAVLink (even via WiFi telemetry) is unreliable.
But we do not want to constrain this module to only platforms that have a companion board.
For this reason we have integrated a simple internal reference trajectory generator for testing and benchmarking purposes.
It supports position (constant position and yaw setpoint) as well as configurable [Lissajous trajectories](https://en.wikipedia.org/wiki/Lissajous_curve).
The Lissajous generator can, for example, generate smooth figure-eight trajectories that contain interesting accelerations for benchmarking and testing purposes.
Please refer to the embedded configurator later in this section to explore the Lissajous parameters and view the resulting trajectories.
To use the internal reference generator, select the mode: `0`: Off/activation position tracking, `1`: Lissajous
```sh
param set MC_RAPTOR_INTREF 1
```
Restart (ctrl+c)
```sh
commander takeoff
commander mode ext{RAPTOR_MODE_ID}
mc_raptor intref lissajous 0.5 1 0 2 1 1 10 3
```
The trajectory is relative to the position and yaw of the vehicle at the point where the RAPTOR mode is activated (or the position and yaw where the parameters are changed if it is already activated).
You can adjust the parameters of the trajectory with the following tool.
Make sure to copy the generated CLI string at the end:
<iframe src="https://rl-tools.github.io/mc-raptor-trajectory-tool" width="100%" height="1700" style="border: none;"></iframe>
### Real-World
#### Setup
The `mc_raptor` module has been mostly tested with the Holybro X500 V2 but it should also work out-of-the-box with other platforms (see the [Other Platforms](#other-platforms) section).
```sh
make px4_fmu-v6c_raptor upload
```
We recommend initially testing the RAPTOR mode using a dead man's switch.
For this we configure the mode selection to be connected to a push button or a switch with a spring that automatically switches back.
In the default position we configure e.g. `Stabilized Mode` and in the pressed configuration we select `External Mode 1` (since the name of the external mode is only transmitted at runtime).
This allows to take off manually and then just trigger the RAPTOR mode for a split-second to see how it behaves.
In our experiments it has been exceptionally stable (zero crashes) but we still think progressively activating it for longer is the safest way to build confidence.
::: warning
Make sure that your platform uses the standard PX4 quadrotor motor layout:
1: front-right, 2: back-left, 3: front-left, 4: back-right
:::
##### Other Platforms
To enable the `mc_raptor` module in other platforms, just add `CONFIG_MODULES_MC_RAPTOR=y` and `CONFIG_LIB_RL_TOOLS=y`
```diff
+++ b/boards/px4/fmu-v6c/raptor.px4board
@@ -35,2 +35,3 @@
CONFIG_DRIVERS_UAVCAN=y
+CONFIG_LIB_RL_TOOLS=y
CONFIG_MODULES_AIRSPEED_SELECTOR=y
@@ -64,2 +65,3 @@
CONFIG_MODULES_MC_POS_CONTROL=y
+CONFIG_MODULES_MC_RAPTOR=y
CONFIG_MODULES_MC_RATE_CONTROL=y
```
#### Results
Even though there were moderate winds (~ 5 m/s) during the test, we found good figure-eight tracking performance at velocities up to 12 m/s:
![Lissajous](../../assets/advanced/neural_networks/raptor/results_figure_eight.svg)
We also tested the linear velocity in a straight line and found that the RAPTOR policy can reliably fly at > 17 m/s (the wind direction was orthogonal to the line):
![Linear Oscillation](../../assets/advanced/neural_networks/raptor/results_line.svg)
### Troubleshooting
#### Logging
Use this logging configuration to log all relevant topics at maximum rate:
```sh
cat > logger_topics.txt << EOF
raptor_status 0
raptor_input 0
trajectory_setpoint 0
vehicle_local_position 0
vehicle_angular_velocity 0
vehicle_attitude 0
vehicle_status 0
actuator_motors 0
EOF
```
Use mavproxy FTP to upload it:
```sh
mavproxy.py
```
##### Real
```sh
ftp mkdir /fs/microsd/etc
ftp mkdir /fs/microsd/etc/logging
ftp put logger_topics.txt /fs/microsd/etc/logging/logger_topics.txt
```
##### SITL
```sh
ftp mkdir etc
ftp mkdir logging
ftp put logger_topics.txt etc/logging/logger_topics.txt
```
docs/en/advanced/tflm.md → docs/en/neural_networks/tflm.md
+2 -2
View File
@@ -1,6 +1,6 @@
# TensorFlow Lite Micro (TFLM)
The PX4 [Multicopter Neural Network](../advanced/neural_networks.md) module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) integrates a neural network that uses the [TensorFlow Lite Micro (TFLM)](https://github.com/tensorflow/tflite-micro) inference library.
The PX4 [MC Neural Networks Control](../neural_networks/mc_neural_network_control.md) module ([mc_nn_control](../modules/modules_controller.md#mc-nn-control)) integrates a neural network that uses the [TensorFlow Lite Micro (TFLM)](https://github.com/tensorflow/tflite-micro) inference library.
This is a mature inference library intended for use on embedded devices, and is hence a suitable choice for PX4.
@@ -68,7 +68,7 @@ The `_input_tensor` is also defined, it is fetched from `_control_interpreter->i
The `_input_tensor` is filled in the `PopulateInputTensor()` function.
`_input_tensor` works by accessing the `->data.f` member array and fill in the required inputs for your network.
The inputs used in the control network is covered in [Neural Networks](../advanced/neural_networks.md).
The inputs used in the control network is covered in [MC Neural Networks Control](../neural_networks/mc_neural_network_control.md).
### Outputs
docs/en/peripherals/esc_motors.md
+1 -1
View File
@@ -30,7 +30,7 @@ The following list is non-exhaustive.
[PWM]: ../peripherals/pwm_escs_and_servo.md
[Holybro Kotleta 20]: ../dronecan/holybro_kotleta.md
[Vertiq Motor & ESC modules]: ../peripherals/vertiq.md
[RaccoonLab CAN PWM nodes]: ../dronecan/raccoonlab_nodes.md
[RaccoonLab CAN PWM ESC nodes]: ../dronecan/raccoonlab_nodes.md
[Zubax Telega]: ../dronecan/zubax_telega.md
## See Also
docs/en/releases/1.16.md
+2
View File
@@ -129,6 +129,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### uXRCE-DDS / ROS2
- [PX4-Autopilot#24113](https://github.com/PX4/PX4-Autopilot/pull/24113): <Badge type="warning" text="Experimental"/> [ROS 2 Message Translation Node](../ros2/px4_ros2_msg_translation_node.md) to translate PX4 messages from one definition version to another dynamically
- <Badge type="warning" text="Experimental"/>[PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [ROS-based waypoint missions](../ros2/px4_ros2_waypoint_missions.md).
- dds_topics: add vtol_vehicle_status ([PX4-Autopilot#24582](https://github.com/PX4/PX4-Autopilot/pull/24582))
- dds_topics: add home_position ([PX4-Autopilot#24583](https://github.com/PX4/PX4-Autopilot/pull/24583))
@@ -138,6 +139,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
- Parameter to always start mavlink stream via USB. ([PX4-Autopilot#22234](https://github.com/PX4/PX4-Autopilot/pull/22234))
- Refactor: MAVLink message handling in one function, reference instead of pointer to main instance ([PX4-Autopilo#23219](https://github.com/PX4/PX4-Autopilot/pull/22234))
- mavlink log handler rewrite for improved effeciency ([PX4-Autopilo#23219](https://github.com/PX4/PX4-Autopilot/pull/22234))
### Multi-Rotor
- [Multirotor] add yaw torque low pass filter ([PX4-Autopilot#24173](https://github.com/PX4/PX4-Autopilot/pull/24173))
docs/en/releases/1.17.md
+134
View File
@@ -0,0 +1,134 @@
# PX4-Autopilot v1.17.0 Release Notes
<Badge type="danger" text="Alpha/Beta" />
<script setup>
import { useData } from 'vitepress'
const { site } = useData();
</script>
<div v-if="site.title !== 'PX4 Guide (main)'">
<div class="custom-block danger">
<p class="custom-block-title">This page is on a release branch, and hence probably out of date. <a href="https://docs.px4.io/main/en/releases/main.html">See the latest version</a>.</p>
</div>
</div>
This contains changes to PX4 planned for PX4 v1.17 (since the last major release [PX v1.16](../releases/1.16.md)).
::: warning
PX4 v1.17 is in alpha/beta testing.
Update these notes with features that are going to be in PX4 v1.17 release.
New features that are not expected to go into the v1.17 release are in [PX4-Autopilot `main` Release Notes](../releases/main.md).
:::
## Read Before Upgrading
TBD …
Please continue reading for [upgrade instructions](#upgrade-guide).
## Major Changes
- TBD
## Upgrade Guide
## Other changes
### Hardware Support
- **[New Hardware]** boards: [MicoAir743-Lite FC](../flight_controller/micoair743-lite.md) <!-- CHECK is this version and add PR link (or fix up doc version tag and move this) -->
- **[New Hardware]** boards: [RadiolinkPIX6 FC](../flight_controller/radiolink_pix6.md) <!-- CHECK is this version and add PR! -->
- **[New Hardware]** boards: [AP-H743-R1 FC](../flight_controller/x-mav_ap-h743r1.md) <!-- CHECK is this version and add PR! -->
<!--
### Common
- [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
<!--
- Added new flight mode(s): [Altitude Cruise (MC)](../flight_modes_mc/altitude_cruise.md), Altitude Cruise (FW).
For fixed-wing the mode behaves the same as Altitude mode but you can disable the manual control loss failsafe. ([PX4-Autopilot#25435: Add new flight mode: Altitude Cruise](https://github.com/PX4/PX4-Autopilot/pull/25435)).
-->
- <Badge type="warning" text="Experimental" /> [MC Neural Network Module](../advanced/neural_networkss.md)
### Estimation
- TBD
<!--
### Sensors
- Add [sbgECom INS driver](../sensor/sbgecom.md) ([PX4-Autopilot#24137](https://github.com/PX4/PX4-Autopilot/pull/24137))
- Quick magnetometer calibration now supports specifying an arbitrary initial heading ([PX4-Autopilot#24637](https://github.com/PX4/PX4-Autopilot/pull/24637))
-->
### Simulation
- Overhaul rover simulation:
- Add synthetic differential rover model: [PX4-gazebo-models#107](https://github.com/PX4/PX4-gazebo-models/pull/107)
- Add synthetic mecanum rover model: [PX4-gazebo-models#113](https://github.com/PX4/PX4-gazebo-models/pull/113)
- Update synthetic ackermann rover model: [PX4-gazebo-models#117](https://github.com/PX4/PX4-gazebo-models/pull/117)
- [Simulation-in-Hardware (SIH)](../sim_sih/index.md#compatibility) <!-- Listed in https://docs.px4.io/main/en/sim_sih/#compatibility : Check the PRs -->
- New simulation: MC Hexacopter X
- New simulation: Ackermann Rover
### Debug & Logging
- TBD
### Ethernet
- TBD
### uXRCE-DDS / Zenoh / ROS2
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [Fixed Wing lateral/longitudinal setpoint](../ros2/px4_ros2_control_interface.md#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype) (`FwLateralLongitudinalSetpointType`) and [VTOL transitions](../ros2/px4_ros2_control_interface.md#controlling-a-vtol). ([PX4-Autopilot#24056](https://github.com/PX4/PX4-Autopilot/pull/24056)).
- [UXRCE_DDS: Simple index based namespace (UXRCE_DDS_NS_IDX)](../middleware/uxrce_dds.md#customizing-the-namespace)
- [Zenoh (PX4 ROS 2 rmw_zenoh)](../middleware/zenoh.md)
### MAVLink
- TBD
<!--
### RC
- Parse ELRS Status and Link Statistics TX messages in the CRSF parser.
### Multi-Rotor
- Removed parameters `MPC_{XY/Z/YAW}_MAN_EXPO` and use default value instead, as they were not deemed necessary anymore. ([PX4-Autopilot#25435: Add new flight mode: Altitude Cruise](https://github.com/PX4/PX4-Autopilot/pull/25435)).
- Renamed `MPC_HOLD_DZ` to `MAN_DEADZONE` to have it globally available in modes that allow for a dead zone. ([PX4-Autopilot#25435: Add new flight mode: Altitude Cruise](https://github.com/PX4/PX4-Autopilot/pull/25435)).
-->
### VTOL
- TBD
### Fixed-wing
- [Fixed Wing Takeoff mode](../flight_modes_fw/takeoff.md) will now keep climbing with level wings on position loss.
A target takeoff waypoint can be set to control takeoff course and loiter altitude. ([PX4-Autopilot#25083](https://github.com/PX4/PX4-Autopilot/pull/25083)).
- Automatically suppress angular rate oscillations using [Gain compression](../features_fw/gain_compression.md). ([PX4-Autopilot#25840: FW rate control: add gain compression algorithm](https://github.com/PX4/PX4-Autopilot/pull/25840))
### Rover
- Removed deprecated rover module ([PX4-Autopilot#25054](https://github.com/PX4/PX4-Autopilot/pull/25054)).
- Add support for [Apps & API](../flight_modes_rover/api.md) including [Rover Setpoints](../ros2/px4_ros2_control_interface.md#rover-setpoints) ([PX4-Autopilot#25074](https://github.com/PX4/PX4-Autopilot/pull/25074), [PX4-ROS2-Interface-Lib#140](https://github.com/Auterion/px4-ros2-interface-lib/pull/140)).
- Update [rover simulation](../frames_rover/index.md#simulation) ([PX4-Autopilot#25644](https://github.com/PX4/PX4-Autopilot/pull/25644)) (see [Simulation](#simulation) release note for details).
### ROS 2
- TBD
docs/en/releases/index.md
+2 -1
View File
@@ -2,7 +2,8 @@
A list of PX4 release notes, they contain a list of the changes that went into each release, explaining the included features, bug fixes, deprecations and updates in detail.
- [main](../releases/main.md) (changes since v1.16)
- [main](../releases/main.md) (changes planned for v1.18 or later)
- [v1.17](../releases/1.17.md) (changes planned for v1.17, since v1.16)
- [v1.16](../releases/1.16.md)
- [v1.15](../releases/1.15.md)
- [v1.14](../releases/1.14.md)
docs/en/releases/main.md
+30 -6
View File
@@ -16,13 +16,13 @@ const { site } = useData();
This contains changes to PX4 `main` branch since the last major release ([PX v1.16](../releases/1.16.md)).
::: warning
PX4 v1.16 is in candidate-release testing, pending release.
Update these notes with features that are going to be in `main` but not the PX4 v1.16 release.
PX4 v1.17 is in alpha/beta testing.
Update these notes with features that are going to be in `main` (PX4 v1.18 or later) but not the PX4 v1.17 release.
:::
## Read Before Upgrading
TBD …
- TBD …
Please continue reading for [upgrade instructions](#upgrade-guide).
@@ -45,8 +45,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### Control
- Added new flight mode(s): [Altitude Cruise (MC)](../flight_modes_mc/altitude_cruise.md), Altitude Cruise (FW).
For fixed-wing the mode behaves the same as Altitude mode but you can disable the manual control loss failsafe. ([PX4-Autopilot#25435: Add new flight mode: Altitude Cruise
](https://github.com/PX4/PX4-Autopilot/pull/25435)).
For fixed-wing the mode behaves the same as Altitude mode but you can disable the manual control loss failsafe. ([PX4-Autopilot#25435: Add new flight mode: Altitude Cruise](https://github.com/PX4/PX4-Autopilot/pull/25435)).
### Estimation
@@ -59,19 +58,34 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### Simulation
- TBD
<!-- MOVED THIS TO v1.17
- Overhaul rover simulation:
- Add synthetic differential rover model: [PX4-gazebo-models#107](https://github.com/PX4/PX4-gazebo-models/pull/107)
- Add synthetic mecanum rover model: [PX4-gazebo-models#113](https://github.com/PX4/PX4-gazebo-models/pull/113)
- Update synthetic ackermann rover model: [PX4-gazebo-models#117](https://github.com/PX4/PX4-gazebo-models/pull/117)
-->
### Debug & Logging
- [Asset Tracking](../debug/asset_tracking.md): Automatic tracking and logging of external device information including vendor name, firmware and hardware version, serial numbers. Currently supports DroneCAN devices. ([PX4-Autopilot#25617](https://github.com/PX4/PX4-Autopilot/pull/25617))
### Ethernet
- TBD
### uXRCE-DDS / ROS2
### uXRCE-DDS / Zenoh / ROS2
- TBD
<!-- MOVED THIS TO v1.17
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [Fixed Wing lateral/longitudinal setpoint](../ros2/px4_ros2_control_interface.md#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype) (`FwLateralLongitudinalSetpointType`) and [VTOL transitions](../ros2/px4_ros2_control_interface.md#controlling-a-vtol). ([PX4-Autopilot#24056](https://github.com/PX4/PX4-Autopilot/pull/24056)).
- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_control_interface.md) support for [ROS-based waypoint missions](../ros2/px4_ros2_waypoint_missions.md).
-->
### MAVLink
@@ -92,16 +106,26 @@ Please continue reading for [upgrade instructions](#upgrade-guide).
### Fixed-wing
- TBD
<!-- MOVED THIS TO v1.17
- [Fixed Wing Takeoff mode](../flight_modes_fw/takeoff.md) will now keep climbing with level wings on position loss.
A target takeoff waypoint can be set to control takeoff course and loiter altitude. ([PX4-Autopilot#25083](https://github.com/PX4/PX4-Autopilot/pull/25083)).
- Automatically suppress angular rate oscillations using [Gain compression](../features_fw/gain_compression.md). ([PX4-Autopilot#25840: FW rate control: add gain compression algorithm](https://github.com/PX4/PX4-Autopilot/pull/25840))
-->
### Rover
- TBD
<!-- MOVED THIS TO v1.17
- Removed deprecated rover module ([PX4-Autopilot#25054](https://github.com/PX4/PX4-Autopilot/pull/25054)).
- Add support for [Apps & API](../flight_modes_rover/api.md) ([PX4-Autopilot#25074](https://github.com/PX4/PX4-Autopilot/pull/25074), [PX4-ROS2-Interface-Lib#140](https://github.com/Auterion/px4-ros2-interface-lib/pull/140)).
- Update [rover simulation](../frames_rover/index.md#simulation) ([PX4-Autopilot#25644](https://github.com/PX4/PX4-Autopilot/pull/25644)) (see [Simulation](#simulation) release note for details).
-->
### ROS 2
- TBD
docs/en/ros2/px4_ros2_control_interface.md
+5 -5
View File
@@ -341,9 +341,9 @@ The used types also define the compatibility with different vehicle types.
The following sections provide a list of supported setpoint types:
- [MulticopterGotoSetpointType](#go-to-setpoint-multicoptergotosetpointtype): <Badge type="warning" text="MC only" /> Smooth position and (optionally) heading control
- [FwLateralLongitudinalSetpointType](#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype): <Badge type="warning" text="FW only" /> <Badge type="tip" text="main (planned for: PX4 v1.17)" /> Direct control of lateral and longitudinal fixed wing dynamics
- [FwLateralLongitudinalSetpointType](#fixed-wing-lateral-and-longitudinal-setpoint-fwlaterallongitudinalsetpointtype): <Badge type="warning" text="FW only" /> <Badge type="tip" text="PX4 v1.17" /> Direct control of lateral and longitudinal fixed wing dynamics
- [DirectActuatorsSetpointType](#direct-actuator-control-setpoint-directactuatorssetpointtype): Direct control of motors and flight surface servo setpoints
- [Rover Setpoints](#rover-setpoints): <Badge type="tip" text="main (planned for: PX4 v1.17)" /> Direct access to rover control setpoints (Position, Speed, Attitude, Rate, Throttle and Steering).
- [Rover Setpoints](#rover-setpoints): <Badge type="tip" text="PX4 v1.17" /> Direct access to rover control setpoints (Position, Speed, Attitude, Rate, Throttle and Steering).
:::tip
The other setpoint types are currently experimental, and can be found in: [px4_ros2/control/setpoint_types/experimental](https://github.com/Auterion/px4-ros2-interface-lib/tree/main/px4_ros2_cpp/include/px4_ros2/control/setpoint_types/experimental).
@@ -410,7 +410,7 @@ _goto_setpoint->update(
#### Fixed-Wing Lateral and Longitudinal Setpoint (FwLateralLongitudinalSetpointType)
<Badge type="warning" text="Fixed wing only" /> <Badge type="tip" text="main (planned for: PX4 v1.17)" />
<Badge type="warning" text="Fixed wing only" /> <Badge type="tip" text="PX4 v1.17" />
::: info
This setpoint type is supported for fixed-wing vehicles and for VTOLs in fixed-wing mode.
@@ -552,7 +552,7 @@ If you want to control an actuator that does not control the vehicle's motion, b
#### Rover Setpoints
<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />
<Badge type="tip" text="PX4 v1.17" /> <Badge type="warning" text="Experimental" />
The rover modules use a hierarchical structure to propagate setpoints:
@@ -586,7 +586,7 @@ An example for a rover specific drive mode using the `RoverSpeedAttitudeSetpoint
### Controlling a VTOL
<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />
<Badge type="tip" text="PX4 v1.17" /> <Badge type="warning" text="Experimental" />
To control a VTOL in an external flight mode, ensure you're returning the correct setpoint type based on the current flight configuration:
docs/en/sim_sih/index.md
+3 -2
View File
@@ -27,8 +27,8 @@ The Desktop computer is only used to display the virtual vehicle.
- SIH for FW (airplane) and VTOL tailsitter are supported from PX4 v1.13.
- SIH as SITL (without hardware) from PX4 v1.14.
- SIH for Standard VTOL from PX4 v1.16.
- SIH for MC Hexacopter X from `main` (expected to be PX4 v1.17).
- SIH for Ackermann Rover from `main`.
- SIH for MC Hexacopter X from PX4 v1.17.
- SIH for Ackermann Rover from PX4 v1.17.
### Benefits
@@ -339,6 +339,7 @@ You can find a full list of available values for `PWM_MAIN_FUNCn` [here](../adva
Alternatively, you can use the [`PWM_AUX_FUNCn`](../advanced_config/parameter_reference.md#PWM_AUX_FUNC1) parameters.
You may also configure the output as desired:
- Disarmed PWM: ([`PWM_MAIN_DISn`](../advanced_config/parameter_reference.md#PWM_MAIN_DIS1) / [`PWM_AUX_DIS1`](../advanced_config/parameter_reference.md#PWM_AUX_DIS1))
- Minimum PWM ([`PWM_MAIN_MINn`](../advanced_config/parameter_reference.md#PWM_MAIN_MIN1) / [`PWM_AUX_MINn`](../advanced_config/parameter_reference.md#PWM_AUX_MIN1))
- Maximum PWM ([`PWM_MAIN_MAXn`](../advanced_config/parameter_reference.md#PWM_MAIN_MAX1) / [`PWM_AUX_MAXn`](../advanced_config/parameter_reference.md#PWM_AUX_MAX1))
docs/ko/SUMMARY.md
+8 -4
View File
@@ -315,15 +315,17 @@
- [ADSB/FLARM (트래픽 회피)](config/actuators.md)
- [ESC 보정](advanced_config/esc_calibration.md)
- [ESC와 모터](peripherals/esc_motors.md)
- [ESC Protocols](esc/esc_protocols.md)
- [PWM ESC와 서보](peripherals/pwm_escs_and_servo.md)
- [DShot ESCs](peripherals/dshot.md)
- [OneShot ESCs and Servos](peripherals/oneshot.md)
- [DroneCAN ESCs](dronecan/escs.md)
- [Zubax Telega](dronecan/zubax_telega.md)
- [PX4 Sapog ESC Firmware](dronecan/sapog.md)
- [Holybro Kotleta](dronecan/holybro_kotleta.md)
- [Vertiq](peripherals/vertiq.md)
- [VESC](peripherals/vesc.md)
- [ARK 4IN1 ESC](esc/ark_4in1_esc.md)
- [Holybro Kotleta](dronecan/holybro_kotleta.md)
- [Vertiq Motor/ESC Modules](peripherals/vertiq.md)
- [VESC Project ESCs](peripherals/vesc.md)
- [Zubax Telega ESCs](dronecan/zubax_telega.md)
- [Radio Control (RC)](getting_started/rc_transmitter_receiver.md)
- [무선 조종기 설정](config/radio.md)
@@ -519,6 +521,7 @@
- [PPS Time Synchronization](advanced/pps_time_sync.md)
- [미들웨어](middleware/index.md)
- [uORB 메시지 전송](middleware/uorb.md)
- [uORB Docs Standard](uorb/uorb_documentation.md)
- [uORB 그라프](middleware/uorb_graph.md)
- [uORB Message Reference](msg_docs/index.md)
- [Versioned](msg_docs/versioned_messages.md)
@@ -581,6 +584,7 @@
- [DebugKeyValue](msg_docs/DebugKeyValue.md)
- [DebugValue](msg_docs/DebugValue.md)
- [DebugVect](msg_docs/DebugVect.md)
- [DeviceInformation](msg_docs/DeviceInformation.md)
- [DifferentialPressure](msg_docs/DifferentialPressure.md)
- [DistanceSensor](msg_docs/DistanceSensor.md)
- [DistanceSensorModeChangeRequest](msg_docs/DistanceSensorModeChangeRequest.md)
docs/ko/advanced_config/ethernet_setup.md
+1
View File
@@ -25,6 +25,7 @@ It may also be supported on other boards.
Supported flight controllers include:
- [ARK Electronics ARKV6X](../flight_controller/ark_v6x.md)
- [CUAV Pixhawk V6X](../flight_controller/cuav_pixhawk_v6x.md)
- [Holybro Pixhawk 5X](../flight_controller/pixhawk5x.md)
- [Holybro Pixhawk 6X](../flight_controller/pixhawk6x.md)
docs/ko/assembly/_assembly.md
+1 -2
View File
@@ -285,7 +285,7 @@ A particular vehicle might have more/fewer motors and actuators, but the wiring
The following sections explain each part in more detail.
:::tip
If you're using [DroneCAN ESC](../peripherals/esc_motors.md#dronecan) the control signals will be connected to the CAN BUS instead of the PWM outputs as shown.
If you're using [DroneCAN ESC](../dronecan/escs.md) the control signals will be connected to the CAN BUS instead of the PWM outputs as shown.
:::
### Flight Controller Power
@@ -426,7 +426,6 @@ They recommend sensors, power systems, and other components from the same manufa
- [Drone Components & Parts](../getting_started/px4_basic_concepts.md#drone-components-parts) (Basic Concepts)
- [Payloads](../getting_started/px4_basic_concepts.md#payloads) (Basic Concepts)
- [Hardware Selection & Setup](../hardware/drone_parts.md) — information about connecting and configuring specific flight controllers, sensors and other peripherals (e.g. airspeed sensor for planes).
- [Mounting the Flight Controller](../assembly/mount_and_orient_controller.md)
- [Vibration Isolation](../assembly/vibration_isolation.md)
- [Mounting a Compass](../assembly/mount_gps_compass.md)
docs/ko/can/index.md
+42 -6
View File
@@ -1,7 +1,13 @@
# CAN
# CAN (DroneCAN & Cyphal)
[Controller Area Network (CAN)](https://en.wikipedia.org/wiki/CAN_bus) is a robust wired network that allows drone components such as flight controller, ESCs, sensors, and other peripherals, to communicate with each other.
Because it is designed to be democratic and uses differential signaling, it is very robust even over longer cable lengths (on large vehicles), and avoids a single point of failure.
It is particularly recommended on larger vehicles.
## 개요
CAN it is designed to be democratic and uses differential signaling.
For this reason it is very robust even over longer cable lengths (on large vehicles), and avoids a single point of failure.
CAN also allows status feedback from peripherals and convenient firmware upgrades over the bus.
PX4 supports two software protocols for communicating with CAN devices:
@@ -18,29 +24,36 @@ In 2022 the project split into two: the original version of UAVCAN (UAVCAN v0) w
The differences between the two protocols are outlined in [Cyphal vs. DroneCAN](https://forum.opencyphal.org/t/cyphal-vs-dronecan/1814).
:::
:::warning
PX4 does not support other CAN software protocols for drones such as KDECAN (at time of writing).
:::
## 배선
The wiring for CAN networks is the same for both DroneCAN and Cyphal/CAN (in fact, for all CAN networks).
Devices are connected in a chain in any order.
Devices within a network are connected in a _daisy-chain_ in any order (this differs from UARTs peripherals, where you attach just one component per port).
:::warning
Don't connect each CAN peripheral to a separate CAN port!
Unlike UARTs, CAN peripherals are designed to be daisy chained, with additional ports such as `CAN2` used for [redundancy](redundancy).
:::
At either end of the chain, a 120Ω termination resistor should be connected between the two data lines.
Flight controllers and some GNSS modules have built in termination resistors for convenience, thus should be placed at opposite ends of the chain.
Otherwise, you can use a termination resistor such as [this one from Zubax Robotics](https://shop.zubax.com/products/uavcan-micro-termination-plug?variant=6007985111069), or solder one yourself if you have access to a JST-GH crimper.
The following diagram shows an example of a CAN bus connecting a flight controller to 4 CAN ESCs and a GNSS.
It includes a redundant bus connected to `CAN 2`.
![CAN Wiring](../../assets/can/uavcan_wiring.svg)
The diagram does not show any power wiring.
Refer to your manufacturer instructions to confirm whether components require separate power or can be powered from the CAN bus itself.
:::info
For more information, see [Cyphal/CAN device interconnection](https://wiki.zubax.com/public/cyphal/CyphalCAN-device-interconnection?pageId=2195476) (kb.zubax.com).
While the article is written with the Cyphal protocol in mind, it applies equally to DroneCAN hardware and any other CAN setup.
For more advanced scenarios, consult with [On CAN bus topology and termination](https://forum.opencyphal.org/t/on-can-bus-topology-and-termination/1685).
:::
### 커넥터
@@ -54,7 +67,30 @@ However, as long as the device firmware supports DroneCAN or Cyphal, it can be u
DroneCAN and Cyphal/CAN support using a second (redundant) CAN interface.
This is completely optional but increases the robustness of the connection.
All Pixhawk flight controllers come with 2 CAN interfaces; if your peripherals support 2 CAN interfaces as well, it is recommended to wire both up for increased safety.
Pixhawk flight controllers come with 2 CAN interfaces; if your peripherals support 2 CAN interfaces as well, it is recommended to wire both up for increased safety.
### Flight Controllers with Multiple CAN Ports
[Flight Controllers](../flight_controller/index.md) may have up to three independent CAN ports, such as `CAN1`, `CAN2`, `CAN3` (neither DroneCAN or Cyphal support more than three).
Note that you can't have both DroneCAN and Cyphal running on PX4 at the same time.
:::tip
You only _need_ one CAN port to support an arbitrary number of CAN devices using a particular CAN protocol.
Don't connect each CAN peripheral to a separate CAN port!
:::
Generally you'll daisy all CAN peripherals off a single port, and if there is more than one CAN port, use the second one for [redundancy](redundancy).
If three are three ports, you might use the remaining network for devices that support another CAN protocol.
The documentation for your flight controller should indicate which ports are supported/enabled.
At runtime you can check what DroneCAN ports are enabled and their status using the following command on the [MAVLink Shell](../debug/mavlink_shell.md) (or some other console):
```sh
uavcan status
```
Note that you can also check the number of supported CAN interfaces for a board by searching for `CONFIG_BOARD_UAVCAN_INTERFACES` in its [default.px4board](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6xrt/default.px4board#) configuration file.
## 펌웨어
docs/ko/config_mc/filter_tuning.md
+1 -1
View File
@@ -70,7 +70,7 @@ Airframes with more than two frequency noise spikes typically clean the first tw
Dynamic notch filters use ESC RPM feedback and/or the onboard FFT analysis.
The ESC RPM feedback is used to track the rotor blade pass frequency and its harmonics, while the FFT analysis can be used to track a frequency of another vibration source, such as a fuel engine.
ESC RPM feedback requires ESCs capable of providing RPM feedback such as [DShot](../peripherals/esc_motors.md#dshot) with telemetry connected, a bidirectional DShot set up ([work in progress](https://github.com/PX4/PX4-Autopilot/pull/23863)), or [UAVCAN/DroneCAN ESCs](../dronecan/escs.md).
ESC RPM feedback requires ESCs capable of providing RPM feedback such as [DShot](../peripherals/dshot.md) with telemetry connected, a bidirectional DShot set up ([work in progress](https://github.com/PX4/PX4-Autopilot/pull/23863)), or [UAVCAN/DroneCAN ESCs](../dronecan/escs.md).
Before enabling, make sure that the ESC RPM is correct.
You might have to adjust the [pole count of the motors](../advanced_config/parameter_reference.md#MOT_POLE_COUNT).
docs/ko/dronecan/ark_flow.md
+1
View File
@@ -94,6 +94,7 @@ Set the following parameters in _QGroundControl_:
- To optionally disable GPS aiding, set [EKF2_GPS_CTRL](../advanced_config/parameter_reference.md#EKF2_GPS_CTRL) to `0`.
- Enable [UAVCAN_SUB_FLOW](../advanced_config/parameter_reference.md#UAVCAN_SUB_FLOW).
- Enable [UAVCAN_SUB_RNG](../advanced_config/parameter_reference.md#UAVCAN_SUB_RNG).
- Set [EKF2_RNG_CTRL](../advanced_config/parameter_reference.md#EKF2_RNG_CTRL) to `1`.
- Set [EKF2_RNG_A_HMAX](../advanced_config/parameter_reference.md#EKF2_RNG_A_HMAX) to `10`.
- Set [EKF2_RNG_QLTY_T](../advanced_config/parameter_reference.md#EKF2_RNG_QLTY_T) to `0.2`.
- Set [UAVCAN_RNG_MIN](../advanced_config/parameter_reference.md#UAVCAN_RNG_MIN) to `0.08`.
docs/ko/dronecan/ark_flow_mr.md
+1
View File
@@ -91,6 +91,7 @@ Set the following parameters in _QGroundControl_:
- To optionally disable GPS aiding, set [EKF2_GPS_CTRL](../advanced_config/parameter_reference.md#EKF2_GPS_CTRL) to `0`.
- Enable [UAVCAN_SUB_FLOW](../advanced_config/parameter_reference.md#UAVCAN_SUB_FLOW).
- Enable [UAVCAN_SUB_RNG](../advanced_config/parameter_reference.md#UAVCAN_SUB_RNG).
- Set [EKF2_RNG_CTRL](../advanced_config/parameter_reference.md#EKF2_RNG_CTRL) to `1`.
- Set [EKF2_RNG_A_HMAX](../advanced_config/parameter_reference.md#EKF2_RNG_A_HMAX) to `10`.
- Set [EKF2_RNG_QLTY_T](../advanced_config/parameter_reference.md#EKF2_RNG_QLTY_T) to `0.2`.
- Set [UAVCAN_RNG_MIN](../advanced_config/parameter_reference.md#UAVCAN_RNG_MIN) to `0.08`.
docs/ko/dronecan/escs.md
+8 -1
View File
@@ -1,7 +1,14 @@
# DroneCAN ESCs
PX4 supports DroneCAN compliant ESCs.
For more information, see the following articles for specific hardware/firmware:
## Supported ESC
:::info
[Supported ESCs](../peripherals/esc_motors#supported-esc) in _ESCs & Motors_ may include additional devices that are not listed below.
:::
The following articles have specific hardware/firmware information:
- [PX4 Sapog ESC Firmware](sapog.md)
- [Holybro Kotleta 20](holybro_kotleta.md)
docs/ko/esc/ark_4in1_esc.md
+65
View File
@@ -0,0 +1,65 @@
# ARK 4IN1 ESC (with/without Connectors)
4 in 1 Electronic Speed Controller (ESC) that is made in the USA, NDAA compliant, and DIU Blue Framework listed.
The ESC comes in variants without connectors that you can solder in place, and a variant that has built-in motor and battery connectors (no soldering required).
![ARK 4IN1 ESC without connectors ](../../assets/hardware/esc/ark/ark_4_in_1_esc.jpg)![ARK 4IN1 ESC with connectors](../../assets/hardware/esc/ark/ark_4_in_1_esc_with_connectors.jpg)
## 구매처
Order this module from:
- [4IN1 ESC (with connectors)](https://arkelectron.com/product/ark-4in1-esc/) (ARK Electronics - US)
- [ARK Electronics (without connectors)](https://arkelectron.com/product/ark-4in1-esc-cons/) (ARK Electronics US)
## Hardware Specifications
- Battery Voltage: 3-8s
- 6V Minimum
- 65V Absolute Maximum
- Current Rating: 50A Continuous, 75A Burst Per Motor
- [STM32F0](https://www.st.com/en/microcontrollers-microprocessors/stm32f0-series.html)
- [AM32 Firmware](https://github.com/am32-firmware/AM32/pull/27)
- Onboard Current Sensor, Serial Telemetry
- 100V/A
- Input Protocols
- DShot (300, 600)
- Bi-directional DShot
- KISS Serial Telemetry
- PWM
- 8 Pin JST-SH Input/Output
- 10 Pin JST-SH Debug
- Motor & Battery Connectors (with-connector version)
- MR30 Connector Limit Per Motor: 30A Continuous, 40A Burst
- Four MR30 Motor Connectors
- Dimensions (with connectors)
- Size: 77.00mm x 42.00mm x 9.43mm
- Mounting Pattern: 30.5mm
- Weight: 24g
- Dimensions (without connectors)
- Size: 43.00mm x 40.50mm x 7.60mm
- Mounting Pattern: 30.5mm
- Weight: 14.5g
Other
- Made in the USA
- Open source AM32 firmware
- [DIU Blue Framework Listed](https://www.diu.mil/blue-uas/framework)
## See Also
- [ARK 4IN1 ESC CONS](https://docs.arkelectron.com/electronic-speed-controller/ark-4in1-esc) (ARK Docs)
docs/ko/esc/esc_protocols.md
+66
View File
@@ -0,0 +1,66 @@
# ESC Protocols
This topic lists the main [Electronic Speed Controller (ESC)](../peripherals/esc_motors.md) protocols supported by PX4.
## DShot
[DShot](../peripherals/dshot.md) is a digital ESC protocol that is highly recommended for vehicles that can benefit from reduced latency, in particular racing multicopters, VTOL vehicles, and so on.
It has reduced latency and is more robust than both [PWM](#pwm) and [OneShot](#oneshot-125).
In addition it does not require ESC calibration, telemetry is available from some ESCs, and you can reverse motor spin directions.
PX4 configuration is done in the [Actuator Configuration](../config/actuators.md).
Selecting a higher rate DShot ESC in the UI results in lower latency, but lower rates are more robust (and hence more suitable for large aircraft with longer leads); some ESCs only support lower rates (see datasheets for information).
Setup:
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
- [DShot](../peripherals/dshot.md) also contains information about how to send commands etc.
## DroneCAN
[DroneCAN ESCs](../dronecan/escs.md) are recommended when DroneCAN is the primary bus used for your vehicle.
The PX4 implementation is currently limited to update rates of 200 Hz.
DroneCAN shares many similar benefits to [DShot](#dshot) including high data rates, robust connection over long leads, telemetry feedback, no need for calibration of the ESC itself.
[DroneCAN ESCs](../dronecan/escs.md) are connected via the DroneCAN bus (setup and configuration are covered at that link).
## PWM
[PWM ESCs](../peripherals/pwm_escs_and_servo.md) are commonly used for fixed-wing vehicles and ground vehicles (vehicles that require a lower latency like multicopters typically use oneshot or dshot ESCs).
PWM ESCs communicate using a periodic pulse, where the _width_ of the pulse indicates the desired speed.
The pulse width typically ranges between 1000 μs for zero power and 2000 μs for full power.
The periodic frame rate of the signal depends on the capability of the ESC, and commonly ranges between 50 Hz and 490 Hz (the theoretical maximum being 500 Hz for a very small "off" cycle).
A higher rate is better for ESCs, in particular where a rapid response to setpoint changes is needed.
For PWM servos 50 Hz is usually sufficient, and many don't support higher rates.
![duty cycle for PWM](../../assets/peripherals/esc_pwm_duty_cycle.png)
In addition to being a relatively slow protocol PWM ESCs require [calibration](../advanced_config/esc_calibration.md) because the pulse widths representing low and high values can vary significantly.
Unlike [DShot](#dshot) and [DroneCAN ESC](#dronecan) they do not have the ability to provide telemetry and feedback on ESC (or servo) state.
Setup:
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md)
- [PX4 Configuration](../peripherals/pwm_escs_and_servo.md#px4-configuration)
- [ESC Calibration](../advanced_config/esc_calibration.md)
## OneShot 125
[OneShot 125 ESCs](../peripherals/oneshot.md) are usually much faster than PWM ESCs, and hence more responsive and easier to tune.
They are preferred over PWM for multicopters (but not as much as [DShot ESCs](#dshot), which do not require calibration, and may provide telemetry feedback).
There are a number of variants of the OneShot protocol, which support different rates.
PX4 only supports OneShot 125.
OneShot 125 is the same as PWM but uses pulse widths that are 8 times shorter (from 125 μs to 250 μs for zero to full power).
This allows OneShot 125 ESCs to have a much shorter duty cycle/higher rate.
For PWM the theoretical maximum is close to 500 Hz while for OneShot it approaches 4 kHz.
The actual supported rate depends on the ESC used.
Setup:
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
- [PX4 Configuration](../peripherals/oneshot.md#px4-configuration)
- [ESC Calibration](../advanced_config/esc_calibration.md)
docs/ko/middleware/uorb.md
+2
View File
@@ -280,6 +280,8 @@ For more information see: [Plotting uORB Topic Data in Real Time using PlotJuggl
## See Also
- [uORB Documentation Standard](../uorb/uorb_documentation.md)
- _PX4 uORB Explained_ Blog series
- [Part 1](https://px4.io/px4-uorb-explained-part-1/)
- [Part 2](https://px4.io/px4-uorb-explained-part-2/)
docs/ko/modules/modules_driver.md
+34 -34
View File
@@ -15,38 +15,6 @@
- [Rpm Sensor](modules_driver_rpm_sensor.md)
- [Transponder](modules_driver_transponder.md)
## MCP23009
Source: [drivers/gpio/mcp23009](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/gpio/mcp23009)
### Usage {#MCP23009_usage}
```
MCP23009 <command> [arguments...]
Commands:
start
[-I] Internal I2C bus(es)
[-X] External I2C bus(es)
[-b <val>] board-specific bus (default=all) (external SPI: n-th bus
(default=1))
[-f <val>] bus frequency in kHz
[-q] quiet startup (no message if no device found)
[-a <val>] I2C address
default: 37
[-D <val>] Direction
default: 0
[-O <val>] Output
default: 0
[-P <val>] Pullups
default: 0
[-U <val>] Update Interval [ms]
default: 0
stop
status print status info
```
## atxxxx
Source: [drivers/osd/atxxxx](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/osd/atxxxx)
@@ -749,6 +717,40 @@ lsm303agr <command> [arguments...]
status print status info
```
## mcp230xx
Source: [lib/drivers/mcp_common](https://github.com/PX4/PX4-Autopilot/tree/main/src/lib/drivers/mcp_common)
### Usage {#mcp230xx_usage}
```
mcp230xx <command> [arguments...]
Commands:
start
[-I] Internal I2C bus(es)
[-X] External I2C bus(es)
[-b <val>] board-specific bus (default=all) (external SPI: n-th bus
(default=1))
[-f <val>] bus frequency in kHz
[-q] quiet startup (no message if no device found)
[-a <val>] I2C address
default: 39
[-D <val>] Direction (1=Input, 0=Output)
default: 0
[-O <val>] Output
default: 0
[-P <val>] Pullups
default: 0
[-U <val>] Update Interval [ms]
default: 0
[-M <val>] First minor number
default: 0
stop
status print status info
```
## mcp9808
Source: [drivers/temperature_sensor/mcp9808](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/temperature_sensor/mcp9808)
@@ -899,8 +901,6 @@ fetching the latest mixing result and write them to PCA9685 at its scheduling ti
It can do full 12bits output as duty-cycle mode, while also able to output precious pulse width
that can be accepted by most ESCs and servos.
The I2C bus and address can be configured via parameters `PCA9685_EN_BUS` and `PCA9685_I2C_ADDR`, or via command line arguments.
### 예
It is typically started with:
docs/ko/modules/modules_system.md
+4
View File
@@ -127,6 +127,10 @@ commander <command> [arguments...]
check Run preflight checks
safety Change prearm safety state
on|off [on] to activate safety, [off] to deactivate safety and allow
control surface movements
arm
[-f] Force arming (do not run preflight checks)
docs/ko/msg_docs/BatteryStatus.md
+5 -5
View File
@@ -2,7 +2,7 @@
Battery status
Battery status information for up to 4 battery instances.
Battery status information for up to 3 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.
@@ -11,7 +11,7 @@ Battery instance information is also logged and streamed in MAVLink telemetry.
```c
# Battery status
#
# Battery status information for up to 4 battery instances.
# Battery status information for up to 3 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.
@@ -33,9 +33,9 @@ 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 SOURCE_POWER_MODULE = 0 # Power module (analog ADC or I2C power monitor)
uint8 SOURCE_EXTERNAL = 1 # External (MAVLink, CAN, or external driver)
uint8 SOURCE_ESCS = 2 # ESCs (via ESC telemetry)
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
docs/ko/msg_docs/BatteryStatusV0.md
+3 -3
View File
@@ -32,9 +32,9 @@ 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 SOURCE_POWER_MODULE = 0 # Power module (analog ADC or I2C power monitor)
uint8 SOURCE_EXTERNAL = 1 # External (MAVLink, CAN, or external driver)
uint8 SOURCE_ESCS = 2 # ESCs (via ESC telemetry)
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
docs/ko/msg_docs/DeviceInformation.md
+45
View File
@@ -0,0 +1,45 @@
# DeviceInformation (UORB message)
Device information
Can be used to uniquely associate a device_id from a sensor topic with a physical device using serial number.
as well as tracking of the used firmware versions on the devices.
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/DeviceInformation.msg)
```c
# Device information
#
# Can be used to uniquely associate a device_id from a sensor topic with a physical device using serial number.
# as well as tracking of the used firmware versions on the devices.
uint64 timestamp # time since system start (microseconds)
uint8 device_type # [@enum DEVICE_TYPE] Type of the device. Matches MAVLink DEVICE_TYPE enum
uint8 DEVICE_TYPE_GENERIC = 0 # Generic/unknown sensor
uint8 DEVICE_TYPE_AIRSPEED = 1 # Airspeed sensor
uint8 DEVICE_TYPE_ESC = 2 # ESC
uint8 DEVICE_TYPE_SERVO = 3 # Servo
uint8 DEVICE_TYPE_GPS = 4 # GPS
uint8 DEVICE_TYPE_MAGNETOMETER = 5 # Magnetometer
uint8 DEVICE_TYPE_PARACHUTE = 6 # Parachute
uint8 DEVICE_TYPE_RANGEFINDER = 7 # Rangefinder
uint8 DEVICE_TYPE_WINCH = 8 # Winch
uint8 DEVICE_TYPE_BAROMETER = 9 # Barometer
uint8 DEVICE_TYPE_OPTICAL_FLOW = 10 # Optical flow
uint8 DEVICE_TYPE_ACCELEROMETER = 11 # Accelerometer
uint8 DEVICE_TYPE_GYROSCOPE = 12 # Gyroscope
uint8 DEVICE_TYPE_DIFFERENTIAL_PRESSURE = 13 # Differential pressure
uint8 DEVICE_TYPE_BATTERY = 14 # Battery
uint8 DEVICE_TYPE_HYGROMETER = 15 # Hygrometer
char[32] vendor_name # Name of the device vendor
char[32] model_name # Name of the device model
uint32 device_id # [-] [@invalid 0 if not available] Unique device ID for the sensor. Does not change between power cycles.
char[24] firmware_version # [-] [@invalid empty if not available] Firmware version.
char[24] hardware_version # [-] [@invalid empty if not available] Hardware version.
char[33] serial_number # [-] [@invalid empty if not available] Device serial number or unique identifier.
```
docs/ko/msg_docs/EstimatorStatus.md
+1
View File
@@ -21,6 +21,7 @@ uint8 GPS_CHECK_FAIL_MAX_VERT_DRIFT = 7 # 7 : maximum allowed vertical position
uint8 GPS_CHECK_FAIL_MAX_HORZ_SPD_ERR = 8 # 8 : maximum allowed horizontal speed fail - requires stationary vehicle
uint8 GPS_CHECK_FAIL_MAX_VERT_SPD_ERR = 9 # 9 : maximum allowed vertical velocity discrepancy fail
uint8 GPS_CHECK_FAIL_SPOOFED = 10 # 10 : GPS signal is spoofed
uint8 GPS_CHECK_FAIL_JAMMED = 11 # 11 : GPS signal is jammed
uint64 control_mode_flags # Bitmask to indicate EKF logic state
uint8 CS_TILT_ALIGN = 0 # 0 - true if the filter tilt alignment is complete
docs/ko/msg_docs/GpioIn.md
+1
View File
@@ -6,6 +6,7 @@ GPIO mask and state
```c
# GPIO mask and state
uint8 MAX_INSTANCES = 8
uint64 timestamp # time since system start (microseconds)
uint32 device_id # Device id
docs/ko/msg_docs/GpsDump.md
+5 -1
View File
@@ -9,11 +9,15 @@ This message is used to dump the raw gps communication to the log.
uint64 timestamp # time since system start (microseconds)
uint8 INSTANCE_MAIN = 0
uint8 INSTANCE_SECONDARY = 1
uint8 instance # Instance of GNSS receiver
uint32 device_id
uint8 len # length of data, MSB bit set = message to the gps device,
# clear = message from the device
uint8[79] data # data to write to the log
uint8 ORB_QUEUE_LENGTH = 8
uint8 ORB_QUEUE_LENGTH = 16
```
docs/ko/msg_docs/VehicleCommand.md
+5
View File
@@ -108,6 +108,7 @@ uint16 VEHICLE_CMD_LOGGING_START = 2510 # Start streaming ULog data.
uint16 VEHICLE_CMD_LOGGING_STOP = 2511 # Stop streaming ULog data.
uint16 VEHICLE_CMD_CONTROL_HIGH_LATENCY = 2600 # Control starting/stopping transmitting data over the high latency link.
uint16 VEHICLE_CMD_DO_VTOL_TRANSITION = 3000 # Command VTOL transition.
uint16 VEHICLE_CMD_DO_SET_SAFETY_SWITCH_STATE = 5300 # Command safety on/off. |1 to activate safety, 0 to deactivate safety and allow control surface movements|Unused|Unused|Unused|Unused|Unused|Unused|
uint16 VEHICLE_CMD_ARM_AUTHORIZATION_REQUEST = 3001 # Request arm authorization.
uint16 VEHICLE_CMD_PAYLOAD_PREPARE_DEPLOY = 30001 # Prepare a payload deployment in the flight plan.
uint16 VEHICLE_CMD_PAYLOAD_CONTROL_DEPLOY = 30002 # Control a pre-programmed payload deployment.
@@ -187,6 +188,10 @@ int8 ARMING_ACTION_ARM = 1
uint8 GRIPPER_ACTION_RELEASE = 0
uint8 GRIPPER_ACTION_GRAB = 1
# Used as param1 in DO_SET_SAFETY_SWITCH_STATE command.
uint8 SAFETY_OFF = 0
uint8 SAFETY_ON = 1
uint8 ORB_QUEUE_LENGTH = 8
float32 param1 # Parameter 1, as defined by MAVLink uint16 VEHICLE_CMD enum.
docs/ko/msg_docs/index.md
+1
View File
@@ -105,6 +105,7 @@ Graphs showing how these are used [can be found here](../middleware/uorb_graph.m
- [DebugKeyValue](DebugKeyValue.md)
- [DebugValue](DebugValue.md)
- [DebugVect](DebugVect.md)
- [DeviceInformation](DeviceInformation.md) — Device information
- [DifferentialPressure](DifferentialPressure.md) — Differential-pressure (airspeed) sensor
- [DistanceSensor](DistanceSensor.md) — DISTANCE_SENSOR message data
- [DistanceSensorModeChangeRequest](DistanceSensorModeChangeRequest.md)
docs/ko/peripherals/dshot.md
+4
View File
@@ -11,6 +11,10 @@ DShot is an alternative ESC protocol that has several advantages over [PWM](../p
이 항목에서는 DShot ESC 연결과 설정 방법을 설명합니다.
## Supported ESC
[ESCs & Motors > Supported ESCs](../peripherals/esc_motors#supported-esc) has a list of supported ESC (check "Protocols" column for DShot ESC).
## Wiring/Connections {#wiring}
DShot ESC are wired the same way as [PWM ESCs](pwm_escs_and_servo.md).
docs/ko/peripherals/esc_motors.md
+32 -68
View File
@@ -3,80 +3,44 @@
Many PX4 drones use brushless motors that are driven by the flight controller via an Electronic Speed Controller (ESC).
The ESC takes a signal from the flight controller and uses it to set control the level of power delivered to the motor.
PX4 supports a number of common protocols for sending the signals to ESCs: [PWM ESCs](../peripherals/pwm_escs_and_servo.md), [OneShot ESCs](../peripherals/oneshot.md), [DShot ESCs](../peripherals/dshot.md), [DroneCAN ESCs](../dronecan/escs.md), PCA9685 ESC (via I2C), and some UART ESCs (from Yuneec).
PX4 supports a number of [common protocols](../esc/esc_protocols.md) for sending the signals to ESCs: [PWM ESCs](../peripherals/pwm_escs_and_servo.md), [OneShot ESCs](../peripherals/oneshot.md), [DShot ESCs](../peripherals/dshot.md), [DroneCAN ESCs](../dronecan/escs.md), PCA9685 ESC (via I2C), and some UART ESCs (from Yuneec).
## Supported ESC
The following list is non-exhaustive.
| ESC Device | Protocols | Firmwares | 참고 |
| ------------------------------ | ------------------------------------ | ------------------------ | ----------------------------------------------------- |
| [ARK 4IN1 ESC] | [Dshot], [PWM] | [AM32] | Has versions with/without connnectors |
| [Holybro Kotleta 20] | [DroneCAN], [PWM] | [PX4 Sapog ESC Firmware] | |
| [Vertiq Motor & ESC modules] | [Dshot], [OneShot], Multishot, [PWM] | Vertiq firmware | Larger modules support DroneCAN, ESC and Motor in one |
| [RaccoonLab CAN PWM ESC nodes] | [DroneCAN], Cyphal | | Cyphal and DroneCAN notes for PWM ESC |
| [VESC ESCs] | [DroneCAN], [PWM] | VESC project firmware | |
| [Zubax Telega] | [DroneCAN], [PWM] | Telega-based | ESC and Motor in one |
<!-- Links for table above -->
[ARK 4IN1 ESC]: ../esc/ark_4in1_esc.md
[AM32]: https://am32.ca/
[PX4 Sapog ESC Firmware]: ../dronecan/sapog.md
[VESC ESCs]: ../peripherals/vesc.md
[DroneCAN]: ../dronecan/escs.md
[Dshot]: ../peripherals/dshot.md
[OneShot]: ../peripherals/oneshot.md
[PWM]: ../peripherals/pwm_escs_and_servo.md
[Holybro Kotleta 20]: ../dronecan/holybro_kotleta.md
[Vertiq Motor & ESC modules]: ../peripherals/vertiq.md
[RaccoonLab CAN PWM ESC nodes]: ../dronecan/raccoonlab_nodes.md
[Zubax Telega]: ../dronecan/zubax_telega.md
## See Also
더 자세한 정보는 다음을 참고하십시오.
- [ESC Protocols](../esc/esc_protocols.md) — overview of main ESC/Servo protocols supported by PX4
- [PWM ESCs and Servos](../peripherals/pwm_escs_and_servo.md)
- [OneShot ESCs and Servos](../peripherals/oneshot.md)
- [DShot](../peripherals/dshot.md)
- [DroneCAN ESCs](../dronecan/escs.md)
- [ESC Calibration](../advanced_config/esc_calibration.md)
- [ESC Firmware and Protocols Overview](https://oscarliang.com/esc-firmware-protocols/) (oscarliang.com)
A high level overview of the main ESC/Servo protocols supported by PX4 is given below.
## ESC Protocols
### PWM
[PWM ESCs](../peripherals/pwm_escs_and_servo.md) are commonly used for fixed-wing vehicles and ground vehicles (vehicles that require a lower latency like multicopters typically use oneshot or dshot ESCs).
PWM ESCs communicate using a periodic pulse, where the _width_ of the pulse indicates the desired power level.
The pulse wdith typically ranges between 1000uS for zero power and 2000uS for full power.
The periodic frame rate of the signal depends on the capability of the ESC, and commonly ranges between 50Hz and 490 Hz (the theoretical maximum being 500Hz for a very small "off" cycle).
A higher rate is better for ESCs, in particular where a rapid response to setpoint changes is needed.
For PWM servos 50Hz is usually sufficient, and many don't support higher rates.
![duty cycle for PWM](../../assets/peripherals/esc_pwm_duty_cycle.png)
In addition to being a relatively slow protocol PWM ESCs require [calibration](../advanced_config/esc_calibration.md) because the range values representing low and high values can vary significantly.
Unlike [dshot](#dshot) and [DroneCAN ESC](#dronecan) they do not have the ability to provide telemetry and feedback on ESC (or servo) state.
Setup:
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md)
- [PX4 Configuration](../peripherals/pwm_escs_and_servo.md#px4-configuration)
- [ESC Calibration](../advanced_config/esc_calibration.md)
### Oneshot 125
[OneShot 125 ESCs](../peripherals/oneshot.md) are usually much faster than PWM ESCs, and hence more responsive and easier to tune.
They are preferred over PWM for multicopters (but not as much as [DShot ESCs](#dshot), which do not require calibration, and may provide telemetry feedback).
There are a number of variants of the OneShot protocol, which support different rates.
PX4 only supports OneShot 125.
OneShot 125 is the same as PWM but uses pulse widths that are 8 times shorter (from 125us to 250us for zero to full power).
This allows OneShot 125 ESCs to have a much shorter duty cycle/higher rate.
For PWM the theoretical maximum is close to 500 Hz while for OneShot it approaches 4 kHz.
The actual supported rate depends on the ESC used.
Setup:
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
- [PX4 Configuration](../peripherals/oneshot.md#px4-configuration)
- [ESC Calibration](../advanced_config/esc_calibration.md)
### DShot
[DShot](../peripherals/dshot.md) is a digital ESC protocol that is highly recommended for vehicles that can benefit from reduce latency, in particular racing multicopters, VTOL vehicles, and so on.
It has reduced latency and is more robust than both [PWM](#pwm) and [OneShot](#oneshot-125).
In addition it does not require ESC calibration, telemetry is available from some ESCs, and you can revers motor spin directions
PX4 configuration is done in the [Actuator Configuration](../config/actuators.md).
Selecting a higher rate DShot ESC in the UI result in lower latency, but lower rates are more robust (and hence more suitable for large aircraft with longer leads); some ESCs only support lower rates (see datasheets for information).
Setup:
- [ESC Wiring](../peripherals/pwm_escs_and_servo.md) (same as for PWM ESCs)
- [DShot](../peripherals/dshot.md) also contains information about how to send commands etc.
### DroneCAN
[DroneCAN ESCs](../dronecan/escs.md) are recommended when DroneCAN is the primary bus used for your vehicle.
The PX4 implementation is currently limited to update rates of 200Hz.
DroneCAN shares many similar benefits to [Dshot](#dshot) including high data rates, robust connection over long leads, telemetry feedback, no need for calibration of the ESC itself.
[DroneCAN ESCs](../dronecan/escs.md) are connected via the DroneCAN bus (setup and configuration are covered at that link).
docs/ko/uorb/uorb_documentation.md
+170
View File
@@ -0,0 +1,170 @@
# uORB Documentation Standard
This topic demonstrates and explains how to document uORB messages.
:::info
At time of writing many topics have not been updated.
:::
## 개요
The [AirspeedValidated](../msg_docs/AirspeedValidated.md) message shown below is a good example of a uORB topic that has been documented to the current standard.
```py
# Validated airspeed
#
# Provides information about airspeed (indicated, true, calibrated) and the source of the data.
# Used by controllers, estimators and for airspeed reporting to operator.
uint32 MESSAGE_VERSION = 1
uint64 timestamp # [us] Time since system start
float32 indicated_airspeed_m_s # [m/s] [@invalid NaN] Indicated airspeed (IAS)
float32 calibrated_airspeed_m_s # [m/s] [@invalid NaN] Calibrated airspeed (CAS)
float32 true_airspeed_m_s # [m/s] [@invalid NaN] True airspeed (TAS)
int8 airspeed_source # [@enum SOURCE] Source of currently published airspeed values
int8 SOURCE_DISABLED = -1 # Disabled
int8 SOURCE_GROUND_MINUS_WIND = 0 # Ground speed minus wind
int8 SOURCE_SENSOR_1 = 1 # Sensor 1
int8 SOURCE_SENSOR_2 = 2 # Sensor 2
int8 SOURCE_SENSOR_3 = 3 # Sensor 3
int8 SOURCE_SYNTHETIC = 4 # Synthetic airspeed
float32 calibrated_ground_minus_wind_m_s # [m/s] [@invalid NaN] CAS calculated from groundspeed - windspeed, where windspeed is estimated based on a zero-sideslip assumption
float32 calibraded_airspeed_synth_m_s # [m/s] [@invalid NaN] Synthetic airspeed
float32 airspeed_derivative_filtered # [m/s^2] Filtered indicated airspeed derivative
float32 throttle_filtered # [-] Filtered fixed-wing throttle
float32 pitch_filtered # [rad] Filtered pitch
```
The main things to note are:
- Documentation is added using formatted uORB comments.
Any text on a line after the `#` character is a comment, except for lines that start with the text `# TOPIC` (which indicates a multi-topic message).
- The message starts with a comment block consisting of short description (mandatory), followed by a longer description and then a space.
- Field and constants almost all have comments.
The comments are added on the same line as the field/constant, separated by one space.
- Fields:
- Comments are all on the same line as the field (extra lines become internal comments).
- Comments start with metadata, such as the units (`[m/s]`, `[rad/s]`) or allowed values (`[@enum SOURCE]`), and can also list invalid values (`[@invalid NaN]`) and allowed ranges (`[@range min, max]`).
- Units are required except for boolean fields or for fields with an enum value.
`[-]` is used to indicate unitless fields.
- Comments follow the metadata after a space.
The line should not be terminated in a full stop.
- Constants:
- Don't have metadata: the description follows the comment marker after one space.
- Some constants, such as `MESSAGE_VERSION`, don't need documentation because they are standardized.
- Constants with the same name prefix are grouped together as enums after the associated field.
The following sections expand on the allowed formats.
## Message Description
Every message should start with a comment block that describes the message:
```py
# Short description (mandatory)
#
# Longer description for the message if needed.
# Can be multiline, and should have punctuation.
# Should be followed by an empty line.
```
This consists of a mandatory short description, optionally followed by an empty comment line, and then a longer description.
Short description (mandatory):
- A succinct explanation for the purpose of the message.
- Usually just one line without a terminating full stop.
- Minimally it may just mirror the message name.
- For example, [`AirspeedValidated`](../msg_docs/AirspeedValidated.md) above has the short description `Validated airspeed`.
Long description (Optional):
- Additional context required to understand how the message is used.
- In particular this should be anything that can't be inferred from the name, fields or constants, such as the publishers and expected consumers.
It might also cover whether the message is only used for a particular frame type or mode.
- The message is often multiline and contains punctuation.
- May include comment lines that are empty, in order to indicate paragraphs.
Both short and long descriptions may be multi-line.
Single line descriptions should not include a terminating full stop, but multiline comments should do so.
The message description block ends at the first non-comment line, which should be an empty line, but might be a field or constant.
Any subsequent comment lines are considered "internal comments".
### Fields
A typical field comment looks like this:
```py
float32 indicated_airspeed_m_s # [m/s] [@invalid NaN] Indicated airspeed (IAS)
```
Field comments must all be on the same line as the field, and consist of optional metadata followed by 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), such as `[m]` for metres.
- Allowed units include: `m`, `m/s`, `m/s^2`, `rad`, `rad/s`, `rpm`, `V`, `A`, `mA`, `mAh`, `W`, `dBm`, `s`, `ms`, `us`, `Ohm`, `MB`, `Kb/s`, `degC`, `Pa`.
- Units are required unless clearly invalid, such as when the field is a boolean, or is an enum value.
- Unitless values should be specified as `[-]`.
Note though that units are not required for boolean fields or enum fields.
- `[@enum <enum_name>]`
- The `enum_name` gives the prefix of constant values in the message that can be assigned to the field.
Note that enums in uORB are just a naming convention: they are not explicitly declared.
Multiple enum names allowed for a field indicates 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, such as `[@invalid NaN]`.
The `description` is optional, and might be used to indicate the conditions under which data is invalid.
- `[@frame <value>]`
- The `frame` in which the field is set, such as `[@frame NED]` or `[@frame Body]`.
- `description`
- A concise description of the purpose of the field, 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.
### Constants
Constants follow the documentation conventions as fields except they only have a description (no metadata).
Documentation for a constant might look like this:
```py
int8 SOURCE_GROUND_MINUS_WIND = 0 # Ground speed minus wind
```
Constants are often grouped together following a field as enum values.
Note below how the prefix `SOURCE` for the values is specified as an enum against the _field_.
```py
int8 airspeed_source # [@enum SOURCE] Source of currently published airspeed values
int8 SOURCE_DISABLED = -1 # Disabled
int8 SOURCE_GROUND_MINUS_WIND = 0 # Ground speed minus wind
...
```
A small number of constants have a standardised meaning and do not require documentation.
These are:
- `ORB_QUEUE_LENGTH`
- `MESSAGE_VERSION`
### `# TOPICS`
The prefix `# TOPICS` is used to indicate topic names for multi-topic messages.
For example, the [VehicleGlobalPosition.msg](../msg_docs/VehicleGlobalPosition.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
```
At time of writing there is no format for documenting these.
docs/uk/SUMMARY.md
+1
View File
@@ -584,6 +584,7 @@
- [DebugKeyValue](msg_docs/DebugKeyValue.md)
- [DebugValue](msg_docs/DebugValue.md)
- [DebugVect](msg_docs/DebugVect.md)
- [DeviceInformation](msg_docs/DeviceInformation.md)
- [DifferentialPressure](msg_docs/DifferentialPressure.md)
- [DistanceSensor](msg_docs/DistanceSensor.md)
- [DistanceSensorModeChangeRequest](msg_docs/DistanceSensorModeChangeRequest.md)
docs/uk/advanced_config/ethernet_setup.md
+1
View File
@@ -25,6 +25,7 @@ PX4 supports Ethernet connectivity on [Pixhawk 5X-standard](https://github.com/p
Підтримувані автопілоти включають:
- [ARK Electronics ARKV6X](../flight_controller/ark_v6x.md)
- [CUAV Pixhawk V6X](../flight_controller/cuav_pixhawk_v6x.md)
- [Holybro Pixhawk 5X](../flight_controller/pixhawk5x.md)
- [Holybro Pixhawk 6X](../flight_controller/pixhawk6x.md)
docs/uk/assembly/_assembly.md
+1 -2
View File
@@ -285,7 +285,7 @@ A particular vehicle might have more/fewer motors and actuators, but the wiring
The following sections explain each part in more detail.
:::tip
If you're using [DroneCAN ESC](../peripherals/esc_motors.md#dronecan) the control signals will be connected to the CAN BUS instead of the PWM outputs as shown.
If you're using [DroneCAN ESC](../dronecan/escs.md) the control signals will be connected to the CAN BUS instead of the PWM outputs as shown.
:::
### Flight Controller Power
@@ -426,7 +426,6 @@ They recommend sensors, power systems, and other components from the same manufa
- [Drone Components & Parts](../getting_started/px4_basic_concepts.md#drone-components-parts) (Basic Concepts)
- [Payloads](../getting_started/px4_basic_concepts.md#payloads) (Basic Concepts)
- [Hardware Selection & Setup](../hardware/drone_parts.md) — information about connecting and configuring specific flight controllers, sensors and other peripherals (e.g. airspeed sensor for planes).
- [Mounting the Flight Controller](../assembly/mount_and_orient_controller.md)
- [Vibration Isolation](../assembly/vibration_isolation.md)
- [Mounting a Compass](../assembly/mount_gps_compass.md)
docs/uk/config_mc/filter_tuning.md
+1 -1
View File
@@ -70,7 +70,7 @@ Airframes with more than two frequency noise spikes typically clean the first tw
Dynamic notch filters use ESC RPM feedback and/or the onboard FFT analysis.
The ESC RPM feedback is used to track the rotor blade pass frequency and its harmonics, while the FFT analysis can be used to track a frequency of another vibration source, such as a fuel engine.
ESC RPM feedback requires ESCs capable of providing RPM feedback such as [DShot](../peripherals/esc_motors.md#dshot) with telemetry connected, a bidirectional DShot set up ([work in progress](https://github.com/PX4/PX4-Autopilot/pull/23863)), or [UAVCAN/DroneCAN ESCs](../dronecan/escs.md).
ESC RPM feedback requires ESCs capable of providing RPM feedback such as [DShot](../peripherals/dshot.md) with telemetry connected, a bidirectional DShot set up ([work in progress](https://github.com/PX4/PX4-Autopilot/pull/23863)), or [UAVCAN/DroneCAN ESCs](../dronecan/escs.md).
Before enabling, make sure that the ESC RPM is correct.
You might have to adjust the [pole count of the motors](../advanced_config/parameter_reference.md#MOT_POLE_COUNT).
docs/uk/dronecan/escs.md
+9 -2
View File
@@ -1,7 +1,14 @@
# DroneCAN ESCs
PX4 підтримує ESCs, які відповідають стандарту DroneCAN.
Для отримання додаткової інформації дивіться наступні статті для конкретного обладнання/прошивки:
PX4 supports DroneCAN compliant ESCs.
## Supported ESC
:::info
[Supported ESCs](../peripherals/esc_motors#supported-esc) in _ESCs & Motors_ may include additional devices that are not listed below.
:::
The following articles have specific hardware/firmware information:
- [PX4 Sapog ESC Firmware](sapog.md)
- [Holybro Kotleta 20](holybro_kotleta.md)
docs/uk/modules/modules_driver.md
+34 -34
View File
@@ -15,38 +15,6 @@
- [Rpm Sensor](modules_driver_rpm_sensor.md)
- [Transponder](modules_driver_transponder.md)
## MCP23009
Source: [drivers/gpio/mcp23009](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/gpio/mcp23009)
### Usage {#MCP23009_usage}
```
MCP23009 <command> [arguments...]
Commands:
start
[-I] Internal I2C bus(es)
[-X] External I2C bus(es)
[-b <val>] board-specific bus (default=all) (external SPI: n-th bus
(default=1))
[-f <val>] bus frequency in kHz
[-q] quiet startup (no message if no device found)
[-a <val>] I2C address
default: 37
[-D <val>] Direction
default: 0
[-O <val>] Output
default: 0
[-P <val>] Pullups
default: 0
[-U <val>] Update Interval [ms]
default: 0
stop
status print status info
```
## atxxxx
Source: [drivers/osd/atxxxx](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/osd/atxxxx)
@@ -749,6 +717,40 @@ lsm303agr <command> [arguments...]
status print status info
```
## mcp230xx
Source: [lib/drivers/mcp_common](https://github.com/PX4/PX4-Autopilot/tree/main/src/lib/drivers/mcp_common)
### Usage {#mcp230xx_usage}
```
mcp230xx <command> [arguments...]
Commands:
start
[-I] Internal I2C bus(es)
[-X] External I2C bus(es)
[-b <val>] board-specific bus (default=all) (external SPI: n-th bus
(default=1))
[-f <val>] bus frequency in kHz
[-q] quiet startup (no message if no device found)
[-a <val>] I2C address
default: 39
[-D <val>] Direction (1=Input, 0=Output)
default: 0
[-O <val>] Output
default: 0
[-P <val>] Pullups
default: 0
[-U <val>] Update Interval [ms]
default: 0
[-M <val>] First minor number
default: 0
stop
status print status info
```
## mcp9808
Source: [drivers/temperature_sensor/mcp9808](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/temperature_sensor/mcp9808)
@@ -899,8 +901,6 @@ fetching the latest mixing result and write them to PCA9685 at its scheduling ti
It can do full 12bits output as duty-cycle mode, while also able to output precious pulse width
that can be accepted by most ESCs and servos.
The I2C bus and address can be configured via parameters `PCA9685_EN_BUS` and `PCA9685_I2C_ADDR`, or via command line arguments.
### Приклади
It is typically started with:
docs/uk/modules/modules_system.md
+4
View File
@@ -127,6 +127,10 @@ commander <command> [arguments...]
check Run preflight checks
safety Change prearm safety state
on|off [on] to activate safety, [off] to deactivate safety and allow
control surface movements
arm
[-f] Force arming (do not run preflight checks)
docs/uk/msg_docs/BatteryStatus.md
+5 -5
View File
@@ -2,7 +2,7 @@
Battery status
Battery status information for up to 4 battery instances.
Battery status information for up to 3 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.
@@ -11,7 +11,7 @@ Battery instance information is also logged and streamed in MAVLink telemetry.
```c
# Battery status
#
# Battery status information for up to 4 battery instances.
# Battery status information for up to 3 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.
@@ -33,9 +33,9 @@ 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 SOURCE_POWER_MODULE = 0 # Power module (analog ADC or I2C power monitor)
uint8 SOURCE_EXTERNAL = 1 # External (MAVLink, CAN, or external driver)
uint8 SOURCE_ESCS = 2 # ESCs (via ESC telemetry)
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
docs/uk/msg_docs/BatteryStatusV0.md
+3 -3
View File
@@ -32,9 +32,9 @@ 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 SOURCE_POWER_MODULE = 0 # Power module (analog ADC or I2C power monitor)
uint8 SOURCE_EXTERNAL = 1 # External (MAVLink, CAN, or external driver)
uint8 SOURCE_ESCS = 2 # ESCs (via ESC telemetry)
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
docs/uk/msg_docs/DeviceInformation.md
+45
View File
@@ -0,0 +1,45 @@
# DeviceInformation (UORB message)
Device information
Can be used to uniquely associate a device_id from a sensor topic with a physical device using serial number.
as well as tracking of the used firmware versions on the devices.
[source file](https://github.com/PX4/PX4-Autopilot/blob/main/msg/DeviceInformation.msg)
```c
# Device information
#
# Can be used to uniquely associate a device_id from a sensor topic with a physical device using serial number.
# as well as tracking of the used firmware versions on the devices.
uint64 timestamp # time since system start (microseconds)
uint8 device_type # [@enum DEVICE_TYPE] Type of the device. Matches MAVLink DEVICE_TYPE enum
uint8 DEVICE_TYPE_GENERIC = 0 # Generic/unknown sensor
uint8 DEVICE_TYPE_AIRSPEED = 1 # Airspeed sensor
uint8 DEVICE_TYPE_ESC = 2 # ESC
uint8 DEVICE_TYPE_SERVO = 3 # Servo
uint8 DEVICE_TYPE_GPS = 4 # GPS
uint8 DEVICE_TYPE_MAGNETOMETER = 5 # Magnetometer
uint8 DEVICE_TYPE_PARACHUTE = 6 # Parachute
uint8 DEVICE_TYPE_RANGEFINDER = 7 # Rangefinder
uint8 DEVICE_TYPE_WINCH = 8 # Winch
uint8 DEVICE_TYPE_BAROMETER = 9 # Barometer
uint8 DEVICE_TYPE_OPTICAL_FLOW = 10 # Optical flow
uint8 DEVICE_TYPE_ACCELEROMETER = 11 # Accelerometer
uint8 DEVICE_TYPE_GYROSCOPE = 12 # Gyroscope
uint8 DEVICE_TYPE_DIFFERENTIAL_PRESSURE = 13 # Differential pressure
uint8 DEVICE_TYPE_BATTERY = 14 # Battery
uint8 DEVICE_TYPE_HYGROMETER = 15 # Hygrometer
char[32] vendor_name # Name of the device vendor
char[32] model_name # Name of the device model
uint32 device_id # [-] [@invalid 0 if not available] Unique device ID for the sensor. Does not change between power cycles.
char[24] firmware_version # [-] [@invalid empty if not available] Firmware version.
char[24] hardware_version # [-] [@invalid empty if not available] Hardware version.
char[33] serial_number # [-] [@invalid empty if not available] Device serial number or unique identifier.
```
docs/uk/msg_docs/EstimatorStatus.md
+1
View File
@@ -21,6 +21,7 @@ uint8 GPS_CHECK_FAIL_MAX_VERT_DRIFT = 7 # 7 : maximum allowed vertical position
uint8 GPS_CHECK_FAIL_MAX_HORZ_SPD_ERR = 8 # 8 : maximum allowed horizontal speed fail - requires stationary vehicle
uint8 GPS_CHECK_FAIL_MAX_VERT_SPD_ERR = 9 # 9 : maximum allowed vertical velocity discrepancy fail
uint8 GPS_CHECK_FAIL_SPOOFED = 10 # 10 : GPS signal is spoofed
uint8 GPS_CHECK_FAIL_JAMMED = 11 # 11 : GPS signal is jammed
uint64 control_mode_flags # Bitmask to indicate EKF logic state
uint8 CS_TILT_ALIGN = 0 # 0 - true if the filter tilt alignment is complete
docs/uk/msg_docs/GpioIn.md
+1
View File
@@ -6,6 +6,7 @@
```c
# GPIO mask and state
uint8 MAX_INSTANCES = 8
uint64 timestamp # time since system start (microseconds)
uint32 device_id # Device id
docs/uk/msg_docs/GpsDump.md
+5 -1
View File
@@ -9,11 +9,15 @@ This message is used to dump the raw gps communication to the log.
uint64 timestamp # time since system start (microseconds)
uint8 INSTANCE_MAIN = 0
uint8 INSTANCE_SECONDARY = 1
uint8 instance # Instance of GNSS receiver
uint32 device_id
uint8 len # length of data, MSB bit set = message to the gps device,
# clear = message from the device
uint8[79] data # data to write to the log
uint8 ORB_QUEUE_LENGTH = 8
uint8 ORB_QUEUE_LENGTH = 16
```
docs/uk/msg_docs/VehicleCommand.md
+5
View File
@@ -108,6 +108,7 @@ uint16 VEHICLE_CMD_LOGGING_START = 2510 # Start streaming ULog data.
uint16 VEHICLE_CMD_LOGGING_STOP = 2511 # Stop streaming ULog data.
uint16 VEHICLE_CMD_CONTROL_HIGH_LATENCY = 2600 # Control starting/stopping transmitting data over the high latency link.
uint16 VEHICLE_CMD_DO_VTOL_TRANSITION = 3000 # Command VTOL transition.
uint16 VEHICLE_CMD_DO_SET_SAFETY_SWITCH_STATE = 5300 # Command safety on/off. |1 to activate safety, 0 to deactivate safety and allow control surface movements|Unused|Unused|Unused|Unused|Unused|Unused|
uint16 VEHICLE_CMD_ARM_AUTHORIZATION_REQUEST = 3001 # Request arm authorization.
uint16 VEHICLE_CMD_PAYLOAD_PREPARE_DEPLOY = 30001 # Prepare a payload deployment in the flight plan.
uint16 VEHICLE_CMD_PAYLOAD_CONTROL_DEPLOY = 30002 # Control a pre-programmed payload deployment.
@@ -187,6 +188,10 @@ int8 ARMING_ACTION_ARM = 1
uint8 GRIPPER_ACTION_RELEASE = 0
uint8 GRIPPER_ACTION_GRAB = 1
# Used as param1 in DO_SET_SAFETY_SWITCH_STATE command.
uint8 SAFETY_OFF = 0
uint8 SAFETY_ON = 1
uint8 ORB_QUEUE_LENGTH = 8
float32 param1 # Parameter 1, as defined by MAVLink uint16 VEHICLE_CMD enum.
docs/uk/msg_docs/index.md
+1
View File
@@ -105,6 +105,7 @@ Graphs showing how these are used [can be found here](../middleware/uorb_graph.m
- [DebugKeyValue](DebugKeyValue.md)
- [DebugValue](DebugValue.md)
- [DebugVect](DebugVect.md)
- [DeviceInformation](DeviceInformation.md) — Device information
- [DifferentialPressure](DifferentialPressure.md) — Differential-pressure (airspeed) sensor
- [DistanceSensor](DistanceSensor.md) — DISTANCE_SENSOR message data
- [DistanceSensorModeChangeRequest](DistanceSensorModeChangeRequest.md)
docs/uk/peripherals/dshot.md
+4
View File
@@ -11,6 +11,10 @@ DShot is an alternative ESC protocol that has several advantages over [PWM](../p
Ця тема показує, як підключити та налаштувати DShot ESC.
## Supported ESC
[ESCs & Motors > Supported ESCs](../peripherals/esc_motors#supported-esc) has a list of supported ESC (check "Protocols" column for DShot ESC).
## Wiring/Connections {#wiring}
DShot ESC are wired the same way as [PWM ESCs](pwm_escs_and_servo.md).
docs/uk/peripherals/esc_motors.md
+9 -7
View File
@@ -9,13 +9,14 @@ PX4 supports a number of [common protocols](../esc/esc_protocols.md) for sending
The following list is non-exhaustive.
| ESC Device | Протоколи | Firmwares | Примітки |
| ---------------------------- | ------------------------------------ | ------------------------ | ----------------------------------------------------- |
| [ARK 4IN1 ESC] | [Dshot], [PWM] | [AM32] | Has versions with/without connnectors |
| [Holybro Kotleta 20] | [DroneCAN], [PWM] | [PX4 Sapog ESC Firmware] | |
| [Vertiq Motor & ESC modules] | [Dshot], [OneShot], Multishot, [PWM] | Vertiq firmware | Larger modules support DroneCAN, ESC and Motor in one |
| [VESC ESCs] | [DroneCAN], [PWM] | VESC project firmware | |
| [Zubax Telega] | [DroneCAN], [PWM] | Telega-based | ESC and Motor in one |
| ESC Device | Протоколи | Firmwares | Примітки |
| ------------------------------ | ------------------------------------ | ------------------------ | ----------------------------------------------------- |
| [ARK 4IN1 ESC] | [Dshot], [PWM] | [AM32] | Has versions with/without connnectors |
| [Holybro Kotleta 20] | [DroneCAN], [PWM] | [PX4 Sapog ESC Firmware] | |
| [Vertiq Motor & ESC modules] | [Dshot], [OneShot], Multishot, [PWM] | Vertiq firmware | Larger modules support DroneCAN, ESC and Motor in one |
| [RaccoonLab CAN PWM ESC nodes] | [DroneCAN], Cyphal | | Cyphal and DroneCAN notes for PWM ESC |
| [VESC ESCs] | [DroneCAN], [PWM] | VESC project firmware | |
| [Zubax Telega] | [DroneCAN], [PWM] | Telega-based | ESC and Motor in one |
<!-- Links for table above -->
@@ -29,6 +30,7 @@ The following list is non-exhaustive.
[PWM]: ../peripherals/pwm_escs_and_servo.md
[Holybro Kotleta 20]: ../dronecan/holybro_kotleta.md
[Vertiq Motor & ESC modules]: ../peripherals/vertiq.md
[RaccoonLab CAN PWM ESC nodes]: ../dronecan/raccoonlab_nodes.md
[Zubax Telega]: ../dronecan/zubax_telega.md
## Дивіться також
docs/zh/SUMMARY.md
+1
View File
@@ -584,6 +584,7 @@
- [DebugKeyValue](msg_docs/DebugKeyValue.md)
- [DebugValue](msg_docs/DebugValue.md)
- [DebugVect](msg_docs/DebugVect.md)
- [DeviceInformation](msg_docs/DeviceInformation.md)
- [DifferentialPressure](msg_docs/DifferentialPressure.md)
- [DistanceSensor](msg_docs/DistanceSensor.md)
- [DistanceSensorModeChangeRequest](msg_docs/DistanceSensorModeChangeRequest.md)
docs/zh/advanced_config/ethernet_setup.md
+1
View File
@@ -25,6 +25,7 @@ PX4 supports Ethernet connectivity on [Pixhawk 5X-standard](https://github.com/p
支持的飞行控制器包括:
- [ARK Electronics ARKV6X](../flight_controller/ark_v6x.md)
- [CUAV Pixhawk V6X](../flight_controller/cuav_pixhawk_v6x.md)
- [Holybro Pixhawk 5X](../flight_controller/pixhawk5x.md)
- [Holybro Pixhawk 6X](../flight_controller/pixhawk6x.md)
docs/zh/advanced_config/tuning_the_ecl_ekf.md
+49 -49
View File
@@ -99,7 +99,7 @@ EKF 实例的总数是 [EKF2_MULTI_IMU](../advanced_config/parameter_reference.m
- [SENS_IMU_MODE](../advanced_config/parameter_reference.md#SENS_IMU_MODE):
如果是以 IMU 传感器多样性运行多个 EKF 实例，即 [EKF2_MULTI_IMU](../advanced_config/parameter_reference.md#EKF2_MULTI_IMU) > 1，则设置为 0。
当设置为 1（单个 EKF 操作的默认值）时，传感器模块选择 EKF 使用的 IMU 数据。
当设置为 1（单个 EKF 的默认值）时，传感器模块选择 EKF 使用的 IMU 数据。
这提供了针对传感器数据丢失的保护，但不提供针对错误传感器数据的保护。
当设置为 0 时，传感器模块不进行选择。
@@ -107,7 +107,7 @@ EKF 实例的总数是 [EKF2_MULTI_IMU](../advanced_config/parameter_reference.m
如果是以磁力计传感器多样性运行多个 EKF 实例，即 [EKF2_MULTI_MAG](../
advanced_config/parameter_reference.md#EKF2_MULTI_MAG) > 1，则设置为 0。
当设置为 1（单个 EKF 操作的默认值）时，传感器模块选择 EKF 使用的磁力计数据。
当设置为 1（单个 EKF 的默认值）时，传感器模块选择 EKF 使用的磁力计数据。
这提供了针对传感器数据丢失的保护，但不提供针对错误传感器数据的保护。
当设置为 0 时，传感器模块不进行选择。
@@ -115,13 +115,13 @@ EKF 实例的总数是 [EKF2_MULTI_IMU](../advanced_config/parameter_reference.m
此参数指定多个 EKF 使用的 IMU 传感器数量。
如果 `EKF2_MULTI_IMU` <= 1，则仅使用第一个 IMU 传感器。
当 [SENS_IMU_MODE](../advanced_config/parameter_reference.md#SENS_IMU_MODE) = 1 时，这将是传感器模块选择的传感器。
如果 `EKF2_MULTI_IMU` >= 2，则将针对指定数量的 IMU 传感器（最多 4 个或存在的 IMU 数量，取较小值）运行单独的 EKF 实例。
如果 `EKF2_MULTI_IMU` >= 2，那么将为指定数量的 IMU 传感器运行独立的 EKF 实例，最多支持 4 个或实际存在的 IMU 数量（取两者中的较小值）。
- [EKF2_MULTI_MAG](../advanced_config/parameter_reference.md#EKF2_MULTI_MAG):
此参数指定多个 EKF 使用的磁力计传感器数量。
如果 `EKF2_MULTI_MAG` <= 1，则仅使用第一个磁力计传感器。
当 [SENS_MAG_MODE](../advanced_config/parameter_reference.md#SENS_MAG_MODE) = 1 时，这将是传感器模块选择的传感器。
如果 `EKF2_MULTI_MAG` >= 2，则将针对指定数量的磁力计传感器（最多 4 个或存在的磁力计数量，取较小值）运行单独的 EKF 实例。
如果 `EKF2_MULTI_MAG` >= 2，那么将为指定数量的磁力计传感器运行独立的 EKF 实例，最多支持 4 个或实际存在的磁力计数量（取两者中的较小值）。
:::info
不支持多 EKF 实例飞行日志的记录和 [EKF2 回放](../debug/system_wide_replay.md#ekf2-replay)。
@@ -131,26 +131,26 @@ EKF 实例的总数是 [EKF2_MULTI_IMU](../advanced_config/parameter_reference.m
## 它使用哪些传感器测量？
EKF 具有不同的操作模式，允许不同的传感器测量组合。
启动时，滤波器会检查最小的可行传感器组合，并在初始倾斜、偏航和高度对准完成后，进入提供旋转、垂直速度、垂直位置、IMU 角度增量零偏和 IMU 速度增量零偏估计的模式。
启动时，滤波器会检查传感器的最小可用组合，并在初始倾斜、偏航和高度对准完成后，进入提供旋转、垂直速度、垂直位置、IMU 角度增量零偏和 IMU 速度增量零偏估计的模式。
此模式需要 IMU 数据、偏航源（磁力计或外部视觉）和高度数据源。
所有 EKF 操作模式都需要此最小数据集。
然后可以使用其他传感器数据来估计额外的状态。
所有 EKF 工作模式都需要此最小数据集。
其他传感器数据可用于估计额外状态。
### IMU
- 三轴机体固定惯性测量单元 (IMU) 的角度增量和速度增量数据，最小速率为 100Hz。
注意：在 EKF 使用 IMU 角度增量数据之前，应先对其应用圆锥效应校正。
- 固定在机体上的三轴 IMU，以至少100Hz的频率获取增量角度和角速度数据 。
注意：在 EKF 使用 IMU 角度增量数据之前，应该使用圆锥校正算法校正。
### 磁力计
估计器需要三轴机体固定磁力计数据，最小速率为 5Hz。
固定在机体上的三轴磁力计数据，至少以 5Hz 提供数据才会被估计器用于估计。
::: info
- 磁力计 **零偏 (biases)** 仅在无人机旋转时可观测。
- 当载具加速（线性加速度）且同时融合绝对位置或速度测量值（例如 GPS）时，真实航向是可观测的。
这意味着如果这些条件能够足够频繁地满足以约束航向漂移（由陀螺仪零偏引起），则初始化后的磁力计航向测量是可选的。
- 当载具处于加速状态（线性加速度）时，可通过融合绝对位置或速度测量数据（例如GPS）来观测真实航向。
这意味着在初始化后，如果满足上述条件且频率足够高以约束（由陀螺仪偏置引起的）航向漂移，则磁力计航向测量是可选的。
:::
@@ -160,12 +160,12 @@ EKF 具有不同的操作模式，允许不同的传感器测量组合。
- 磁力计读数仅在解锁前影响航向估计，解锁后影响整个姿态。
- 使用此方法时会补偿航向和倾斜误差。
- 不正确的磁场测量会降低倾斜估计的质量。
- 只要可观测，就会估计磁力计零偏。
- 磁力计零偏会在可观测时被估计。
1. 磁航向 (Magnetic heading):
- 仅修正航向。
倾斜估计永远不会受到不正确磁场测量的影响。
- 使用此方法时，不会修正因没有速度/位置辅助飞行而产生的倾斜误差。
- 只要可观测，就会估计磁力计零偏。
- 磁力计零偏会在可观测时被估计。
2. 已弃用
3. 已弃用
4. 已弃用
@@ -173,7 +173,7 @@ EKF 具有不同的操作模式，允许不同的传感器测量组合。
- 永不使用磁力计数据。
当数据完全不可信时（例如：传感器附近有大电流、外部异常），这很有用。
- 估计器将使用其他航向源：[GPS 航向](#yaw-measurements) 或外部视觉。
- 当使用 GPS 测量而没有其他航向源时，航向只能在充分的水平加速后才能初始化。
- 当使用 GPS 测量而没有其他航向源时，航向只能在获得足够的水平加速度后才能初始化。
参见下文的 [从载具运动估计偏航](#yaw-from-gps-velocity)。
6. 仅初始化 (Init only):
- 磁力计数据仅用于初始化航向估计。
@@ -317,9 +317,9 @@ GSF 应用于各个 3 状态 EKF 输出的权重位于 `weight` 字段中。
- 检查来自每个接收机的 `s_variance_m_s`、`eph` 和 `epv` 数据，并决定可以使用哪些精度指标。
如果两个接收机都输出合理的 `s_variance_m_s` 和 `eph` 数据，并且 GPS 垂直位置未直接用于导航，则建议将 [SENS_GPS_MASK](../advanced_config/parameter_reference.md#SENS_GPS_MASK) 设置为 3。
如果只有 `eph` 数据可用，且两个接收机都不输出 `s_variance_m_s` 数据，则将 [SENS_GPS_MASK](../advanced_config/parameter_reference.md#SENS_GPS_MASK) 设置为 2。
只有当 GPS 已通过 [EKF2_HGT_REF](../advanced_config/parameter_reference.md#EKF2_HGT_REF) 参数被选为参考高度源，且两个接收机都输出合理的 `epv` 数据时，才会设置第 2 位。
只有当 GPS 已通过 [EKF2_HGT_REF](../advanced_config/parameter_reference.md#EKF2_HGT_REF) 参数被选为参考高度源，且两个接收机都输出合理的 `epv` 数据时，第 2 位才会被置位。
- 混合接收机数据的输出记录为 `ekf_gps_position`，可以在连接 nsh 终端时使用命令 `listener ekf_gps_position` 进行检查。
- 如果接收机以不同的速率输出，则混合输出将采用较慢接收机的速率。
- 若各接收机输出速率不同，融合后的输出速率将与速率较慢的接收机保持一致。
在可能的情况下，接收机应配置为以相同的速率输出。
#### GNSS 性能要求
@@ -546,11 +546,11 @@ EKF 会考虑视觉位姿估计中的不确定性。
此不确定性信息可以通过 MAVLink [ODOMETRY](https://mavlink.io/en/messages/common.html#ODOMETRY) 消息中的协方差字段发送，也可以通过参数 [EKF2_EVP_NOISE](../advanced_config/parameter_reference.md#EKF2_EVP_NOISE)、[EKF2_EVV_NOISE](../advanced_config/parameter_reference.md#EKF2_EVV_NOISE) 和 [EKF2_EVA_NOISE](../advanced_config/parameter_reference.md#EKF2_EVA_NOISE) 进行设置。
您可以使用 [EKF2_EV_NOISE_MD](../advanced_config/parameter_reference.md#EKF2_EV_NOISE_MD) 选择不确定性的来源。
## 如何使用 'ecl' 库 EKF？
## 如何使用 'ecl' 库中的EKF？
EKF2 默认启用（有关更多信息，请参阅 [切换状态估计器](../advanced/switching_state_estimators.md) 和 [EKF2_EN](../advanced_config/parameter_reference.md#EKF2_EN)）。
## 如何使用 'ecl' 库 EKF？
## ecl EKF相较于其他估计器的优缺点是什么？
像所有估计器一样，大部分性能来自于与传感器特性相匹配的调参。
调参是精度和鲁棒性之间的折衷，虽然我们试图提供满足大多数用户需求的参数，但仍会有需要更改参数的应用。
@@ -624,7 +624,7 @@ covariances\[24\] 的索引映射如下：
- \[19 ... 21\] 机体磁场 XYZ \(gauss^2\)
- \[22 ... 23\] 风速 NE \(m/s\)^2
### 观测创新量与创新方差
### 观测新息与新息方差
观测 `estimator_innovations`、`estimator_innovation_variances` 与 `estimator_innovation_test_ratios` 消息字段定义在 [EstimatorInnovations.msg](https://github.com/PX4/PX4-Autopilot/blob/main/msg/EstimatorInnovations.msg) 中。
这些消息字段名称/类型相同（但单位不同）。
@@ -654,30 +654,30 @@ covariances\[24\] 的索引映射如下：
这些字段基本自说明，下面给出原始定义：
```
float32[2] gps_hvel # 水平 GPS 速度创新量 (m/sec) 与创新方差 ((m/sec)**2)
float32 gps_vvel # 垂直 GPS 速度创新量 (m/sec) 与创新方差 ((m/sec)**2)
float32[2] gps_hpos # 水平 GPS 位置创新量 (m) 与创新方差 (m**2)
float32 gps_vpos # 垂直 GPS 位置创新量 (m) 与创新方差 (m**2)
float32[2] gps_hvel # 水平 GPS 速度新息 (m/sec) 与新息方差 ((m/sec)**2)
float32 gps_vvel # 垂直 GPS 速度新息 (m/sec) 与新息方差 ((m/sec)**2)
float32[2] gps_hpos # 水平 GPS 位置新息 (m) 与新息方差 (m**2)
float32 gps_vpos # 垂直 GPS 位置新息 (m) 与新息方差 (m**2)
# External Vision
float32[2] ev_hvel # 水平外部视觉速度创新量 (m/sec) 与创新方差 ((m/sec)**2)
float32 ev_vvel # 垂直外部视觉速度创新量 (m/sec) 与创新方差 ((m/sec)**2)
float32[2] ev_hpos # 水平外部视觉位置创新量 (m) 与创新方差 (m**2)
float32 ev_vpos # 垂直外部视觉位置创新量 (m) 与创新方差 (m**2)
float32[2] ev_hvel # 水平外部视觉速度新息 (m/sec) 与新息方差 ((m/sec)**2)
float32 ev_vvel # 垂直外部视觉速度新息 (m/sec) 与新息方差 ((m/sec)**2)
float32[2] ev_hpos # 水平外部视觉位置新息 (m) 与新息方差 (m**2)
float32 ev_vpos # 垂直外部视觉位置新息 (m) 与新息方差 (m**2)
# Fake Position and Velocity
float32[2] fake_hvel # 虚拟水平速度创新量 (m/s) 与创新方差 ((m/s)**2)
float32 fake_vvel # 虚拟垂直速度创新量 (m/s) 与创新方差 ((m/s)**2)
float32[2] fake_hpos # 虚拟水平位置创新量 (m) 与创新方差 (m**2)
float32 fake_vpos # 虚拟垂直位置创新量 (m) 与创新方差 (m**2)
float32[2] fake_hvel # 虚拟水平速度新息 (m/s) 与新息方差 ((m/s)**2)
float32 fake_vvel # 虚拟垂直速度新息 (m/s) 与新息方差 ((m/s)**2)
float32[2] fake_hpos # 虚拟水平位置新息 (m) 与新息方差 (m**2)
float32 fake_vpos # 虚拟垂直位置新息 (m) 与新息方差 (m**2)
# Height sensors
float32 rng_vpos # 测距高度创新量 (m) 与创新方差 (m**2)
float32 baro_vpos # 气压计高度创新量 (m) 与创新方差 (m**2)
float32 rng_vpos # 测距高度新息 (m) 与新息方差 (m**2)
float32 baro_vpos # 气压计高度新息 (m) 与新息方差 (m**2)
# Auxiliary velocity
float32[2] aux_hvel # 来自着陆目标测量的水平辅助速度创新量 (m/sec) 与创新方差 ((m/sec)**2)
float32 aux_vvel # 来自着陆目标测量的垂直辅助速度创新量 (m/sec) 与创新方差 ((m/sec)**2)
float32[2] aux_hvel # 来自着陆目标测量的水平辅助速度新息 (m/sec) 与新息方差 ((m/sec)**2)
float32 aux_vvel # 来自着陆目标测量的垂直辅助速度新息 (m/sec) 与新息方差 ((m/sec)**2)
```
### 输出互补滤波器
@@ -710,17 +710,17 @@ EKF 包含针对严重条件状态和协方差更新的内部错误检查。
这种情况的一个例子是过度振动导致大的垂直位置误差，导致气压计高度测量被拒绝。
这两者都可能导致观测数据被拒绝，如果时间足够长，使得 EKF 尝试重置状态以使用传感器观测数据。
所有观测都会对创新量进行统计置信度检查。
所有观测结果均对新息进行了统计置信度检查。
各观测类型的检查标准差数由对应的 `EKF2_*_GATE` 参数控制。
测试指标可在 [EstimatorStatus](https://github.com/PX4/PX4-Autopilot/blob/main/msg/EstimatorStatus.msg) 中查看：
- `mag_test_ratio`：磁力计创新量最大分量与测试限值的比值
- `vel_test_ratio`：速度创新量最大分量与测试限值的比值
- `pos_test_ratio`：水平位置创新量最大分量与测试限值的比值
- `hgt_test_ratio`：垂直位置创新量与测试限值的比值
- `tas_test_ratio`：真空速创新量与测试限值的比值
- `hagl_test_ratio`：离地高度创新量与测试限值的比值
- `mag_test_ratio`：磁力计新息最大分量与测试限值的比值
- `vel_test_ratio`：速度新息最大分量与测试限值的比值
- `pos_test_ratio`：水平位置新息最大分量与测试限值的比值
- `hgt_test_ratio`：垂直位置新息与测试限值的比值
- `tas_test_ratio`：真空速新息与测试限值的比值
- `hagl_test_ratio`：离地高度新息与测试限值的比值
若需查看每个传感器的二值通过/失败汇总，请参考 [EstimatorStatus](https://github.com/PX4/PX4-Autopilot/blob/main/msg/EstimatorStatus.msg) 中的 `innovation_check_flags`。
@@ -749,7 +749,7 @@ EKF 对其所有计算使用单精度浮点运算，并使用一阶近似来推
重新调参后，尤其是降低噪声变量的调参，应检查 `estimator_status.gps_check_fail_flags` 是否保持为零。
## 如果高度估计值发散了怎么办?
## 如何应对高度估计的发散？
在飞行期间 EKF 高度偏离 GPS 和高度计测量的最常见原因是由振动引起的 IMU 测量的削波和/或混叠。
出现该问题时，通常会在数据中看到以下迹象：
@@ -772,7 +772,7 @@ EKF 对其所有计算使用单精度浮点运算，并使用一阶近似来推
注意 这些变化的影响将使 EKF 对 GPS 垂直速度和气压的误差更敏感。
## 如果位置估计发散了应该怎么办?
## 如何应对位置估计的发散？
位置发散的最常见原因是：
@@ -821,7 +821,7 @@ EKF 对其所有计算使用单精度浮点运算，并使用一阶近似来推
### 确定过度振动
高振动通常会影响垂直位置与速度创新量以及水平分量。
高振动通常会影响垂直位置与速度新息以及水平分量。
磁力计测试级别仅受到很小程度的影响。
\(在此插入示例绘图显示不好振动\)
@@ -865,11 +865,11 @@ GPS 数据精度差通常伴随着接收器报告的速度误差的增加以及
GPS 数据丢失会表现为速度与位置创新测试比值“贴平(flat-lining)”。
出现该情况时，请检查 `vehicle_gps_position` 中的其他 GPS 状态数据。
下图显示了使用 SITL Gazebo 模拟 VTOL 飞行生成的 NED GPS 速度创新量 `ekf2_innovations_0.vel_pos_innov[0 ... 2]`、GPS NE 位置创新量 `ekf2_innovations_0.vel_pos_innov[3 ... 4]` 以及气压垂直位置创新量 `ekf2_innovations_0.vel_pos_innov[5]`。
下图显示了使用 SITL Gazebo 模拟 VTOL 飞行生成的 NED GPS 速度新息 `ekf2_innovations_0.vel_pos_innov[0 ... 2]`、GPS NE 位置新息 `ekf2_innovations_0.vel_pos_innov[3 ... 4]` 以及气压垂直位置新息 `ekf2_innovations_0.vel_pos_innov[5]`。
模拟的 GPS 在 73 秒时失锁。
注意 GPS 丢失后 NED 速度创新量与 NE 位置创新量“贴平(flat-line)”。
注意 GPS 丢失 10 秒后，EKF 会回退到使用最后已知位置的静态位置模式，NE 位置创新量开始再次变化。
注意 GPS 丢失后 NED 速度新息与 NE 位置新息“贴平(flat-line)”。
注意 GPS 丢失 10 秒后，EKF 会回退到使用最后已知位置的静态位置模式，NE 位置新息开始再次变化。
![GPS Data Loss - in SITL](../../assets/ecl/gps_data_loss_-_velocity_innovations.png)
docs/zh/assembly/_assembly.md
+1 -2
View File
@@ -285,7 +285,7 @@ A particular vehicle might have more/fewer motors and actuators, but the wiring
The following sections explain each part in more detail.
:::tip
If you're using [DroneCAN ESC](../peripherals/esc_motors.md#dronecan) the control signals will be connected to the CAN BUS instead of the PWM outputs as shown.
If you're using [DroneCAN ESC](../dronecan/escs.md) the control signals will be connected to the CAN BUS instead of the PWM outputs as shown.
:::
### Flight Controller Power
@@ -426,7 +426,6 @@ They recommend sensors, power systems, and other components from the same manufa
- [Drone Components & Parts](../getting_started/px4_basic_concepts.md#drone-components-parts) (Basic Concepts)
- [Payloads](../getting_started/px4_basic_concepts.md#payloads) (Basic Concepts)
- [Hardware Selection & Setup](../hardware/drone_parts.md) — information about connecting and configuring specific flight controllers, sensors and other peripherals (e.g. airspeed sensor for planes).
- [Mounting the Flight Controller](../assembly/mount_and_orient_controller.md)
- [Vibration Isolation](../assembly/vibration_isolation.md)
- [Mounting a Compass](../assembly/mount_gps_compass.md)
docs/zh/config_mc/filter_tuning.md
+1 -1
View File
@@ -70,7 +70,7 @@ Airframes with more than two frequency noise spikes typically clean the first tw
Dynamic notch filters use ESC RPM feedback and/or the onboard FFT analysis.
The ESC RPM feedback is used to track the rotor blade pass frequency and its harmonics, while the FFT analysis can be used to track a frequency of another vibration source, such as a fuel engine.
ESC RPM feedback requires ESCs capable of providing RPM feedback such as [DShot](../peripherals/esc_motors.md#dshot) with telemetry connected, a bidirectional DShot set up ([work in progress](https://github.com/PX4/PX4-Autopilot/pull/23863)), or [UAVCAN/DroneCAN ESCs](../dronecan/escs.md).
ESC RPM feedback requires ESCs capable of providing RPM feedback such as [DShot](../peripherals/dshot.md) with telemetry connected, a bidirectional DShot set up ([work in progress](https://github.com/PX4/PX4-Autopilot/pull/23863)), or [UAVCAN/DroneCAN ESCs](../dronecan/escs.md).
Before enabling, make sure that the ESC RPM is correct.
You might have to adjust the [pole count of the motors](../advanced_config/parameter_reference.md#MOT_POLE_COUNT).
docs/zh/dev_setup/building_px4.md
+3 -3
View File
@@ -145,7 +145,7 @@ make px4_fmu-v5_default
- [Pixhawk 1 (FMUv2)](../flight_controller/pixhawk.md): `make px4_fmu-v2_default`
:::warning
您**必须**使用受支持的GCC版本来构建此开发板（例如与[CI/docker](../test_and_ci/docker.md)中使用的相同版本），否则需从构建中移除相关模块。 Building with an unsupported GCC may fail, as PX4 is close to the board's 1MB flash limit.
您**必须**使用受支持的GCC版本来构建此开发板（例如与[CI/docker](../test_and_ci/docker.md)中使用的相同版本），否则需从构建中移除相关模块。 使用不受支持的GCC进行构建可能会失败，因为PX4接近板载1MB闪存的容量限制。
:::
@@ -174,8 +174,8 @@ Rebooting.
```
:::tip
在 WSL 2 上开发时不支持此操作。（其实也有办法，见 [WSL 2 连接 USB 设备](https://learn.microsoft.com/zh-cn/windows/wsl/connect-usb)）。
参见[ Windows 开发环境 (WSL2-基于) > Flash控制板](../dev_setup/dev_env_windows_wsl.md#flash-a-flight-control-board)。
在 WSL2 上开发时不支持此操作。
参见[ Windows 开发环境 (WSL2-基于) > 烧录主板](../dev_setup/dev_env_windows_wsl.md#flash-a-flight-control-board)。
:::
## 其他飞控板
docs/zh/dronecan/escs.md
+8 -1
View File
@@ -1,7 +1,14 @@
# DroneCAN ESCs
PX4 supports DroneCAN compliant ESCs.
For more information, see the following articles for specific hardware/firmware:
## Supported ESC
:::info
[Supported ESCs](../peripherals/esc_motors#supported-esc) in _ESCs & Motors_ may include additional devices that are not listed below.
:::
The following articles have specific hardware/firmware information:
- [PX4 Sapog ESC Firmware](sapog.md)
- [Holybro Kotleta 20](holybro_kotleta.md)

Some files were not shown because too many files have changed in this diff Show More