Update description

Allow user to set choke position through parameter
2026-05-25 15:37:34 +08:00 · 2025-04-07 11:52:45 +02:00 · 2025-04-04 15:26:31 +02:00
183 changed files with 1834 additions and 4718 deletions
@@ -231,11 +231,6 @@ CONFIG:
      buildType: MinSizeRel
      settings:
        CONFIG: bitcraze_crazyflie_default
-    bluerobotics_navigator_default:
-      short: bluerobotics_navigator
-      buildType: MinSizeRel
-      settings:
-        CONFIG: bluerobotics_navigator_default
    cuav_can-gps-v1_default:
      short: cuav_can-gps-v1_default
      buildType: MinSizeRel
@@ -20,7 +20,7 @@ param set-default COM_ARM_CHK_ESCS 0  # We don't have ESCs
 param set-default FD_ESCS_EN 0 # We don't have ESCs - but maybe we need this later?

 param set-default CA_AIRFRAME 14
-param set-default MAV_TYPE 7  # Using Airship
+param set-default MAV_TYPE 99

 param set-default CA_THRUSTER_CNT 8
 param set-default CA_R_REV 0
@@ -30,12 +30,12 @@ param set-default RO_JERK_LIM 20
 param set-default RO_MAX_THR_SPEED 2.8

 # Rover Rate Control Parameters
-param set-default RO_YAW_RATE_I 0.1
-param set-default RO_YAW_RATE_P 0.1
-param set-default RO_YAW_RATE_LIM 120
+param set-default RO_YAW_RATE_I 0
+param set-default RO_YAW_RATE_P 0
+param set-default RO_YAW_RATE_LIM 0

 # Rover Attitude Control Parameters
-param set-default RO_YAW_P 2.5
+param set-default RO_YAW_P 0

 # Rover Position Control Parameters
 param set-default RO_SPEED_LIM 2.5
@@ -11,7 +11,7 @@
 . ${R}etc/init.d/rc.sc_defaults

 param set-default CA_AIRFRAME 14
-param set-default MAV_TYPE 7
+param set-default MAV_TYPE 99

 param set-default CA_THRUSTER_CNT 8
 param set-default CA_R_REV 0
@@ -5,8 +5,8 @@

 set VEHICLE_TYPE sc

-# MAV_TYPE_SPACECRAFT
-param set-default MAV_TYPE 7
+# MAV_TYPE_QUADROTOR 2
+#param set-default MAV_TYPE 12

 # Set micro-dds-client to use ethernet and IP-address 192.168.0.1
 param set-default UXRCE_DDS_AG_IP -1062731775
@@ -226,7 +226,10 @@ then

 	# compasses
 	hmc5883 -T -X -q start
-	iis2mdc -X -q start
+	if ! iis2mdc -X -q start
+	then
+		lis2mdl -X -q start
+	fi
 	ist8308 -X -q start
 	ist8310 -X -q start
 	if ! lis3mdl -X -q start
@@ -32,15 +32,6 @@ then
 	. ${R}etc/init.d/rc.rover_apps
 fi

-#
-# Spapcecraft setup.
-#
-if [ $VEHICLE_TYPE = sc ]
-then
-	# Start standard multicopter apps.
-	. ${R}etc/init.d/rc.sc_apps
-fi
-
 #
 # Differential Rover setup.
 #
@@ -5,8 +5,8 @@ if [ -z ${PX4_DOCKER_REPO+x} ]; then
 	if [[ $@ =~ .*px4_fmu.* ]]; then
 		# nuttx-px4fmu-v{1,2,3,4,5}
 		PX4_DOCKER_REPO="px4io/px4-dev-nuttx-focal:2022-08-12"
-	elif [[ $@ =~ .*navio2.* ]] || [[ $@ =~ .*raspberry.* ]] || [[ $@ =~ .*beaglebone.* ]] || [[ $@ =~ .*pilotpi.default ]] || [[ $@ =~ .*navigator.* ]]; then
-		# beaglebone_blue_default, emlid_navio2_default, px4_raspberrypi_default, scumaker_pilotpi_default, bluerobotics_navigator_default
+	elif [[ $@ =~ .*navio2.* ]] || [[ $@ =~ .*raspberry.* ]] || [[ $@ =~ .*beaglebone.* ]] || [[ $@ =~ .*pilotpi.default ]]; then
+		# beaglebone_blue_default, emlid_navio2_default, px4_raspberrypi_default, scumaker_pilotpi_default
 		PX4_DOCKER_REPO="px4io/px4-dev-armhf:2023-06-26"
 	elif [[ $@ =~ .*pilotpi.arm64 ]]; then
 		# scumaker_pilotpi_arm64
@@ -129,7 +129,7 @@ __EXPORT void board_on_reset(int status)
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -67,7 +67,7 @@ void rgb_led(int r, int g, int b, int freqs)
 	if (!once) {
 		once = 1;

-		/* Enable Clock to Block */
+		/* Enabel Clock to Block */
 		modifyreg32(STM32_RCC_APB2ENR, 0, RCC_APB2ENR_TIM1EN);

 		/* Reload */
@@ -67,7 +67,7 @@ void rgb_led(int r, int g, int b, int freqs)
 	if (!once) {
 		once = 1;

-		/* Enable Clock to Block */
+		/* Enabel Clock to Block */
 		modifyreg32(STM32_RCC_APB2ENR, 0, RCC_APB2ENR_TIM1EN);

 		/* Reload */
@@ -67,7 +67,7 @@ void rgb_led(int r, int g, int b, int freqs)
 	if (!once) {
 		once = 1;

-		/* Enable Clock to Block */
+		/* Enabel Clock to Block */
 		modifyreg32(STM32_RCC_APB2ENR, 0, RCC_APB2ENR_TIM1EN);

 		/* Reload */
@@ -107,7 +107,7 @@ icm20948_i2c_passthrough -X -q start
 hmc5883 -T -X -q start
 ist8308 -X -q start
 ist8310 -X -q start
-iis2mdc -X -q start
+lis2mdl -X -q start
 lis3mdl -X -q start
 qmc5883l -X -q start
 rm3100 -X -q start
@@ -67,7 +67,7 @@ void rgb_led(int r, int g, int b, int freqs)
 	if (!once) {
 		once = 1;

-		/* Enable Clock to Block */
+		/* Enabel Clock to Block */
 		modifyreg32(STM32_RCC_APB2ENR, 0, RCC_APB2ENR_TIM1EN);

 		/* Reload */
@@ -296,7 +296,6 @@ CONFIG_UART4_RXBUFSIZE=600
 CONFIG_UART4_TXBUFSIZE=1500
 CONFIG_UART5_IFLOWCONTROL=y
 CONFIG_UART5_OFLOWCONTROL=y
-CONFIG_UART5_RXBUFSIZE=800
 CONFIG_UART5_RXDMA=y
 CONFIG_UART5_TXBUFSIZE=10000
 CONFIG_UART5_TXDMA=y
@@ -27,7 +27,6 @@ CONFIG_DRIVERS_UAVCAN=y
 CONFIG_BOARD_UAVCAN_TIMER_OVERRIDE=2
 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
@@ -67,7 +67,7 @@ void rgb_led(int r, int g, int b, int freqs)
 	if (!once) {
 		once = 1;

-		/* Enable Clock to Block */
+		/* Enabel Clock to Block */
 		modifyreg32(STM32_RCC_APB2ENR, 0, RCC_APB2ENR_TIM1EN);

 		/* Reload */
@@ -67,7 +67,7 @@ void rgb_led(int r, int g, int b, int freqs)
 	if (!once) {
 		once = 1;

-		/* Enable Clock to Block */
+		/* Enabel Clock to Block */
 		modifyreg32(STM32_RCC_APB2ENR, 0, RCC_APB2ENR_TIM1EN);

 		/* Reload */
@@ -100,7 +100,7 @@ __END_DECLS
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -100,7 +100,7 @@ __END_DECLS
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -1,53 +0,0 @@
-############################################################################
-#
-#   Copyright (c) 2020 PX4 Development Team. All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# 1. Redistributions of source code must retain the above copyright
-#    notice, this list of conditions and the following disclaimer.
-# 2. Redistributions in binary form must reproduce the above copyright
-#    notice, this list of conditions and the following disclaimer in
-#    the documentation and/or other materials provided with the
-#    distribution.
-# 3. Neither the name PX4 nor the names of its contributors may be
-#    used to endorse or promote products derived from this software
-#    without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
-# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
-# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
-# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
-# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
-# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
-# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
-# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-# POSSIBILITY OF SUCH DAMAGE.
-#
-############################################################################
-
-if(DEFINED ENV{AUTOPILOT_HOST})
-	set(AUTOPILOT_HOST $ENV{AUTOPILOT_HOST})
-else()
-	set(AUTOPILOT_HOST "raspberrypi")
-endif()
-
-if(DEFINED ENV{AUTOPILOT_USER})
-	set(AUTOPILOT_USER $ENV{AUTOPILOT_USER})
-else()
-	set(AUTOPILOT_USER "pi")
-endif()
-
-add_custom_target(upload
-	COMMAND rsync -arh --progress
-			${CMAKE_RUNTIME_OUTPUT_DIRECTORY} ${PX4_SOURCE_DIR}/posix-configs/rpi/navigator/*.config ${PX4_BINARY_DIR}/etc # source
-			"${AUTOPILOT_USER}@${AUTOPILOT_HOST}:/home/${AUTOPILOT_USER}/px4" # destination
-	DEPENDS px4
-	COMMENT "uploading px4"
-	USES_TERMINAL
-)
@@ -1,78 +0,0 @@
-CONFIG_PLATFORM_POSIX=y
-CONFIG_BOARD_LINUX_TARGET=y
-CONFIG_BOARD_TESTING=y
-CONFIG_BOARD_TOOLCHAIN="arm-linux-gnueabihf"
-CONFIG_BOARD_ARCHITECTURE="cortex-a53"
-CONFIG_DRIVERS_ADC_ADS1115=y
-CONFIG_DRIVERS_BATT_SMBUS=y
-CONFIG_DRIVERS_CAMERA_TRIGGER=y
-CONFIG_DRIVERS_LIGHTS_NEOPIXEL=y
-CONFIG_DRIVERS_IMU_INVENSENSE_ICM20602=y
-CONFIG_DRIVERS_BAROMETER_BMP280=y
-CONFIG_DRIVERS_GPS=y
-CONFIG_DRIVERS_MAGNETOMETER_MEMSIC_MMC5983MA=y
-CONFIG_DRIVERS_MAGNETOMETER_AKM_AK09916=y
-CONFIG_DRIVERS_PCA9685_PWM_OUT=y
-CONFIG_PCA9685_USE_EXTERNAL_CRYSTAL=y
-CONFIG_DRIVERS_RC_INPUT=y
-CONFIG_DRIVERS_SMART_BATTERY_BATMON=y
-CONFIG_COMMON_RC=y
-CONFIG_COMMON_DIFFERENTIAL_PRESSURE=y
-CONFIG_COMMON_DISTANCE_SENSOR=y
-CONFIG_MODULES_AIRSPEED_SELECTOR=y
-CONFIG_MODULES_ATTITUDE_ESTIMATOR_Q=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_EVENTS=y
-CONFIG_MODULES_FLIGHT_MODE_MANAGER=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_MAVLINK=y
-CONFIG_MODULES_MC_HOVER_THRUST_ESTIMATOR=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_UUV_ATT_CONTROL=y
-CONFIG_MODULES_UUV_POS_CONTROL=y
-CONFIG_MODULES_FW_ATT_CONTROL=y
-CONFIG_MODULES_FW_AUTOTUNE_ATTITUDE_CONTROL=y
-CONFIG_MODULES_FW_POS_CONTROL=y
-CONFIG_MODULES_FW_RATE_CONTROL=y
-CONFIG_MODULES_MANUAL_CONTROL=y
-CONFIG_MODULES_MC_ATT_CONTROL=y
-CONFIG_MODULES_MC_AUTOTUNE_ATTITUDE_CONTROL=y
-CONFIG_MODULES_MC_POS_CONTROL=y
-CONFIG_MODULES_MC_RATE_CONTROL=y
-CONFIG_MODULES_ROVER_POS_CONTROL=y
-CONFIG_MODULES_VTOL_ATT_CONTROL=y
-CONFIG_SYSTEMCMDS_BSONDUMP=y
-CONFIG_SYSTEMCMDS_DYN=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_TOPIC_LISTENER=y
-CONFIG_SYSTEMCMDS_TUNE_CONTROL=y
-CONFIG_SYSTEMCMDS_UORB=y
-CONFIG_SYSTEMCMDS_VER=y
-CONFIG_SYSTEMCMDS_WORK_QUEUE=y
-CONFIG_EXAMPLES_DYN_HELLO=y
-CONFIG_EXAMPLES_FAKE_GPS=y
-CONFIG_EXAMPLES_HELLO=y
-CONFIG_EXAMPLES_PX4_MAVLINK_DEBUG=y
-CONFIG_EXAMPLES_PX4_SIMPLE_APP=y
-CONFIG_EXAMPLES_WORK_ITEM=y
@@ -1,13 +0,0 @@
-#!/bin/sh
-#
-# board specific defaults
-#------------------------------------------------------------------------------
-
-# system_power not implemented
-param set CBRK_SUPPLY_CHK 894281
-
-# 1K + 4.7K
-param set BAT1_V_DIV 5.7
-
-# Always keep current config
-param set SYS_AUTOCONFIG 0
@@ -1,7 +0,0 @@
-#!/bin/sh
-#
-# board specific extras init
-#------------------------------------------------------------------------------
-
-rc_input start -d /dev/ttyAMA1
-rc_update start
@@ -1,39 +0,0 @@
-#!/bin/sh
-#
-# Navigator specific board sensors init
-#------------------------------------------------------------------------------
-
-if ! mmc5983ma start -s -m 0 -R 4
-then
-	echo "mmc5983ma not found."
-fi
-
-if ! ak09916 start -I -R 6
-then
-	echo "AK09916 not found."
-fi
-
-if ! icm20602 start -s -m 0 -R 14
-then
-	echo "ICM20602 not found."
-fi
-
-if ! bmp280 start -I
-then
-	echo "bmp280 not found."
-fi
-
-if ! ads1115 start -I
-then
-	echo "ads1115 not found."
-fi
-
-if ! pca9685_pwm_out start -a 0x40 -b 4
-then
-	echo "pca9685_pwm_out not found."
-fi
-
-if ! neopixel start
-then
-	echo "neopixel not found."
-fi
@@ -1,36 +0,0 @@
-############################################################################
-#
-#   Copyright (c) 2024 PX4 Development Team. All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# 1. Redistributions of source code must retain the above copyright
-#    notice, this list of conditions and the following disclaimer.
-# 2. Redistributions in binary form must reproduce the above copyright
-#    notice, this list of conditions and the following disclaimer in
-#    the documentation and/or other materials provided with the
-#    distribution.
-# 3. Neither the name PX4 nor the names of its contributors may be
-#    used to endorse or promote products derived from this software
-#    without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
-# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
-# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
-# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
-# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
-# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
-# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
-# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-# POSSIBILITY OF SUCH DAMAGE.
-#
-############################################################################
-
-px4_add_library(arch_srgbled_dma
-	srgbled_impl.cpp
-)
@@ -1,157 +0,0 @@
-/****************************************************************************
- *
- *   Copyright (c) 2024 PX4 Development Team. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in
- *    the documentation and/or other materials provided with the
- *    distribution.
- * 3. Neither the name PX4 nor the names of its contributors may be
- *    used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
- * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
- * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
- * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- *
- ****************************************************************************/
-
-/**
- * @file srgbled_impl.cpp
- *
- * Implementation of functions to control NeoPixel LEDs on the BlueRobotics Navigator for the neopixel driver.
- *
- * Definitions:
- * - BOARD_HAS_N_S_RGB_LED: Number of NeoPixel LEDs on the Navigator.
- * - BOARD_RGB_SPI_BUS: SPI bus connected to the NeoPixel data line.
- * - BOARD_RGB_SPI_FREQ: SPI bus frequency for the NeoPixel connection.
- */
-
-#include <board_config.h>
-#include <drivers/drv_neopixel.h>
-#include <px4_platform_common/i2c_spi_buses.h>
-#include <px4_platform_common/log.h>
-#include <px4_platform_common/px4_config.h>
-#include <px4_platform_common/sem.h>
-
-#if defined(BOARD_HAS_N_S_RGB_LED)
-
-#if !defined(BOARD_RGB_SPI_BUS)
-#  error  BOARD_RGB_SPI_BUS must be defined to use the NeoPixel driver implementation for the BlueRobotics Navigator
-#endif
-#if !defined(BOARD_RGB_SPI_FREQ)
-#  error  BOARD_RGB_SPI_FREQ must be defined to use the NeoPixel driver implementation for the BlueRobotics Navigator
-#endif
-
-#define LED_T0 0b11000000
-#define LED_T1 0b11110000
-
-class NavigatorLED : public device::SPI
-{
-public:
-	NavigatorLED();
-	~NavigatorLED() override = default;
-
-	int init();
-	int write(uint8_t red, uint8_t green, uint8_t blue);
-	int deinit();
-
-protected:
-	void _setup_data(uint8_t red, uint8_t green, uint8_t blue);
-
-private:
-	uint8_t _data[24];
-	px4_sem_t _sem;
-};
-
-NavigatorLED::NavigatorLED() :
-	// By default we don't use the CS line and MODE must be 0 for compatibility with Raspberry Pi
-	SPI(DRV_DEVTYPE_UNUSED, "navigator-neopixel", BOARD_RGB_SPI_BUS, 0, SPIDEV_MODE0, BOARD_RGB_SPI_FREQ)
-{
-	px4_sem_init(&_sem, 0, 1);
-}
-
-int NavigatorLED::init()
-{
-	int ret = SPI::init();
-
-	if (ret != PX4_OK) {
-		PX4_ERR("Neopixel SPI init failed");
-		return ret;
-	}
-
-	return PX4_OK;
-}
-
-void NavigatorLED::_setup_data(uint8_t red, uint8_t green, uint8_t blue)
-{
-	for (uint8_t i = 0; i < 8; i++) {
-		_data[i] = (green & (1 << (7 - i))) ? LED_T1 : LED_T0;
-	}
-
-	for (uint8_t i = 0; i < 8; i++) {
-		_data[8 + i] = (red & (1 << (7 - i))) ? LED_T1 : LED_T0;
-	}
-
-	for (uint8_t i = 0; i < 8; i++) {
-		_data[16 + i] = (blue & (1 << (7 - i))) ? LED_T1 : LED_T0;
-	}
-}
-
-int NavigatorLED::write(uint8_t red, uint8_t green, uint8_t blue)
-{
-	_setup_data(red, green, blue);
-
-	px4_sem_wait(&_sem);
-
-	int ret = transfer(_data, nullptr, sizeof(_data));
-
-	px4_sem_post(&_sem);
-
-	if (ret != PX4_OK) {
-		PX4_ERR("Failed to write data to NeoPixel %d", ret);
-	}
-
-	return ret;
-}
-
-int NavigatorLED::deinit()
-{
-	PX4_INFO("Neopixel deinitialized");
-	return PX4_OK;
-}
-
-// Neopixel driver impl
-
-NavigatorLED navigator_led;
-
-int neopixel_init(neopixel::NeoLEDData *led_data, int number_of_packages)
-{
-	return navigator_led.init();
-}
-
-int neopixel_write(neopixel::NeoLEDData *led_data, int number_of_packages)
-{
-	return navigator_led.write(led_data->R(), led_data->G(), led_data->B());
-}
-
-int neopixel_deinit()
-{
-	return navigator_led.deinit();
-}
-#endif // defined(BOARD_HAS_N_S_RGB_LED)
@@ -1,37 +0,0 @@
-############################################################################
-#
-#   Copyright (c) 2024 PX4 Development Team. All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions
-# are met:
-#
-# 1. Redistributions of source code must retain the above copyright
-#    notice, this list of conditions and the following disclaimer.
-# 2. Redistributions in binary form must reproduce the above copyright
-#    notice, this list of conditions and the following disclaimer in
-#    the documentation and/or other materials provided with the
-#    distribution.
-# 3. Neither the name PX4 nor the names of its contributors may be
-#    used to endorse or promote products derived from this software
-#    without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
-# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
-# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
-# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
-# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
-# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
-# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
-# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-# POSSIBILITY OF SUCH DAMAGE.
-#
-############################################################################
-
-add_library(drivers_board
-	i2c.cpp
-	spi.cpp
-)
@@ -1,40 +0,0 @@
-/****************************************************************************
- *
- *   Copyright (C) 2024 PX4 Development Team. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in
- *    the documentation and/or other materials provided with the
- *    distribution.
- * 3. Neither the name PX4 nor the names of its contributors may be
- *    used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
- * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
- * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
- * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- *
- ****************************************************************************/
-
-#include <px4_arch/i2c_hw_description.h>
-
-constexpr px4_i2c_bus_t px4_i2c_buses[I2C_BUS_MAX_BUS_ITEMS] = {
-	initI2CBusInternal(1),
-	initI2CBusInternal(4),
-	initI2CBusExternal(6),
-};
@@ -1,45 +0,0 @@
-/****************************************************************************
- *
- *   Copyright (C) 2024 PX4 Development Team. All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in
- *    the documentation and/or other materials provided with the
- *    distribution.
- * 3. Neither the name PX4 nor the names of its contributors may be
- *    used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
- * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
- * COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
- * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
- * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- *
- ****************************************************************************/
-
-#include <px4_arch/spi_hw_description.h>
-#include <drivers/drv_sensor.h>
-
-constexpr px4_spi_bus_t px4_spi_buses[SPI_BUS_MAX_BUS_ITEMS] = {
-	initSPIBus(1, {
-		initSPIDevice(DRV_MAG_DEVTYPE_MMC5983MA, 1),
-		initSPIDevice(DRV_IMU_DEVTYPE_ICM20602, 2),
-	}),
-	initSPIBus(0, {
-		initSPIDevice(DRV_DEVTYPE_UNUSED, 0),
-	}),
-};
@@ -77,7 +77,7 @@
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -71,7 +71,7 @@ void rgb_led(int r, int g, int b, int freqs)
 	if (!once) {
 		once = 1;

-		/* Enable Clock to Block */
+		/* Enabel Clock to Block */
 		modifyreg32(STM32_RCC_APB2ENR, 0, RCC_APB2ENR_TIM1EN);

 		/* Reload */
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -77,7 +77,7 @@
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -154,7 +154,7 @@ __EXPORT void board_peripheral_reset(int ms)
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -517,7 +517,7 @@ extern "C"
 *
 * Description:
 *   All kinetis architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -120,7 +120,7 @@ __END_DECLS
 #define GPIO_SPEKTRUM_P_EN          (GPIO_HIGHDRIVE | GPIO_OUTPUT_ONE | PIN_PORTA | PIN7)

 /* For binding the Spektrum 3-pin interfaces is used with it TX (output)
- * as an input Therefore we drive are UARTx_RX (normally an input) as an
+ * as an input Therefore we drive are UARTx_RX (normaly an input) as an
 * output
 */

@@ -289,7 +289,7 @@ __END_DECLS
 #define GPIO_USB_VBUS_VALID         /* PTE8 */ (GPIO_PULLUP | PIN_PORTE | PIN8)

 /* PWM input driver. Use FMU PWM14 pin
- * todo:design this
+ * todo:desing this
 */
 #define PWMIN_TIMER		0
 #define PWMIN_TIMER_CHANNEL	2
@@ -171,7 +171,7 @@ __EXPORT void board_peripheral_reset(int ms)
 *
 * Description:
 *   All Kinetis architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -513,7 +513,7 @@ extern "C"
 *
 * Description:
 *   All kinetis architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -120,7 +120,7 @@ __END_DECLS
 #define GPIO_SPEKTRUM_P_EN          (GPIO_HIGHDRIVE | GPIO_OUTPUT_ONE | PIN_PORTA | PIN7)

 /* For binding the Spektrum 3-pin interfaces is used with it TX (output)
- * as an input Therefore we drive are UARTx_RX (normally an input) as an
+ * as an input Therefore we drive are UARTx_RX (normaly an input) as an
 * output
 */

@@ -293,7 +293,7 @@ __END_DECLS
 #define GPIO_USB_VBUS_VALID         /* PTE8 */ (GPIO_PULLUP | PIN_PORTE | PIN8)

 /* PWM input driver. Use FMU PWM14 pin
- * todo:design this
+ * todo:desing this
 */
 #define PWMIN_TIMER		0
 #define PWMIN_TIMER_CHANNEL	2
@@ -171,7 +171,7 @@ __EXPORT void board_peripheral_reset(int ms)
 *
 * Description:
 *   All Kinetis architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -119,7 +119,7 @@ int s32k3xx_bringup(void)
 		PX4_ERR("btn_lower_initialize() failed: %d", ret);

 	} else {
-		PX4_INFO("btn_lower_initialize() successful");
+		PX4_INFO("btn_lower_initialize() succesful");
 	}

 #endif
@@ -133,7 +133,7 @@ int s32k3xx_bringup(void)
 		PX4_ERR("userled_lower_initialize() failed: %d", ret);

 	} else {
-		PX4_INFO("userled_lower_initialize() successful");
+		PX4_INFO("userled_lower_initialize() succesful");
 	}

 #endif
@@ -224,7 +224,7 @@ int s32k3xx_bringup(void)
 				PX4_ERR("nxffs_initialize() failed: %d", ret);

 			} else {
-				PX4_INFO("nxffs_initialize() successful");
+				PX4_INFO("nxffs_initialize() succesful");

 				/* Mount the file system at /mnt/qspi */

@@ -234,7 +234,7 @@ int s32k3xx_bringup(void)
 					PX4_ERR("nx_mount() failed: %d", ret);

 				} else {
-					PX4_INFO("nx_mount() successful");
+					PX4_INFO("nx_mount() succesful");
 				}
 			}

@@ -250,7 +250,7 @@ int s32k3xx_bringup(void)
 #    ifdef CONFIG_BCH

 			else {
-				PX4_INFO("ftl_initialize() successful");
+				PX4_INFO("ftl_initialize() succesful");

 				/* Use the minor number to create device paths */

@@ -267,7 +267,7 @@ int s32k3xx_bringup(void)
 					PX4_ERR("bchdev_register %s failed: %d", chardev, ret);

 				} else {
-					PX4_INFO("bchdev_register %s successful", chardev);
+					PX4_INFO("bchdev_register %s succesful", chardev);
 				}
 			}

@@ -85,7 +85,7 @@ static int s32k3xx_selftest_se050(void)
 	lpi2c1 = s32k3xx_i2cbus_initialize(1);

 	if (lpi2c1 != NULL) {
-		_info("s32k3xx_i2cbus_initialize() successful\n");
+		_info("s32k3xx_i2cbus_initialize() succesful\n");

 	} else {
 		error = true;
@@ -105,7 +105,7 @@ static int s32k3xx_selftest_se050(void)
 	ret = I2C_TRANSFER(lpi2c1, &se050_msg, 1);

 	if (ret == 0) {
-		_info("SE050 ACK successful\n");
+		_info("SE050 ACK succesful\n");

 	} else {
 		error = true;
@@ -119,7 +119,7 @@ static int s32k3xx_selftest_se050(void)
 	ret = s32k3xx_i2cbus_uninitialize(lpi2c1);

 	if (ret == 0) {
-		_info("s32k3xx_i2cbus_uninitialize() successful\n");
+		_info("s32k3xx_i2cbus_uninitialize() succesful\n");

 		/* Return error if we had any earlier, otherwise return result of
 		 * s32k3xx_i2cbus_uninitialize()
@@ -232,7 +232,7 @@ static int s32k3xx_selftest_can(void)

 	for (i = 0; i < 4; i++) {
 		if (s32k3xx_gpioread(errn_pins[i])) {
-			_info("CAN%d flag check successful\n", i);
+			_info("CAN%d flag check succesful\n", i);

 		} else {
 			error = true;
@@ -333,7 +333,7 @@ static int s32k3xx_selftest_sct(void)

 	for (i = 4; i < 6; i++) {
 		if (s32k3xx_gpioread(rxd_pins[i - 4])) {
-			_info("CAN%d RXD high check successful\n", i);
+			_info("CAN%d RXD high check succesful\n", i);

 		} else {
 			error = true;
@@ -355,7 +355,7 @@ static int s32k3xx_selftest_sct(void)

 	for (i = 4; i < 6; i++) {
 		if (!s32k3xx_gpioread(rxd_pins[i - 4])) {
-			_info("CAN%d RXD low check successful\n", i);
+			_info("CAN%d RXD low check succesful\n", i);

 		} else {
 			error = true;
@@ -432,7 +432,7 @@ void s32k3xx_selftest(void)
 #endif

 	if (!error) {
-		_info("s32k3xx_selftest() successful\n");
+		_info("s32k3xx_selftest() succesful\n");
 	}
 }

@@ -318,7 +318,7 @@ int s32k3xx_tja1153_initialize(int bus)
 	}

 	close(sock);
-	_info("CAN%d TJA1153 configuration successful\n", bus);
+	_info("CAN%d TJA1153 configuration succesful\n", bus);
 	return 0;
 }

@@ -37,7 +37,7 @@ fi
 hmc5883 -T -X -q start
 ist8308 -X -q start
 ist8310 -X -q start
-iis2mdc -X -q start
+lis2mdl -X -q start
 lis3mdl -X -q start
 qmc5883l -X -q start
 rm3100 -X -q start
@@ -300,7 +300,7 @@ __EXPORT int board_get_hw_revision()
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -63,7 +63,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -300,7 +300,7 @@ __EXPORT int board_get_hw_revision()
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -63,7 +63,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -77,7 +77,7 @@
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -61,7 +61,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The SP Racing H7 Extreme has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The SP Racing H7 Extreme has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -154,7 +154,7 @@ __EXPORT void board_peripheral_reset(int ms)
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -154,7 +154,7 @@ __EXPORT void board_peripheral_reset(int ms)
 *
 * Description:
 *   All STM32 architectures must provide the following entry point.  This entry point
- *   is called early in the initialization -- after all memory has been configured
+ *   is called early in the intitialization -- after all memory has been configured
 *   and mapped but before any devices have been initialized.
 *
 ************************************************************************************/
@@ -59,7 +59,7 @@
 *   2) BOOT=1: Boot address defined by user option byte BOOT_ADD1[15:0].
 *      ST programmed value: System bootloader at 0x1FF0:0000
 *
- * The Durandal has a Switch on board, the BOOT0 pin is at ground so by default,
+ * The Durandal has a Swtich on board, the BOOT0 pin is at ground so by default,
 * the STM32 will boot to address 0x0800:0000 in FLASH unless the swiutch is
 * drepresed, then the boot will be from 0x1FF0:0000
 *
@@ -62,7 +62,7 @@
 typedef struct {
 	uint32_t                hw_ver_rev; /* the version and revision */
 	const px4_hw_mft_item_t *mft;       /* The first entry */
-	uint32_t                entries;    /* the length of the list */
+	uint32_t                entries;    /* the lenght of the list */
 } px4_hw_mft_list_entry_t;

 typedef px4_hw_mft_list_entry_t *px4_hw_mft_list_entry;
@@ -713,10 +713,6 @@
        - [YawEstimatorStatus](msg_docs/YawEstimatorStatus.md)
        - [VehicleStatusV0](msg_docs/VehicleStatusV0.md)
    - [MAVLink Messaging](middleware/mavlink.md)
-      - [Adding Messages](mavlink/adding_messages.md)
-      - [Streaming Messages](mavlink/streaming_messages.md)
-      - [Receiving Messages](mavlink/receiving_messages.md)
-      - [Custom MAVLink Messages](mavlink/custom_messages.md)
      - [Standard Modes Protocol](mavlink/standard_modes.md)
    - [uXRCE-DDS (PX4-ROS 2/DDS Bridge)](middleware/uxrce_dds.md)
  - [Modules & Commands](modules/modules_main.md)
@@ -372,29 +372,3 @@ This section explains how you might manually run the same steps as the script (s
   ```sh
   CONFIG_PUBLIC_KEY1="../../../keys/public/public_key.pub"
   ```
-
-## Flight Review & Encrypted logs
-
-If your logs are secret enough to require encryption it is likely that you will not trust them on the public [Flight Review](../getting_started/flight_reporting.md) server (this is not particularly hardened against data loss or theft).
-
-::: info
-The public [Flight Review](../getting_started/flight_reporting.md) service does not support encrypted logs.
-If you wish to use the service you can use the tools here to download and decrypt the files first.
-:::
-
-This section explains how you can host a _private_ instance of the Flight Review server.
-This can use logs that you have downloaded and decrypted yourself, or you can include your private key in the server for automatic decryption of logs on upload.
-
-The steps are:
-
-1. Follow the Flight Review [installation and setup](https://github.com/PX4/flight_review?tab=readme-ov-file#installation-and-setup) instructions to clone and setup the server.
-2. Put your private key in the source code at: `flight_review/app/private_key/private_key.pem`
-3. Add this key location into the server config file: `flight_review/app/config_default.ini`.
-
-   The line to add should look something like this (for the file above):
-
-   ```sh
-   ulge_private_key = ../private_key/private_key.pem
-   ```
-
-4. Follow the Flight Review Instructions to start your server.
@@ -33,14 +33,22 @@ If needed you can also [get the source code specific to a particular release](..
 First we'll build a simulated target using a console environment.
 This allows us to validate the system setup before moving on to real hardware and an IDE.

-Navigate into the **PX4-Autopilot** directory and start [Gazebo SITL](../sim_gazebo_gz/index.md) using the following command:
+Navigate into the **PX4-Autopilot** directory.
+Depending on your operating system you will have installed either [Gazebo SITL](../sim_gazebo_gz/index.md) or [Gazebo Classic SITL](../sim_gazebo_classic/index.md) (if you don't know which you can try both).
+
+:::: tabs
+
+::: tab Gazebo
+Start [Gazebo SITL](../sim_gazebo_gz/index.md) using the following command:

 ```sh
 make px4_sitl gz_x500
 ```

-::: details  If you installed Gazebo Classic
-Start  [Gazebo Classic SITL](../sim_gazebo_classic/index.md) using the following command:
+:::
+
+::: tab Gazebo-Classic
+Start [Gazebo SITL](../sim_gazebo_gz/index.md) using the following command:

 ```sh
 make px4_sitl gazebo-classic
@@ -48,6 +56,8 @@ make px4_sitl gazebo-classic

 :::

+::::
+
 This will bring up the PX4 console:

 ![PX4 Console](../../assets/toolchain/console_gazebo.png)
@@ -63,9 +73,19 @@ The drone can be flown by typing the following command (as shown in the console
 pxh> commander takeoff
 ```

-The vehicle will take off and you'll see this in the Gazebo simulator UI:
+The vehicle will take off and you'll see this in the simulator UI:

+:::: tabs
+
+::: tab Gazebo
 ![Gazebo UI with vehicle taking off](../../assets/toolchain/gazebo_takeoff.png)
+:::
+
+::: tab Gazebo-Classic
+![Gazebo Classic UI with vehicle taking off](../../assets/toolchain/gazebo_classic_takeoff.png)
+:::
+
+::::

 The drone can be landed by typing `commander land` and the whole simulation can be stopped by doing **CTRL+C** (or by entering `shutdown`).

@@ -1,23 +1,20 @@
 # Ubuntu Development Environment

-The following instructions use a bash script to set up the PX4 development environment on the [Ubuntu Linux LTS](https://wiki.ubuntu.com/LTS) versions supported by PX4: Ubuntu 24.04 (Nimble Numbat) and Ubuntu 22.04 (Jammy Jellyfish).
+The following instructions use a bash script to set up the PX4 development environment on the [Ubuntu Linux LTS](https://wiki.ubuntu.com/LTS) versions supported by PX4: Ubuntu 22.04 (Jammy Jellyfish), 20.04 (Focal Fossa), and 18.04 (Bionic Beaver).

 The environment includes:

- [Gazebo Simulator](../sim_gazebo_gz/index.md) ("Harmonic")
+- [Gazebo Simulator](../sim_gazebo_gz/index.md) ("Harmonic") on Ubuntu 22.04
+- [Gazebo Classic Simulator](../sim_gazebo_classic/index.md) on Ubuntu 20.04 and Ubuntu 18.04
 - [Build toolchain for Pixhawk (and other NuttX-based hardware)](../dev_setup/building_px4.md#nuttx-pixhawk-based-boards).

-On Ubuntu 22.04:
-
- [Gazebo Classic Simulator](../sim_gazebo_classic/index.md) can be used instead of Gazebo.
-  Gazebo is nearing feature-parity with Gazebo-Classic on PX4, and will soon replace it for all use cases.
-
+::: info
 The build toolchain for other flight controllers, simulators, and working with ROS are discussed in the [Other Targets](#other-targets) section below.
+:::

-::: details Can I use an older version of Ubuntu?
-PX4 supports the current and last Ubuntu LTS release where possible.
-Older releases are not supported (so you can't raise defects against them), but may still work.
-For example, Gazebo Classic setup is included in our standard build instructions for macOS, Ubuntu 18.04 and 20.04, and Windows on WSL2 for the same hosts.
+::: tip
+if you need to use Gazebo on Ubuntu 20.04 you can [manually install Gazebo "Garden"](../sim_gazebo_gz/index.md#installation-ubuntu-linux), with the caveat that this is end-of-life in November 2024.
+If you want to use Gazebo Classic on Ubuntu 22.04 (say) then you can manually install it by following the instructions in [Gazebo Classic > Installation](../sim_gazebo_classic/index.md#installation).
 :::

 ## Simulation and NuttX (Pixhawk) Targets
@@ -41,7 +38,7 @@ To install the toolchain:
   If working with an older version of PX4 you may need to [get the source code specific to your release](../contribute/git_examples.md#get-a-specific-release).
   :::

-2. Run the **ubuntu.sh** with no arguments (in a bash shell) to install everything:
+1. Run the **ubuntu.sh** with no arguments (in a bash shell) to install everything:

   ```sh
   bash ./PX4-Autopilot/Tools/setup/ubuntu.sh
@@ -50,9 +47,7 @@ To install the toolchain:
   - Acknowledge any prompts as the script progress.
   - You can use the `--no-nuttx` and `--no-sim-tools` options to omit the NuttX and/or simulation tools.

-3. If you need Gazebo Classic (Ubuntu 22.04 only) then you can manually remove Gazebo and install it by following the instructions in [Gazebo Classic > Installation](../sim_gazebo_classic/index.md#installation).
-
-4. Restart the computer on completion.
+1. Restart the computer on completion.

 :::details Additional notes
 These notes are provided "for information only":
@@ -64,8 +59,8 @@ These notes are provided "for information only":
  ```sh
  $arm-none-eabi-gcc --version

-  arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009
-  Copyright (C) 2023 Free Software Foundation, Inc.
+  arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)
+  Copyright (C) 2019 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  ```
@@ -81,6 +76,17 @@ These notes are provided "for information only":

  :::

+## Video Guide
+
+This video shows how to install the toolchain for NuttX and simulation targets ([as covered below](#simulation-and-nuttx-pixhawk-targets)) along with the basic testing covered in [Building PX4 Software](../dev_setup/building_px4.md).
+
+::: warning
+The video suggests that you build source using JMAVSim, entering the command: `make px4_sitl jmavsim`.
+As JMAVSim is now community-supported, you should instead build using Gazebo or Gazebo Classic, as shown in [Building the Code](../dev_setup/building_px4.md#first-build-using-a-simulator)
+:::
+
+<lite-youtube videoid="OtValQdAdrU" title=" Setting up your PX4 development environment on Linux"/>
+
 ## Other Targets

 The Ubuntu development environment for ROS, other simulators, and other hardware targets, is covered in their respective documentation.
@@ -5,7 +5,7 @@
 There are a number of reasons to use VSCode for PX4 development:

 - Getting setup _really_ only takes a few minutes.
- A rich extension ecosystem that enables a huge range of tools needed for PX4 development: C/C++ (with solid _cmake_ integration), _Python_, _Jinja2_, ROS messages, and even DroneCAN DSDL.
+- A rich extension ecosystem that enables a huge range of tools needed for PX4 development: C/C++ (with solid _cmake_ integration), _Python_, _Jinja2_, ROS messages, and even DroneCAN dsdl.
 - Excellent Github integration.

 This topic explains how to setup the IDE and start developing.
@@ -25,9 +25,7 @@ You must already have installed the command line [PX4 developer environment](../
 1. Open VSCode and add the PX4 source code:

   - Select _Open folder ..._ option on the welcome page (or using the menu: **File > Open Folder**):
-
     ![Open Folder](../../assets/toolchain/vscode/welcome_open_folder.jpg)
-
   - A file selection dialog will appear.
     Select the **PX4-Autopilot** directory and then press **OK**.

@@ -13,11 +13,6 @@ Logs can be downloaded using [QGroundControl](http://qgroundcontrol.com/): **[An

 ![Flight Log Download](../../assets/qgc/analyze/log_download.jpg)

-::: tip
-Encrypted logs cannot be downloaded with QGroundControl, or uploaded to the public Flight Review service.
-The easiest way to download and extract encrypted logs is to use the [Log Encryption Tools](../dev_log/log_encryption.md).
-You can also host a [private Flight Review server](../dev_log/log_encryption.md#flight-review-encrypted-logs) that automatically decrypts logs on upload using your private key.
-:::

 ## Analyzing the Logs

@@ -30,9 +25,9 @@ After upload you'll be emailed a link to the analysis page for the log.
 There are many other great tools for visualising and analysing PX4 Logs.
 For more information see: [Flight Analysis](../dev_log/flight_log_analysis.md).
 :::
-
+  
 :::tip
-If you have a constant high-rate MAVLink connection to the vehicle (not just a telemetry link) then you can use _QGroundControl_ to automatically upload logs directly to _Flight Review_.
+If you have a constant high-rate MAVLink connection to the vehicle (not just a telemetry link) then you can use *QGroundControl* to automatically upload logs directly to *Flight Review*.
 For more information see [Settings > MAVLink Settings > MAVLink 2 Logging (PX4 only)](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/settings_view/mavlink.html#logging).
 :::

@@ -40,6 +35,7 @@ For more information see [Settings > MAVLink Settings > MAVLink 2 Logging (PX4 o

 The [Flight Review](http://logs.px4.io) log file link can be shared for discussion in the [support forums](../contribute/support.md#forums-and-chat) or a [Github issue](../index.md#reporting-bugs-issues).

+
 ## Log Configuration

 The logging system is configured by default to collect sensible logs for use with [Flight Review](http://logs.px4.io).
@@ -1,96 +0,0 @@
-# Adding Standard MAVLink Definitions (Messages/Commands)
-
-This topic explains how to add new MAVLink messages and commands that are expected to be _part of_ the normal PX4 build.
-
-## Standard MAVLink Messages
-
-The PX4/PX4-Autopilot source code uses only messages that have been standardized by MAVLink.
-That is to say, the standard definitions in [common.xml](https://mavlink.io/en/messages/common.html) in releases, and [development.xml](https://mavlink.io/en/messages/development.html) during development.
-These messages are present in at least one significant flight stack, and members of other flight stacks have accepted them as a reasonable design that would likely be adopted if the same functionality was required.
-
-::: tip
-A [Custom MAVLink Message](../mavlink/custom_messages.md) is one that isn't part of the standard.
-These are defined in your own XML as part of your own fork of PX4.
-If you use [custom MAVLink messages](../mavlink/custom_messages.md) you will need maintain the definitions in PX4, your ground station, and any other SDKs that communicate with it.
-Generally you should use (or add to) the standard definitions if at all possible to reduce the maintenance burden.
-:::
-
-New standard definitions are added first to `development.xml`, and then moved to `common.xml` following review and prototyping, and acceptance by the MAVLink team.
-
-If you intend your message to become part of the default PX4 build you will need to propose it to the MAVLink community by submitting a pull request (PR) to [development.xml](https://github.com/mavlink/mavlink/blob/master/message_definitions/v1.0/development.xml).
-The [MAVLink Developer guide](https://mavlink.io/en/getting_started/) explains how to define new messages in [How to Define MAVLink Messages & Enums](https://mavlink.io/en/guide/define_xml_element.html).
-
-## Generating Message Headers
-
-During development you can add your definitions to `PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0/development.xml` (or pull them from MAVLink).
-
-When you build PX4, header files for these message definitions are generated in the build directory (`/build/<build target>/mavlink/`).
-If headers are not build for your messages, they may be incorrectly formatted, or use clashing ids.
-Inspect the build log for information.
-
-## Implementing Message Senders/Receivers
-
-Once the message headers for your definitions are generated in the PX4 build, you can use them in your code to send and receive the messages:
-
- [Streaming MAVLink Messages](../mavlink/streaming_messages.md)
- [Receiving MAVLink Messages](../mavlink/receiving_messages.md)
-
-## Testing
-
-The first step in debugging is to confirm that any messages you've created are being sent/received as you expect.
-
-You should should first use the `uorb top [<message_name>]` command to verify in real-time that your message is published and the rate (see [uORB Messaging](../middleware/uorb.md#uorb-top-command)).
-This approach can also be used to test incoming messages that publish a uORB topic (for other messages you might use `printf` in your code and test in SITL).
-
-There are several approaches you can use to view MAVLink traffic:
-
- Create a [Wireshark MAVLink plugin](https://mavlink.io/en/guide/wireshark.html) for your dialect.
-  This allows you to inspect MAVLink traffic on an IP interface - for example between _QGroundControl_ or MAVSDK and your real or simulated version of PX4.
-
-  :::tip
-  It is much easier to generate a wireshark plugin and inspect traffic in Wireshark, than to rebuild QGroundControl with your dialect and use MAVLink Inspector.
-  :::
-
- [Log uORB topics](../dev_log/logging.md) associate with your MAVLink message.
- View received messages in the QGroundControl [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_inspector.html).
-  You will need to [rebuild QGroundControl with the new message definitions](#updating-ground-stations).
-
-### Set Streaming Rate using a Shell
-
-For testing, it is sometimes useful to increase the streaming rate of individual topics at runtime (e.g. for inspection in QGC).
-This can be achieved using by calling the [mavlink](../modules/modules_communication.md#mavlink) module through the [QGC MAVLink console](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html) (or some other shell):
-
-```sh
-mavlink stream -u <port number> -s <mavlink topic name> -r <rate>
-```
-
-You can get the port number with `mavlink status` which will output (amongst others) `transport protocol: UDP (<port number>)`.
-An example would be:
-
-```sh
-mavlink stream -u 14556 -s CA_TRAJECTORY -r 300
-```
-
-## Updating Ground Stations
-
-Ultimately you'll want to use your new MAVLink interface by providing the corresponding ground station or MAVSDK implementation.
-
-The important thing to remember here is that MAVLink requires that you use a version of the library that is built to the same definition (XML file).
-So if you have created a custom message in PX4 you won't be able to use it unless you build QGC or MAVSDK with that same definition.
-
-### Updating QGroundControl
-
-You will need to [Build QGroundControl](https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/getting_started/index.html) including a pre-built C library that contains your custom messages.
-
-QGC uses a pre-built C library that must be located at [/qgroundcontrol/libs/mavlink/include/mavlink](https://github.com/mavlink/qgroundcontrol/tree/master/libs/mavlink/include/mavlink) in the QGC source.
-
-By default this is pre-included as a submodule from <https://github.com/mavlink/c_library_v2> but you can [generate your own MAVLink Libraries](https://mavlink.io/en/getting_started/generate_libraries.html).
-
-QGC uses the **all.xml** dialect by default, which includes **common.xml**.
-You can include your messages in either file.
-
-Note that if you use your own _custom dialect_ then it should include **ArduPilotMega.xml** (or it will miss all the existing messages), and you will need to change the dialect used by setting it in [`MAVLINK_CONF`](https://github.com/mavlink/qgroundcontrol/blob/master/QGCExternalLibs.pri#L52) when running _qmake_.
-
-### Updating MAVSDK
-
-See the MAVSDK docs for information about how to work with [MAVLink headers and dialects](https://mavsdk.mavlink.io/main/en/cpp/guide/build.html).
@@ -1,49 +0,0 @@
-# Custom MAVLink Messages
-
-A custom [MAVLink message](../middleware/mavlink.md) is one that isn't in the standard MAVLink definitions that are included into PX4 by default.
-
-::: info
-If you use a custom definition you will fork and maintain PX4, your ground station, and any other SDKs that communicate with it.
-Generally you should use (or add to) the standard definitions if at all possible to reduce the maintenance burden.
-:::
-
-## Adding Custom XML
-
-Custom definitions can be added in a new dialect file in the same directory as [when using the standard XML definitions](../mavlink/adding_messages.md).
-For example, create `PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0/custom_messages.xml`, and set `CONFIG_MAVLINK_DIALECT` to build the new file for SITL.
-This dialect file should include `development.xml` so that all the standard definitions are also included.
-
-For initial prototyping, or if you intend your message to be "standard", you can also add your messages to `common.xml` (or `development.xml`).
-This simplifies building, because you don't need to modify the dialect that is built.
-
-The MAVLink developer guide explains how to define new messages in [How to Define MAVLink Messages & Enums](https://mavlink.io/en/guide/define_xml_element.html).
-
-You can check that your new messages are built by inspecting the headers generated in the build directory (`/build/<build target>/mavlink/`).
-If your messages are not built they may be incorrectly formatted, or use clashing ids.
-Inspect the build log for information.
-
-Once the message is being built you can stream, receive, or otherwise use it, as described in the following sections.
-
-::: info
-The [MAVLink Developer guide](https://mavlink.io/en/getting_started/) has more information about using the MAVLink toolchain.
-:::
-
-## Alternative to Creating Custom MAVLink Messages
-
-Sometimes there is the need for a custom MAVLink message with content that is not fully defined.
-
-For example when using MAVLink to interface PX4 with an embedded device, the messages that are exchanged between the autopilot and the device may go through several iterations before they are stabilized.
-In this case, it can be time-consuming and error-prone to regenerate the MAVLink headers, and make sure both devices use the same version of the protocol.
-
-An alternative - and temporary - solution is to re-purpose debug messages.
-Instead of creating a custom MAVLink message `CA_TRAJECTORY`, you can send a message `DEBUG_VECT` with the string key `CA_TRAJ` and data in the `x`, `y` and `z` fields.
-See [this tutorial](../debug/debug_values.md) for an example usage of debug messages.
-
-::: info
-This solution is not efficient as it sends character string over the network and involves comparison of strings.
-It should be used for development only!
-:::
-
-## Testing & Updating Ground Stations
-
-Testing the code and updating ground stations is done in the same way as when [Adding New Standard MAVLink Definitions ](../mavlink/adding_messages.md).
@@ -1,85 +0,0 @@
-# Receiving MAVLink Messages
-
-This topic explains how to receive a [MAVLink message](../middleware/mavlink.md) and publish it to uORB.
-
-## Overview
-
-The topic shows how we would handle a received `BATTERY_STATUS_DEMO` message (as defined in [Streaming MAVLink Messages](../mavlink/streaming_messages.md)) and then update the (existing) [BatteryStatus uORB message](../msg_docs/BatteryStatus.md) with the contained information.
-
-This is the kind of implementation that you would provide to support a MAVLink battery integration with PX4.
-
-## Steps
-
-Add the headers for the uORB topic to publish to in [mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L77):
-
-```cpp
-#include <uORB/topics/battery_status.h>
-```
-
-Add a function signature for a function that handles the incoming MAVLink message in the `MavlinkReceiver` class in
-[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L126)
-
-```cpp
-void handle_message_battery_status_demo(mavlink_message_t *msg);
-```
-
-Normally you would add a uORB publisher for the uORB topic to publish in the `MavlinkReceiver` class in
-[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L296).
-In this case the [BatteryStatus](../msg_docs/BatteryStatus.md) uORB topic already exists:
-
-```cpp
-uORB::Publication<battery_status_s> _battery_pub{ORB_ID(battery_status)};
-```
-
-This creates a publication to a single uORB topic instance, which by default will be the _first_ instance.
-
-::: info
-This implementation won't work on multi-battery systems, because several batteries might be publishing data to the first instance of the topic, and there is no way to differentiate them.
-To support multiple batteries we'd need to use `PublicationMulti` and map the MAVLink message instance IDs to specific uORB topic instances.
-:::
-
-Implement the `handle_message_battery_status_demo` function in [mavlink_receiver.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp).
-
-```cpp
-void
-MavlinkReceiver::handle_message_battery_status_demo(mavlink_message_t *msg)
-{
-	if ((msg->sysid != mavlink_system.sysid) || (msg->compid == mavlink_system.compid)) {
-		// ignore battery status coming from other systems or from the autopilot itself
-		return;
-	}
-
-	// external battery measurements
-	mavlink_battery_status_t battery_mavlink;
-	mavlink_msg_battery_status_decode(msg, &battery_mavlink);
-
-	battery_status_s battery_status{};
-	battery_status.timestamp = hrt_absolute_time();
-
-	battery_status.remaining = (float)battery_mavlink.battery_remaining / 100.0f;
-	battery_status.temperature = (float)battery_mavlink.temperature;
-	battery_status.connected = true;
-
-	_battery_pub.publish(battery_status);
-}
-```
-
-::: info
-Above we only write to the battery fields that are defined in the topic.
-In practice you'd update all fields with either valid or invalid values: this has been cut back for brevity.
-:::
-
-and finally make sure it is called in [MavlinkReceiver::handle_message()](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp#L228)
-
-```cpp
-MavlinkReceiver::handle_message(mavlink_message_t *msg)
- {
-    switch (msg->msgid) {
-        ...
-    case MAVLINK_MSG_ID_BATTERY_STATUS_DEMO:
-        handle_message_battery_status_demo(msg);
-        break;
-        ...
-    }
- }
-```
@@ -1,257 +0,0 @@
-# Streaming MAVLink Messages
-
-This tutorial demonstrates how to stream a uORB message as a MAVLink message, and applies to both standard and custom messages.
-
-## Overview
-
-[MAVLink messages](../middleware/mavlink.md) are streamed using a streaming class, derived from `MavlinkStream`, that has been added to the PX4 stream list.
-The class has framework methods that you implement so PX4 can get information it needs from the generated MAVLink message definition.
-It also has a `send()` method that is called each time the message needs to be sent — you override this to copy information from a uORB subscription to the MAVLink message object that is to be sent.
-
-Once you have created a streaming class the corresponding message can be streamed on request.
-You can also configure PX4 to stream the message by default, depending on the MAVLink configuration.
-
-## Preconditions
-
-Generally you will already have a [uORB](../middleware/uorb.md) message that contains information you'd like to stream and a definition of a MAVLink message that you'd like to stream it with.
-
-For this example we're going to assume that you want to stream the (existing) [BatteryStatus](../msg_docs/BatteryStatus.md) uORB message to a new MAVLink battery status message, which we will name `BATTERY_STATUS_DEMO`.
-
-Copy this `BATTERY_STATUS_DEMO` message into the message section of `development.xml` in your PX4 source code, which will be located at: `\src\modules\mavlink\mavlink\message_definitions\v1.0\development.xml`.
-
-```xml
-    <message id="11514" name="BATTERY_STATUS_DEMO">
-      <description>Simple demo battery.</description>
-      <field type="uint8_t" name="id" instance="true">Battery ID</field>
-      <field type="int16_t" name="temperature" units="cdegC" invalid="INT16_MAX">Temperature of the whole battery pack (not internal electronics). INT16_MAX field not provided.</field>
-      <field type="uint8_t" name="percent_remaining" units="%" invalid="UINT8_MAX">Remaining battery energy. Values: [0-100], UINT8_MAX: field not provided.</field>
-    </message>
-```
-
-::: info
-Note that this is a cut-down version of the not-yet-implemented [BATTERY_STATUS_V2](https://mavlink.io/en/messages/development.html#BATTERY_STATUS_V2) message with randomly chosen unused id of `11514`.
-Here we've put the message in `development.xml`, which is fine for testing and if the message is intended to eventually be part of the standard message set, but you might also put a [custom message](../mavlink/custom_messages.md) in its own dialect file.
-:::
-
-Build PX4 for SITL and confirm that the associated message is generated in `/build/px4_sitl_default/mavlink/development/mavlink_msg_battery_status_demo.h`.
-
-Because `BatteryStatus` already exists you will not need to do anything to create or build it.
-
-## Define the Streaming Class
-
-First create a file named `BATTERY_STATUS_DEMO.hpp` for your streaming class (named after the message to stream) inside the [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams) directory.
-
-Add the headers for the uORB message(s) to the top of the file (the required MAVLink headers should already be available):
-
-```cpp
-#include <uORB/topics/battery_status.h>
-```
-
-::: info
-The uORB topic's snake-case header file is generated from the CamelCase uORB filename at build time.
-:::
-
-Then copy the streaming class definition below into the file:
-
-```cpp
-class MavlinkStreamBatteryStatusDemo : public MavlinkStream
-{
-public:
-    static MavlinkStream *new_instance(Mavlink *mavlink)
-    {
-        return new MavlinkStreamBatteryStatusDemo(mavlink);
-    }
-    const char *get_name() const
-    {
-        return MavlinkStreamBatteryStatusDemo::get_name_static();
-    }
-    static const char *get_name_static()
-    {
-        return "BATTERY_STATUS_DEMO";
-    }
-    static uint16_t get_id_static()
-    {
-        return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO;
-    }
-    uint16_t get_id()
-    {
-        return get_id_static();
-    }
-    unsigned get_size()
-    {
-        return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO_LEN + MAVLINK_NUM_NON_PAYLOAD_BYTES;
-    }
-
-private:
-    //Subscription to array of uORB battery status instances
-    uORB::SubscriptionMultiArray<battery_status_s, battery_status_s::MAX_INSTANCES> _battery_status_subs{ORB_ID::battery_status};
-    // SubscriptionMultiArray subscription is needed because battery has multiple instances.
-    // uORB::Subscription is used to subscribe to a single-instance topic
-
-    /* do not allow top copying this class */
-    MavlinkStreamBatteryStatusDemo(MavlinkStreamBatteryStatusDemo &);
-    MavlinkStreamBatteryStatusDemo& operator = (const MavlinkStreamBatteryStatusDemo &);
-
-protected:
-    explicit MavlinkStreamBatteryStatusDemo(Mavlink *mavlink) : MavlinkStream(mavlink)
-    {}
-
-	bool send() override
-	{
-		bool updated = false;
-
-		// Loop through _battery_status_subs (subscription to array of BatteryStatus instances)
-		for (auto &battery_sub : _battery_status_subs) {
-            // battery_status_s is a struct that can hold the battery object topic
-			battery_status_s battery_status;
-
-			// Update battery_status and publish only if the status has changed
-			if (battery_sub.update(&battery_status)) {
-                // mavlink_battery_status_demo_t is the MAVLink message object
-				mavlink_battery_status_demo_t bat_msg{};
-
-				bat_msg.id = battery_status.id - 1;
-				bat_msg.percent_remaining = (battery_status.connected) ? roundf(battery_status.remaining * 100.f) : -1;
-
-				// check if temperature valid
-				if (battery_status.connected && PX4_ISFINITE(battery_status.temperature)) {
-					bat_msg.temperature = battery_status.temperature * 100.f;
-				} else {
-					bat_msg.temperature = INT16_MAX;
-				}
-
-                //Send the message
-				mavlink_msg_battery_status_demo_send_struct(_mavlink->get_channel(), &bat_msg);
-				updated = true;
-			}
-		}
-
-		return updated;
-	}
-
-};
-```
-
-Most streaming classes are very similar (see examples in [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams)):
-
- The streaming class derives from [`MavlinkStream`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_stream.h) and is named using the pattern `MavlinkStream<CamelCaseMessageName>`.
- The `public` definitions are "near-boilerplate", allowing PX4 to get an instance of the class (`new_instance()`), and then to use it to fetch the name, id, and size of the message from the MAVLink headers (`get_name()`, `get_name_static()`, `get_id_static()`, `get_id()`, `get_size()`).
-  For your own streaming classes these can just be copied and modified to match the values for your MAVLink message.
- The `private` definitions subscribe to the uORB topics that need to be published.
-  In this case the uORB topic has multiple instances: one for each battery.
-  We use `uORB::SubscriptionMultiArray` to get an array of battery status subscriptions.
-
-  Here we also define constructors to prevent the definition being copied.
-
- The `protected` section is where the important work takes place!
-
-  Here we override the `send()` method, copying values from the subscribed uORB topic(s) into appropriate fields in the MAVLink message, and then send the message.
-
-  In this particular example we have an array of uORB instances `_battery_status_subs` (because we have multiple batteries).
-  We iterate the array and use `update()` on each subscription to check if the associated battery instance has changed (and update a structure with the current data).
-  This allows us to send the MAVLink message _only_ if the associated battery uORB topic has changed:
-
-  ```cpp
-  // Struct to hold current topic data.
-  battery_status_s battery_status;
-
-  // update() populates battery_status and returns true if the status has changed
-  if (battery_sub.update(&battery_status)) {
-     // Use battery_status to populate message and send
-  }
-  ```
-
-  If wanted to send a MAVLink message whether or not the data changed, we could instead use `copy()` as shown:
-
-  ```cpp
-  battery_status_s battery_status;
-  battery_sub.copy(&battery_status);
-  ```
-
-  ::: info
-  For a single-instance topic like [VehicleStatus](../msg_docs/VehicleStatus.md) we would subscribe like this:
-
-  ```cpp
-  // Create subscription _vehicle_status_sub
-  uORB::Subscription _vehicle_status_sub{ORB_ID(vehicle_status)};
-  ```
-
-  And we could use the resulting subscription in the same way with update or copy.
-
-  ```cpp
-  vehicle_status_s vehicle_status{}; // vehicle_status_s is the definition of the uORB topic
-  if (_vehicle_status_sub.update(&vehicle_status)) {
-    // Use the vehicle_status as it has been updated.
-  }
-  ```
-
-  :::
-
-Next we include our new class in [mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp#L2193).
-Add the line below to the part of the file where all the other streams are included:
-
-```cpp
-#include "streams/BATTERY_STATUS_DEMO.hpp"
-```
-
-Finally append the stream class to the `streams_list` at the bottom of
-[mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp)
-
-```C
-StreamListItem *streams_list[] = {
-...
-#if defined(BATTERY_STATUS_DEMO_HPP)
-    create_stream_list_item<MavlinkStreamBatteryStatusDemo>(),
-#endif // BATTERY_STATUS_DEMO_HPP
-...
-}
-```
-
-The class is now available for streaming, but won't be streamed by default.
-We cover that in the next sections.
-
-## Streaming by Default
-
-The easiest way to stream your messages by default (as part of a build) is to add them to [mavlink_main.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_main.cpp) in the appropriate message group.
-
-If you search in the file you'll find groups of messages defined in a switch statement:
-
- `MAVLINK_MODE_NORMAL`: Streamed to a GCS.
- `MAVLINK_MODE_ONBOARD`: Streamed to a companion computer on a fast link, such as Ethernet
- `MAVLINK_MODE_ONBOARD_LOW_BANDWIDTH`: Streamed to a companion computer for re-routing to a reduced-traffic link, such as a GCS.
- `MAVLINK_MODE_GIMBAL`: Streamed to a gimbal
- `MAVLINK_MODE_EXTVISION`: Streamed to an external vision system
- `MAVLINK_MODE_EXTVISIONMIN`: Streamed to an external vision system on a slower link
- `MAVLINK_MODE_OSD`: Streamed to an OSD, such as an FPV headset.
- `MAVLINK_MODE_CUSTOM`: Stream nothing by default. Used when configuring streaming using MAVLink.
- `MAVLINK_MODE_MAGIC`: Same as `MAVLINK_MODE_CUSTOM`
- `MAVLINK_MODE_CONFIG`: Streaming over USB with higher rates than `MAVLINK_MODE_NORMAL`.
- `MAVLINK_MODE_MINIMAL`: Stream a minimal set of messages. Normally used for poor telemetry links.
- `MAVLINK_MODE_IRIDIUM`: Streamed to an iridium satellite phone
-
-Normally you'll be testing on a GCS, so you could just add the message to the `MAVLINK_MODE_NORMAL` case using the `configure_stream_local()` method.
-For example, to stream CA_TRAJECTORY at 5 Hz:
-
-```cpp
-	case MAVLINK_MODE_CONFIG: // USB
-		// Note: streams requiring low latency come first
-		...
-		configure_stream_local("BATTERY_STATUS_DEMO", 5.0f);
-        ...
-```
-
-It is also possible to add a stream by calling the [mavlink](../modules/modules_communication.md#mavlink) module with the `stream` argument in a [startup script](../concept/system_startup.md).
-For example, you might add the following line to [/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink) in order to stream `BATTERY_STATUS_DEMO` at 50Hz on UDP port `14556` (`-r` configures the streaming rate and `-u` identifies the MAVLink channel on UDP port 14556).
-
-```sh
-mavlink stream -r 50 -s BATTERY_STATUS_DEMO -u 14556
-```
-
-## Streaming on Request
-
-Some messages are only needed once, when particular hardware is connected, or under other circumstances.
-In order to avoid clogging communications links with messages that aren't needed you may not stream all messages by default, even at low rate.
-
-If you needed, a GCS or other MAVLink API can request that particular messages are streamed at a particular rate using [MAV_CMD_SET_MESSAGE_INTERVAL](https://mavlink.io/en/messages/common.html#MAV_CMD_SET_MESSAGE_INTERVAL).
-A particular message can be requested just once using [MAV_CMD_REQUEST_MESSAGE](https://mavlink.io/en/messages/common.html#MAV_CMD_REQUEST_MESSAGE).
-
@@ -5,15 +5,13 @@
 PX4 uses _MAVLink_ to communicate with ground stations and MAVLink SDKs, such as _QGroundControl_ and [MAVSDK](https://mavsdk.mavlink.io/), and as the integration mechanism for connecting to drone components outside of the flight controller: companion computers, MAVLink enabled cameras, and so on.

 This topic provides a brief overview of fundamental MAVLink concepts, such as messages, commands, and microservices.
-It also links instructions for how you can add PX4 support for:
+It also provides tutorial instructions for how you can add PX4 support for:

- [Adding Standard Messages](../mavlink/adding_messages.md)
- [Streaming MAVLink messages](../mavlink/streaming_messages.md)
- [Handling incoming MAVLink messages (and writing to a uORB topic)](../mavlink/receiving_messages.md)
- [Custom MAVLink Messages](../mavlink/custom_messages.md)
+- Streaming MAVLink messages
+- Handling incoming MAVLink messages and writing to a uORB topic.

 ::: info
-We do not yet cover _command_ handling and sending, or how to implement your own microservices.
+The topic does not cover _command_ handling and sending, or how to implement your own microservices.
 :::

 ## MAVLink Overview
@@ -85,3 +83,439 @@ The XML file for which headers files are generated may be defined in the [PX4 kc
 - For other boards `CONFIG_MAVLINK_DIALECT` is not set by default, and PX4 builds the definitions in `common.xml` (these are build into the [mavlink module](../modules/modules_communication.md#mavlink) by default — search for `menuconfig MAVLINK_DIALECT` in [src/modules/mavlink/Kconfig](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/Kconfig#L10)).

 The files are generated into the build directory: `/build/<build target>/mavlink/`.
+
+## Custom MAVLink Messages
+
+A custom MAVLink message is one that isn't in the default definitions included into PX4.
+
+::: info
+If you use a custom definition you will need maintain the definition in PX4, your ground station, and any other SDKs that communicate with it.
+Generally you should use (or add to) the standard definitions if at all possible to reduce the maintenance burden.
+:::
+
+Custom definitions can be added in a new dialect file in the same directory as the standard XML definitions.
+For example, create `PX4-Autopilot/src/modules/mavlink/mavlink/message_definitions/v1.0/custom_messages.xml`, and set `CONFIG_MAVLINK_DIALECT` to build the new file for SITL.
+This dialect file should include `development.xml` so that all the standard definitions are also included.
+
+For initial prototyping, or if you intend your message to be "standard", you can also add your messages to `common.xml` (or `development.xml`).
+This simplifies building, because you don't need to modify the dialect that is built.
+
+The MAVLink developer guide explains how to define new messages in [How to Define MAVLink Messages & Enums](https://mavlink.io/en/guide/define_xml_element.html).
+
+You can check that your new messages are built by inspecting the headers generated in the build directory (`/build/<build target>/mavlink/`).
+If your messages are not built they may be incorrectly formatted, or use clashing ids.
+Inspect the build log for information.
+
+Once the message is being built you can stream, receive, or otherwise use it, as described in the following sections.
+
+::: info
+The [MAVLink Developer guide](https://mavlink.io/en/getting_started/) has more information about using the MAVLink toolchain.
+:::
+
+## Streaming MAVLink Messages
+
+MAVLink messages are streamed using a streaming class, derived from `MavlinkStream`, that has been added to the PX4 stream list.
+The class has framework methods that you implement so PX4 can get information it needs from the generated MAVLink message definition.
+It also has a `send()` method that is called each time the message needs to be sent — you override this to copy information from a uORB subscription to the MAVLink message object that is to be sent.
+
+This tutorial demonstrates how to stream a uORB message as a MAVLink message, and applies to both standard and custom messages.
+
+### Preconditions
+
+Generally you will already have a [uORB](../middleware/uorb.md) message that contains information you'd like to stream and a definition of a MAVLink message that you'd like to stream it with.
+
+For this example we're going to assume that you want to stream the (existing) [BatteryStatus](../msg_docs/BatteryStatus.md) uORB message to a new MAVLink battery status message, which we will name `BATTERY_STATUS_DEMO`.
+
+Copy this `BATTERY_STATUS_DEMO` message into the message section of `development.xml` in your PX4 source code, which will be located at: `\src\modules\mavlink\mavlink\message_definitions\v1.0\development.xml`.
+
+```xml
+    <message id="11514" name="BATTERY_STATUS_DEMO">
+      <description>Simple demo battery.</description>
+      <field type="uint8_t" name="id" instance="true">Battery ID</field>
+      <field type="int16_t" name="temperature" units="cdegC" invalid="INT16_MAX">Temperature of the whole battery pack (not internal electronics). INT16_MAX field not provided.</field>
+      <field type="uint8_t" name="percent_remaining" units="%" invalid="UINT8_MAX">Remaining battery energy. Values: [0-100], UINT8_MAX: field not provided.</field>
+    </message>
+```
+
+::: info
+Note that this is a cut-down version of the not-yet-implemented [BATTERY_STATUS_V2](https://mavlink.io/en/messages/development.html#BATTERY_STATUS_V2) message with randomly chosen unused id of `11514`.
+Here we've put the message in `development.xml`, which is fine for testing and if the message is intended to eventually be part of the standard message set, but you might also put a [custom message](#custom-mavlink-messages) in its own dialect file.
+:::
+
+Build PX4 for SITL and confirm that the associated message is generated in `/build/px4_sitl_default/mavlink/development/mavlink_msg_battery_status_demo.h`.
+
+Because `BatteryStatus` already exists you will not need to do anything to create or build it.
+
+### Define the Streaming Class
+
+First create a file named `BATTERY_STATUS_DEMO.hpp` for your streaming class (named after the message to stream) inside the [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams) directory.
+
+Add the headers for the uORB message(s) to the top of the file (the required MAVLink headers should already be available):
+
+```cpp
+#include <uORB/topics/battery_status.h>
+```
+
+::: info
+The uORB topic's snake-case header file is generated from the CamelCase uORB filename at build time.
+:::
+
+Then copy the streaming class definition below into the file:
+
+```cpp
+class MavlinkStreamBatteryStatusDemo : public MavlinkStream
+{
+public:
+    static MavlinkStream *new_instance(Mavlink *mavlink)
+    {
+        return new MavlinkStreamBatteryStatusDemo(mavlink);
+    }
+    const char *get_name() const
+    {
+        return MavlinkStreamBatteryStatusDemo::get_name_static();
+    }
+    static const char *get_name_static()
+    {
+        return "BATTERY_STATUS_DEMO";
+    }
+    static uint16_t get_id_static()
+    {
+        return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO;
+    }
+    uint16_t get_id()
+    {
+        return get_id_static();
+    }
+    unsigned get_size()
+    {
+        return MAVLINK_MSG_ID_BATTERY_STATUS_DEMO_LEN + MAVLINK_NUM_NON_PAYLOAD_BYTES;
+    }
+
+private:
+    //Subscription to array of uORB battery status instances
+    uORB::SubscriptionMultiArray<battery_status_s, battery_status_s::MAX_INSTANCES> _battery_status_subs{ORB_ID::battery_status};
+    // SubscriptionMultiArray subscription is needed because battery has multiple instances.
+    // uORB::Subscription is used to subscribe to a single-instance topic
+
+    /* do not allow top copying this class */
+    MavlinkStreamBatteryStatusDemo(MavlinkStreamBatteryStatusDemo &);
+    MavlinkStreamBatteryStatusDemo& operator = (const MavlinkStreamBatteryStatusDemo &);
+
+protected:
+    explicit MavlinkStreamBatteryStatusDemo(Mavlink *mavlink) : MavlinkStream(mavlink)
+    {}
+
+	bool send() override
+	{
+		bool updated = false;
+
+		// Loop through _battery_status_subs (subscription to array of BatteryStatus instances)
+		for (auto &battery_sub : _battery_status_subs) {
+            // battery_status_s is a struct that can hold the battery object topic
+			battery_status_s battery_status;
+
+			// Update battery_status and publish only if the status has changed
+			if (battery_sub.update(&battery_status)) {
+                // mavlink_battery_status_demo_t is the MAVLink message object
+				mavlink_battery_status_demo_t bat_msg{};
+
+				bat_msg.id = battery_status.id - 1;
+				bat_msg.percent_remaining = (battery_status.connected) ? roundf(battery_status.remaining * 100.f) : -1;
+
+				// check if temperature valid
+				if (battery_status.connected && PX4_ISFINITE(battery_status.temperature)) {
+					bat_msg.temperature = battery_status.temperature * 100.f;
+				} else {
+					bat_msg.temperature = INT16_MAX;
+				}
+
+                //Send the message
+				mavlink_msg_battery_status_demo_send_struct(_mavlink->get_channel(), &bat_msg);
+				updated = true;
+			}
+		}
+
+		return updated;
+	}
+
+};
+```
+
+Most streaming classes are very similar (see examples in [/src/modules/mavlink/streams](https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/mavlink/streams)):
+
+- The streaming class derives from [`MavlinkStream`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_stream.h) and is named using the pattern `MavlinkStream<CamelCaseMessageName>`.
+- The `public` definitions are "near-boilerplate", allowing PX4 to get an instance of the class (`new_instance()`), and then to use it to fetch the name, id, and size of the message from the MAVLink headers (`get_name()`, `get_name_static()`, `get_id_static()`, `get_id()`, `get_size()`).
+  For your own streaming classes these can just be copied and modified to match the values for your MAVLink message.
+- The `private` definitions subscribe to the uORB topics that need to be published.
+  In this case the uORB topic has multiple instances: one for each battery.
+  We use `uORB::SubscriptionMultiArray` to get an array of battery status subscriptions.
+
+  Here we also define constructors to prevent the definition being copied.
+
+- The `protected` section is where the important work takes place!
+
+  Here we override the `send()` method, copying values from the subscribed uORB topic(s) into appropriate fields in the MAVLink message, and then send the message.
+
+  In this particular example we have an array of uORB instances `_battery_status_subs` (because we have multiple batteries).
+  We iterate the array and use `update()` on each subscription to check if the associated battery instance has changed (and update a structure with the current data).
+  This allows us to send the MAVLink message _only_ if the associated battery uORB topic has changed:
+
+  ```cpp
+  // Struct to hold current topic data.
+  battery_status_s battery_status;
+
+  // update() populates battery_status and returns true if the status has changed
+  if (battery_sub.update(&battery_status)) {
+     // Use battery_status to populate message and send
+  }
+  ```
+
+  If wanted to send a MAVLink message whether or not the data changed, we could instead use `copy()` as shown:
+
+  ```cpp
+  battery_status_s battery_status;
+  battery_sub.copy(&battery_status);
+  ```
+
+  ::: info
+  For a single-instance topic like [VehicleStatus](../msg_docs/VehicleStatus.md) we would subscribe like this:
+
+  ```cpp
+  // Create subscription _vehicle_status_sub
+  uORB::Subscription _vehicle_status_sub{ORB_ID(vehicle_status)};
+  ```
+
+  And we could use the resulting subscription in the same way with update or copy.
+
+  ```cpp
+  vehicle_status_s vehicle_status{}; // vehicle_status_s is the definition of the uORB topic
+  if (_vehicle_status_sub.update(&vehicle_status)) {
+    // Use the vehicle_status as it has been updated.
+  }
+  ```
+
+  :::
+
+Next we include our new class in [mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp#L2193).
+Add the line below to the part of the file where all the other streams are included:
+
+```cpp
+#include "streams/BATTERY_STATUS_DEMO.hpp"
+```
+
+Finally append the stream class to the `streams_list` at the bottom of
+[mavlink_messages.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_messages.cpp)
+
+```C
+StreamListItem *streams_list[] = {
+...
+#if defined(BATTERY_STATUS_DEMO_HPP)
+    create_stream_list_item<MavlinkStreamBatteryStatusDemo>(),
+#endif // BATTERY_STATUS_DEMO_HPP
+...
+}
+```
+
+The class is now available for streaming, but won't be streamed by default.
+We cover that in the next sections.
+
+### Streaming by Default
+
+The easiest way to stream your messages by default (as part of a build) is to add them to [mavlink_main.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_main.cpp) in the appropriate message group.
+
+If you search in the file you'll find groups of messages defined in a switch statement:
+
+- `MAVLINK_MODE_NORMAL`: Streamed to a GCS.
+- `MAVLINK_MODE_ONBOARD`: Streamed to a companion computer on a fast link, such as Ethernet
+- `MAVLINK_MODE_ONBOARD_LOW_BANDWIDTH`: Streamed to a companion computer for re-routing to a reduced-traffic link, such as a GCS.
+- `MAVLINK_MODE_GIMBAL`: Streamed to a gimbal
+- `MAVLINK_MODE_EXTVISION`: Streamed to an external vision system
+- `MAVLINK_MODE_EXTVISIONMIN`: Streamed to an external vision system on a slower link
+- `MAVLINK_MODE_OSD`: Streamed to an OSD, such as an FPV headset.
+- `MAVLINK_MODE_CUSTOM`: Stream nothing by default. Used when configuring streaming using MAVLink.
+- `MAVLINK_MODE_MAGIC`: Same as `MAVLINK_MODE_CUSTOM`
+- `MAVLINK_MODE_CONFIG`: Streaming over USB with higher rates than `MAVLINK_MODE_NORMAL`.
+- `MAVLINK_MODE_MINIMAL`: Stream a minimal set of messages. Normally used for poor telemetry links.
+- `MAVLINK_MODE_IRIDIUM`: Streamed to an iridium satellite phone
+
+Normally you'll be testing on a GCS, so you could just add the message to the `MAVLINK_MODE_NORMAL` case using the `configure_stream_local()` method.
+For example, to stream CA_TRAJECTORY at 5 Hz:
+
+```cpp
+	case MAVLINK_MODE_CONFIG: // USB
+		// Note: streams requiring low latency come first
+		...
+		configure_stream_local("BATTERY_STATUS_DEMO", 5.0f);
+        ...
+```
+
+It is also possible to add a stream by calling the [mavlink](../modules/modules_communication.md#mavlink) module with the `stream` argument in a [startup script](../concept/system_startup.md).
+For example, you might add the following line to [/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink](https://github.com/PX4/PX4-Autopilot/blob/main/ROMFS/px4fmu_common/init.d-posix/px4-rc.mavlink) in order to stream `BATTERY_STATUS_DEMO` at 50Hz on UDP port `14556` (`-r` configures the streaming rate and `-u` identifies the MAVLink channel on UDP port 14556).
+
+```sh
+mavlink stream -r 50 -s BATTERY_STATUS_DEMO -u 14556
+```
+
+### Streaming on Request
+
+Some messages are only needed once, when particular hardware is connected, or under other circumstances.
+In order to avoid clogging communications links with messages that aren't needed you may not stream all messages by default, even at low rate.
+
+If you needed, a GCS or other MAVLink API can request that particular messages are streamed at a particular rate using [MAV_CMD_SET_MESSAGE_INTERVAL](https://mavlink.io/en/messages/common.html#MAV_CMD_SET_MESSAGE_INTERVAL).
+A particular message can be requested just once using [MAV_CMD_REQUEST_MESSAGE](https://mavlink.io/en/messages/common.html#MAV_CMD_REQUEST_MESSAGE).
+
+## Receiving MAVLink Messages
+
+This section explains how to receive a message over MAVLink and publish it to uORB.
+
+It assumes that we are receiving the `BATTERY_STATUS_DEMO` message and we want to update the (existing) [BatteryStatus uORB message](../msg_docs/BatteryStatus.md) with the contained information.
+This is the kind of implementation that you would provide to support a MAVLink battery integration with PX4.
+
+Add the headers for the uORB topic to publish to in [mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L77):
+
+```cpp
+#include <uORB/topics/battery_status.h>
+```
+
+Add a function signature for a function that handles the incoming MAVLink message in the `MavlinkReceiver` class in
+[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L126)
+
+```cpp
+void handle_message_battery_status_demo(mavlink_message_t *msg);
+```
+
+Normally you would add a uORB publisher for the uORB topic to publish in the `MavlinkReceiver` class in
+[mavlink_receiver.h](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.h#L296).
+In this case the [BatteryStatus](../msg_docs/BatteryStatus.md) uORB topic already exists:
+
+```cpp
+uORB::Publication<battery_status_s> _battery_pub{ORB_ID(battery_status)};
+```
+
+This creates a publication to a single uORB topic instance, which by default will be the _first_ instance.
+
+::: info
+This implementation won't work on multi-battery systems, because several batteries might be publishing data to the first instance of the topic, and there is no way to differentiate them.
+To support multiple batteries we'd need to use `PublicationMulti` and map the MAVLink message instance IDs to specific uORB topic instances.
+:::
+
+Implement the `handle_message_battery_status_demo` function in [mavlink_receiver.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp).
+
+```cpp
+void
+MavlinkReceiver::handle_message_battery_status_demo(mavlink_message_t *msg)
+{
+	if ((msg->sysid != mavlink_system.sysid) || (msg->compid == mavlink_system.compid)) {
+		// ignore battery status coming from other systems or from the autopilot itself
+		return;
+	}
+
+	// external battery measurements
+	mavlink_battery_status_t battery_mavlink;
+	mavlink_msg_battery_status_decode(msg, &battery_mavlink);
+
+	battery_status_s battery_status{};
+	battery_status.timestamp = hrt_absolute_time();
+
+	battery_status.remaining = (float)battery_mavlink.battery_remaining / 100.0f;
+	battery_status.temperature = (float)battery_mavlink.temperature;
+	battery_status.connected = true;
+
+	_battery_pub.publish(battery_status);
+}
+```
+
+::: info
+Above we only write to the battery fields that are defined in the topic.
+In practice you'd update all fields with either valid or invalid values: this has been cut back for brevity.
+:::
+
+and finally make sure it is called in [MavlinkReceiver::handle_message()](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_receiver.cpp#L228)
+
+```cpp
+MavlinkReceiver::handle_message(mavlink_message_t *msg)
+ {
+    switch (msg->msgid) {
+        ...
+    case MAVLINK_MSG_ID_BATTERY_STATUS_DEMO:
+        handle_message_battery_status_demo(msg);
+        break;
+        ...
+    }
+ }
+```
+
+## Alternative to Creating Custom MAVLink Messages
+
+Sometimes there is the need for a custom MAVLink message with content that is not fully defined.
+
+For example when using MAVLink to interface PX4 with an embedded device, the messages that are exchanged between the autopilot and the device may go through several iterations before they are stabilized.
+In this case, it can be time-consuming and error-prone to regenerate the MAVLink headers, and make sure both devices use the same version of the protocol.
+
+An alternative - and temporary - solution is to re-purpose debug messages.
+Instead of creating a custom MAVLink message `CA_TRAJECTORY`, you can send a message `DEBUG_VECT` with the string key `CA_TRAJ` and data in the `x`, `y` and `z` fields.
+See [this tutorial](../debug/debug_values.md) for an example usage of debug messages.
+
+::: info
+This solution is not efficient as it sends character string over the network and involves comparison of strings.
+It should be used for development only!
+:::
+
+## Testing
+
+As a first step, and while debugging, commonly you'll just want to confirm that any messages you've created are being sent/received as you expect.
+
+You should should first use the `uorb top [<message_name>]` command to verify in real-time that your message is published and the rate (see [uORB Messaging](../middleware/uorb.md#uorb-top-command)).
+This approach can also be used to test incoming messages that publish a uORB topic (for other messages you might use `printf` in your code and test in SITL).
+
+There are several approaches you can use to view MAVLink traffic:
+
+- Create a [Wireshark MAVLink plugin](https://mavlink.io/en/guide/wireshark.html) for your dialect.
+  This allows you to inspect MAVLink traffic on an IP interface - for example between _QGroundControl_ or MAVSDK and your real or simulated version of PX4.
+
+  :::tip
+  It is much easier to generate a wireshark plugin and inspect traffic in Wireshark, than to rebuild QGroundControl with your dialect and use MAVLink Inspector.
+  :::
+
+- [Log uORB topics](../dev_log/logging.md) associate with your MAVLink message.
+- View received messages in the QGroundControl [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_inspector.html).
+  You will need to rebuild QGroundControl with the custom message definitions, [as described below](#updating-qgroundcontrol)
+
+### Set Streaming Rate using a Shell
+
+For testing, it is sometimes useful to increase the streaming rate of individual topics at runtime (e.g. for inspection in QGC).
+This can be achieved using by calling the [mavlink](../modules/modules_communication.md#mavlink) module through the [QGC MAVLink console](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html) (or some other shell):
+
+```sh
+mavlink stream -u <port number> -s <mavlink topic name> -r <rate>
+```
+
+You can get the port number with `mavlink status` which will output (amongst others) `transport protocol: UDP (<port number>)`.
+An example would be:
+
+```sh
+mavlink stream -u 14556 -s CA_TRAJECTORY -r 300
+```
+
+## Updating Ground Stations
+
+Ultimately you'll want to use your new MAVLink interface by providing the corresponding ground station or MAVSDK implementation.
+
+The important thing to remember here is that MAVLink requires that you use a version of the library that is built to the same definition (XML file).
+So if you have created a custom message in PX4 you won't be able to use it unless you build QGC or MAVSDK with that same definition.
+
+### Updating QGroundControl
+
+You will need to [Build QGroundControl](https://docs.qgroundcontrol.com/master/en/qgc-dev-guide/getting_started/index.html) including a pre-built C library that contains your custom messages.
+
+QGC uses a pre-built C library that must be located at [/qgroundcontrol/libs/mavlink/include/mavlink](https://github.com/mavlink/qgroundcontrol/tree/master/libs/mavlink/include/mavlink) in the QGC source.
+
+By default this is pre-included as a submodule from <https://github.com/mavlink/c_library_v2> but you can [generate your own MAVLink Libraries](https://mavlink.io/en/getting_started/generate_libraries.html).
+
+QGC uses the all.xml dialect by default, which includes **common.xml**.
+You can include your messages in either file or in your own dialect.
+However if you use your own dialect then it should include ArduPilotMega.xml (or it will miss all the existing messages), and you will need to change the dialect used by setting it in [`MAVLINK_CONF`](https://github.com/mavlink/qgroundcontrol/blob/master/QGCExternalLibs.pri#L52) when running _qmake_.
+
+### Updating MAVSDK
+
+See the MAVSDK docs for information about how to work with [MAVLink headers and dialects](https://mavsdk.mavlink.io/main/en/cpp/guide/build.html).
@@ -192,13 +192,13 @@ ist8310 <command> [arguments...]

   status        print status info
 ```
-## iis2mdc
-Source: [drivers/magnetometer/iis2mdc](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/magnetometer/iis2mdc)
+## lis2mdl
+Source: [drivers/magnetometer/lis2mdl](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/magnetometer/lis2mdl)

-<a id="iis2mdc_usage"></a>
+<a id="lis2mdl_usage"></a>
 ### Usage
 ```
-iis2mdc <command> [arguments...]
+lis2mdl <command> [arguments...]
 Commands:
   start
     [-I]        Internal I2C bus(es)
@@ -1,9 +1,8 @@
 # Gazebo Classic Simulation

 :::warning
-[Gazebo](../sim_gazebo_gz/index.md) is nearing feature-parity with Gazebo Classic on PX4, and will soon replace it.
-Until then you can continue to use Gazebo-Classic on Ubuntu 22.04 for the few cases where you still need to.
-For more information see [PX4-Autopilot#23602: GZ Feature tracker](https://github.com/PX4/PX4-Autopilot/issues/23602).
+_Gazebo Classic_ is supported with PX4 up to Ubuntu Linux 20.04.
+In Ubuntu 22.04 and later you must use [Gazebo](../sim_gazebo_gz/index.md) (which was [formerly known](https://www.openrobotics.org/blog/2022/4/6/a-new-era-for-gazebo) as "Gazebo Ignition").
 :::

 Gazebo Classic is a powerful 3D simulation environment for autonomous robots that is particularly suitable for testing object-avoidance and computer vision.
@@ -33,8 +32,11 @@ See [Simulation](../simulation/index.md) for general information about simulator
 If you plan to use PX4 with ROS you **should follow the** [ROS Instructions](../simulation/ros_interface.md) to install both ROS and Gazebo Classic (and thereby avoid installation conflicts).
 :::

-The standard installation script ([/Tools/setup/ubuntu.sh](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/setup/ubuntu.sh)) installs the [Gazebo](../sim_gazebo_gz/index.md) (Harmonic) simulator.
-If you want to use Gazebo Classic on _Ubuntu 22.04 (only)_ you can use the following commands to remove Gazebo and then reinstall Gazebo-Classic 11:
+Gazebo Classic setup is included in our [standard build instructions](../dev_setup/dev_env.md) for macOS, Ubuntu 18.04 and 20.04, and Windows on WSL2 for the same hosts.
+
+For Ubuntu 22.04 LTS and later, the installation script ([/Tools/setup/ubuntu.sh](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/setup/ubuntu.sh)) installs the [Gazebo](../sim_gazebo_gz/index.md) simulator instead.
+
+If you want to use Gazebo Classic on Ubuntu 22.04 you can use the following commands to remove [Gazebo](../sim_gazebo_gz/index.md) (Harmonic) and then reinstall Gazebo-Classic 11:

 ```sh
 sudo apt remove gz-harmonic
@@ -45,10 +47,10 @@ sudo aptitude install gazebo libgazebo11 libgazebo-dev
 Note that `aptitude` is needed because it can resolve dependency conflicts (by removing certain packages) that `apt` is unable to handle.

 ::: tip
-You could also modify the installation script to install Gazebo Classic on Ubuntu 22.04 before it is run for the first time.
+You could also modify the installation script to install Gazebo Classic on later versions before it is run for the first time.
+:::

 Additional installation instructions can be found on [gazebosim.org](http://gazebosim.org/tutorials?cat=guided_b&tut=guided_b1).
-:::

 ## Running the Simulation

@@ -280,6 +282,8 @@ To enable/disable GPS noise:

 The next time you build/restart Gazebo Classic it will use the new GPS noise setting.

+
+
 ## Loading a Specific World

 PX4 supports a number of [Worlds](../sim_gazebo_classic/worlds.md), which are stored in [PX4-Autopilot/Tools/simulation/gazebo-classic/sitl_gazebo-classic/worlds](https://github.com/PX4/PX4-SITL_gazebo-classic/tree/main/worlds).
@@ -541,6 +545,8 @@ The build system enforces the correct GIT submodules, including the simulator.
 It will not overwrite changes in files in the directory.
 :::

+
+
 ## Further Information

 - [ROS with Gazebo Classic Simulation](../simulation/ros_interface.md)
@@ -314,7 +314,6 @@
  - [Joysticks](config/joystick.md)
  - [Data Links](data_links/index.md)
    - [MAVLink 텔레메트리(OSD/GCS) ](peripherals/mavlink_peripherals.md)
-
    - [텔레메트리 무선통신](telemetry/index.md)
      - [SiK 무선통신](telemetry/sik_radio.md)
        - [RFD900 (SiK) 텔레메트리](telemetry/rfd900_telemetry.md)
@@ -327,13 +326,9 @@
        - [ARK Electron Microhard Serial Telemetry Radio](telemetry/ark_microhard_serial.md)
        - [Holybro Microhard P900 Telemetry Radio](telemetry/holybro_microhard_p900_radio.md)
      - [CUAV P8 Telemetry Radio](telemetry/cuav_p8_radio.md)
-      - [J.Fi Wireless Telemetry Module](telemetry/jfi_telemetry.md)
      - [HolyBro XBP9X - Discontinued](telemetry/holybro_xbp9x_radio.md)
-
    - [FrSky 텔레메트리](peripherals/frsky_telemetry.md)
-
    - [TBS Crossfire (CRSF) Telemetry](telemetry/crsf_telemetry.md)
-
    - [Satellite Comms (Iridium/RockBlock)](advanced_features/satcom_roadblock.md)
  - [Power Systems](power_systems/index.md)
    - [Battery Estimation Tuning](config/battery.md)
@@ -846,4 +841,4 @@
  - [1.15 (stable)](releases/1.15.md)
  - [1.14](releases/1.14.md)
  - [1.13](releases/1.13.md)
-  - [1.12](releases/1.12.md)
+  - [1.12](releases/1.12.md)
@@ -43,9 +43,7 @@ The gimbal can be connected to _any free serial port_ using the instructions in
 For example, if the `TELEM2` port on the flight controller is unused you can connect it to the gimbal and set the following PX4 parameters:

 - [MAV_1_CONFIG](../advanced_config/parameter_reference.md#MAV_1_CONFIG) to **TELEM2** (if `MAV_1_CONFIG` is already used for a companion computer (say), use `MAV_2_CONFIG`).
- [MAV_1_MODE](../advanced_config/parameter_reference.md#MAV_1_MODE) to **Gimbal**
- [MAV_1_FLOW_CTRL](../advanced_config/parameter_reference.md#MAV_1_FLOW_CTRL) to **Off (0)** (very few gimbals will have RST/CST wires connected).
- [MAV_1_FORWARD](../advanced_config/parameter_reference.md#MAV_1_FORWARD) to **Enabled** (Note strictly necessary as forwarding is enabled when `MAV_1_MODE` is set to Gimbal).
+- [MAV_1_MODE](../advanced_config/parameter_reference.md#MAV_1_MODE) to **NORMAL**
 - [SER_TEL2_BAUD](../advanced_config/parameter_reference.md#SER_TEL2_BAUD) to manufacturer recommended baud rate.

 ### Multiple Gimbal Support
@@ -131,20 +131,6 @@ Additional notes:

 - Whether tuning is applied while flying or after landing can be [configured using parameters](#apply-tuning-when-in-air-landed).

-<div v-if="$frontmatter.frame === 'Multicopter'">
-
-## Autotuning Large Vehicles
-
-For big multicopter vehicles you may need to increase the desired raise time of the step response [MC_AT_RISE_TIME](../advanced_config/parameter_reference.md#MC_AT_RISE_TIME).
-This requires some trial and error as an appropriate rise time depends on both vehicle size and the rotor response.
-
-Note that if there are slow oscillations in pretuning it may mean that the attitude loop is too fast compared to the rate loop.
-In this case you should troubleshoot as described in [Drone oscillates when performing the pre-tuning test](#drone-oscillates-when-performing-the-pre-tuning-test).
-
-<!-- Fixed wing rise time is hardcoded (it's lower than on multirotors and is probably enough for most platforms). -->
-
-</div>
-
 ## 문제 해결

 ### Drone oscillates when performing the pre-tuning test
@@ -146,12 +146,6 @@ The Data Link Loss failsafe is triggered if a telemetry link (connection to grou
 | 데이터 연결불량 시간 초과 | [COM_DL_LOSS_T](../advanced_config/parameter_reference.md#COM_DL_LOSS_T) | 데이터 연결이 끊어진 후 안전 장치가 동작하기 전까지의 시간입니다.                           |
 | 안전장치 동작        | [NAV_DLL_ACT](../advanced_config/parameter_reference.md#NAV_DLL_ACT)                          | Disabled, Hold mode, Return mode, Land mode, Disarm, Terminate. |

-다음 설정도 가능하지만 QGC UI에 표시되지 않습니다.
-
-| 설정                                                          | 매개변수                                                                                                                 | 설명                                                                   |
-| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
-| <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. |
-
 ## Geofence 안전장치

 The _Geofence Failsafe_ is triggered when the drone breaches a "virtual" perimeter.
@@ -17,7 +17,7 @@ Simple changes to _existing content_ can be made by clicking the **Edit on GitHu

 ![Vitepress: Edit Page button](../../assets/vuepress/vuepress_edit_page_on_github_link.png)

-To edit an existing English page:
+기존 페이지를 편집하려면:

 1. 해당 페이지를 엽니다.
 2. Click the **Edit on GitHub** link below the page content.
@@ -26,32 +26,19 @@ To edit an existing English page:

 문서 팀은 요청을 검토하고, 병합하거나 업데이트하기 위하여 귀하와 협력할 것입니다.

-Note that you can only make changes to the English version directly in the source.
-[Translations are handled in Crowdin](../contribute/translation.md).
-
-## Changes using Git
+## Git을 사용한 변경(새 페이지 및 이미지)

 새 페이지 추가 또는 이미지 추가/수정을 포함하여 보다 실질적인 변경은 Github에서 수행(또는 적절하게 테스트)하는 것처럼 간단하지 않습니다.
-
 For these kinds of changes we suggest using the same approach as for _code_:

-1. Use the _git_ toolchain to get the PX4 source code onto your local computer.
+1. Use the _git_ toolchain to get the documentation source code onto your local computer.
 2. 필요한 문서를 수정합니다(추가, 변경, 삭제).
 3. _Test_ that it builds properly using Vitepress.
-4. Create a branch for your changes and create a pull request (PR) to pull it back into the [PX4-Autopilot](https://github.com/PX4/PX4-Autopilot.git) repo.
+4. 변경 사항에 대한 분기를 만들고 풀 요청을 만들어 문서로 다시 가져옵니다.

 다음에는 소스 코드를 가져오고, 로컬에서 빌드(테스트용)하고, 코드를 수정하는 방법을 설명합니다.

-### Get Documentation Source Code
-
-Documentation sources are in the [PX4-Autopilot](https://github.com/PX4/PX4-Autopilot/) repo, alongside all the other PX4 source code.
-The sources are markdown files located the [/docs](https://github.com/PX4/PX4-Autopilot/tree/main/docs) subdirectory.
-The English source files are in the [/docs/en/](https://github.com/PX4/PX4-Autopilot/tree/main/docs/en) subdirectory and can be edited directly.
-[Translation](../contribute/translation.md) sources are in language specific subdirectories, such as `ko` for korean and `zh` for Chinese: these are edited via the Crowdin tool, and should not be edited directly.
-
-:::tip
-If you already have a clone of the [PX4-Autopilot](https://github.com/PX4/PX4-Autopilot/) you can ignore this section.
-:::
+### 문서 소스 코드 가져오기/보내기

 라이브러리 소스를 로컬 컴퓨터로 가져오려면 git 명령어를 사용하여야 합니다.
 아래 지침은 git을 가져와 로컬 컴퓨터에서 사용하는 방법을 설명합니다.
@@ -60,31 +47,31 @@ If you already have a clone of the [PX4-Autopilot](https://github.com/PX4/PX4-Au

 2. [Sign up](https://github.com/join) for Github if you haven't already

-3. Create a copy (Fork) of the [PX4-Autopilot repo](https://github.com/PX4/PX4-Autopilot) on Github ([instructions here](https://docs.github.com/en/get-started/quickstart/fork-a-repo)).
+3. Create a copy (Fork) of the [PX4 User Guide repo](https://github.com/PX4/PX4-user_guide) on Github ([instructions here](https://docs.github.com/en/get-started/quickstart/fork-a-repo)).

 4. 복사된 저장소를 로컬 컴퓨터에 복제합니다.

  ```sh
  cd ~/wherever/
-  git clone https://github.com/<your git name>/PX4-Autopilot.git
+  git clone https://github.com/<your git name>/PX4-user_guide.git
  ```

-  For example, to clone PX4 source fork for a user with Github account "john_citizen":
+  예를 들어, Github 계정이 "john_citizen"인 사용자의 PX4 사용자 가이드 포크를 복제합니다.

  ```sh
-  git clone https://github.com/john_citizen/PX4-Autopilot.git
+  git clone https://github.com/john_citizen/PX4-user_guide.git
  ```

 5. 로컬 저장소로 이동합니다.

  ```sh
-  cd ~/wherever/PX4-Autopilot
+  cd ~/wherever/PX4-user_guide
  ```

-6. Add a _remote_ called "upstream" to point to the "official" PX4 version of the library:
+6. Add a _remote_ called "upstream" to point to the PX4 version of the library:

  ```sh
-  git remote add upstream https://github.com/PX4/PX4-Autopilot.git
+  git remote add upstream https://github.com/PX4/PX4-user_guide.git
  ```

  :::tip
@@ -94,19 +81,7 @@ If you already have a clone of the [PX4-Autopilot](https://github.com/PX4/PX4-Au

 :::

-### Make/Push Documentation Changes
-
-Within the repository you created above:
-
-1. Bring your copy of the repository `main` branch up to date:
-
-  ```sh
-  git checkout main
-  git fetch upstream main
-  git pull upstream main
-  ```
-
-2. Create a new branch for your changes:
+7. 변경 사항에 대한 브랜치를 생성합니다.

  ```sh
  git checkout -b <your_feature_branch_name>
@@ -114,9 +89,9 @@ Within the repository you created above:

  This creates a local branch on your computer named `your_feature_branch_name`.

-3. 필요에 따라 문서를 변경합니다(다음 섹션에서 이에 대한 일반 지침).
+8. 필요에 따라 문서를 변경합니다(다음 섹션에서 이에 대한 일반 지침).

-4. 변경 사항에 완료되면 "커밋"을 사용하여, 로컬 브랜치에 추가합니다.
+9. 변경 사항에 완료되면 "커밋"을 사용하여, 로컬 브랜치에 추가합니다.

  ```sh
  git add <file name>
@@ -125,26 +100,23 @@ Within the repository you created above:

  For a good commit message, please refer to the [Source Code Management](../contribute/code.md#commits-and-commit-messages) section.

-5. 로컬 분기(추가된 커밋 포함)를 Github의 분기된 저장소에 푸시합니다.
+10. 로컬 분기(추가된 커밋 포함)를 Github의 분기된 저장소에 푸시합니다.

  ```sh
  git push origin your_feature_branch_name
  ```

-6. Go to your forked repository on Github in a web browser, e.g.: `https://github.com/<your git name>/PX4-Autopilot.git`.
+11. Go to your forked repository on Github in a web browser, e.g.: `https://github.com/<your git name>/PX4-user_guide.git`.
  새 분기가 분기된 저장소로 푸시되었다는 메시지가 표시되어야 합니다.

-7. 풀 요청(PR) 생성:
-
+12. 풀 요청(PR) 생성:
  - On the right hand side of the "new branch message" (see one step before), you should see a green button saying "Compare & Create Pull Request".
    클릭합니다.
  - 풀 요청 템플릿이 생성됩니다.
    그것은 당신의 커밋을 나열하고 의미 있는 제목(하나의 커밋 PR의 경우 일반적으로 커밋 메시지)과 메시지(<span style="color:orange">어떤 이유에서 수행했는지 설명</span>)를 추가할 수 있습니다(반드시).
-    Check [other pull requests](https://github.com/PX4/PX4-Autopilot/pulls) for comparison).
-  - Add the "Documentation" label.
-
-8. 완료하였습니다.
+    Check [other pull requests](https://github.com/PX4/PX4-user_guide/pulls) for comparison)

+13. 완료하였습니다.
  PX4 사용자 가이드 유지 관리자는 이제 귀하의 기여를 검투한 후에, 통합 여부를 결정합니다.
  때때로 변경 사항에 대한 질문을 확인하십시오.

@@ -157,10 +129,10 @@ Within the repository you created above:
  - [Nodejs 18+](https://nodejs.org/en)
  - [Yarn classic](https://classic.yarnpkg.com/en/docs/install)

-2. Navigate to your local repository and the `/docs` subdirectory:
+2. 로컬 저장소로 이동합니다.

  ```sh
-  cd ~/wherever/PX4-Autopilot/docs
+  cd ~/wherever/PX4-user_guide
  ```

 3. 종속성(Vuepress 포함)들을 설치합니다.
@@ -11,7 +11,3 @@ This section provides information about various radio systems that you can use,
 - [FrSky Telemetry](../peripherals/frsky_telemetry.md) — Telemetry on your (FRSky) RC Receiver
 - [TBS Crossfire (CRSF) Telemetry](../telemetry/crsf_telemetry.md) — Telemetry on your (TBS Crossfire) RC Receiver
 - [Satellite Comms (Iridium/RockBlock)](../advanced_features/satcom_roadblock.md) — High-latency comms via satellite
-
-## See Also
-
- [Safety Configuration > Data Link Loss Failsafe](../config/safety.md#data-link-loss-failsafe)
@@ -190,189 +190,67 @@ You can now build and test.

 ## Download & Decrypt Log Files

-Before you can analyse your logs they must first be downloaded and decrypted.
-PX4 includes Python scripts in [Tools/log_encryption](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/) that make this process easier:
+Encrypted log files are downloaded using the QGroundControl [Log Download](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/log_download.html) view (**Analyze Tools > Log Download**) just like ordinary log files.

- [download_logs.py](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/log_encryption/download_logs.py): Downloads the logs to `/logs/encrypted`.
- [decrypt_logs.py](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/log_encryption/decrypt_logs.py): Decrypts encrypted logs in `/logs/encrypted` to `/logs/decrypted` using a specified (or default) key.
-
-The following sections show how these are used.
-
-### Download Log Files
-
-The easiest way to download the files is to use [download_logs.py](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/log_encryption/download_logs.py).
-This takes a single argument that sets the serial or UDP MAVLink connection to the device as shown below (adjust parameters as needed):
-
- UDP connection
-
-  ```sh
-  cd PX4-Autopilot/Tools/log_encryption
-  python3 download_logs.py udp:0.0.0.0:14550
-  ```
-
- USB serial port on Linux
-
-  ```sh
-  cd PX4-Autopilot/Tools/log_encryption
-  python3 download_logs.py /dev/ttyACM0 --baudrate 57600
-  ```
-
-The files are downloaded to `/logs/encrypted`, which is the location expected by the decryption script.
-
-:::info
-Encrypted log files can also be downloaded manually using the QGroundControl [Log Download](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/log_download.html) view (**Analyze Tools > Log Download**) just like ordinary log files.
-
-Note that in this case you will need to copy the files to `/logs/encrypted` and rename them to the `.ulge` suffix (they are downloaded with the `.ulg` suffix)
-:::
+Note that the encrypted files will be downloaded with the `.ulg` suffix, instead of `.ulge`.

 ### Decrypt ULogs

-By default, the [decrypt_logs.py](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/log_encryption/decrypt_logs.py) script decrypts encrypted logs in `/logs/encrypted` using the private key in `keys/private/private_key.pem`, and generates the unencrypted logs in `/logs/decrypted`.
+Before you can analyze your encrypted logs, you will need to decrypt them.
+There is a Python script that can be used to decrypt logs in `Tools/decrypt_ulog.py`.

-Navigate into the `Tools/log_encryption` folder and run the tool as shown below:
+When decrypting a `.ulge` file the script takes 3 arguments:
+
+1. The encrypted log file.
+2. An empty string `''`.
+3. The decryption key (the RSA2048 `.pem` private key which is used to unwrap the symmetric key).
+
+예:

 ```sh
-cd PX4-Autopilot/Tools/log_encryption
-python3 decrypt_logs.py
+python3 decrypt_ulog.py \
+/home/john/Downloads/log_24_2024-10-6-23-39-50.ulg '' \
+new_keys/private_key.pem
 ```

-On success the decrypted logs can be found in the decrypted folder.
+On success the decrypted log file is created with the `.ulog` suffix.
+
+:::info
+The script can be used with both `.ulge` logs and the `.ulgc`/`.ulgk` files used in [PX4 v1.15 Log Encryption](https://docs.px4.io/v1.15/en/dev_log/log_encryption.html).
+The full command line syntax is given below:

 ```sh
-PX4-Autopilot/logs/decrypted
-```
+usage: decrypt_ulog.py [-h] [ulog_file] [ulog_key] [rsa_key]

-The expected folder structure showing the location of encrypted logs, decrypted logs and the default private key is shown below:
+CLI tool to decrypt an ulog file

-```sh
-PX4-Autopilot/
-│
-├── logs/ # Main directory for logs
-│ ├── encrypted/ # Stores encrypted logs (.ulge)
-│ │ ├── log-YYYY-MM-DD_HH-MM-SS_ID.ulge # Encrypted logs
-│ │
-│ ├── decrypted/
-│ │ ├── log-YYYY-MM-DD_HH-MM-SS_ID.ulg # Regular PX4 logs
-|
-├── keys/ # Main directory for keys
-  ├── private/ # Stores private keys
-    ├── private_key.pem # RSA private key (2048-bit)
-```
+positional arguments:
+  ulog_file   .ulge/.ulgc, encrypted log file
+  ulog_key    .ulgk, legacy encrypted key (give empty string '' to ignore for .ulge)
+  rsa_key     .pem format key for decrypting the ulog key

-:::tip
-The script also allows you to specify a particular key and/or to specify a particular file or folder to be decrypted using optional positional arguments:
-
-```sh
-python3 decrypt_logs.py ["" | custom_key] [log_file.ulge | log_folder]
-```
-
-The full set of command options are shown below:
-
-```sh
-# Default key + default folder
-python3 decrypt_logs.py
-
-# Specific key + default folder
-python3 decrypt_logs.py path/to/private_key.pem
-
-# Specific key + specific file
-python3 decrypt_logs.py path/to/private_key.pem path/to/log_file.ulge
-
-# Specific key + specific folder
-python3 decrypt_logs.py path/to/private_key.pem path/to/log_folder
-
-# Default key + specific file
-python3 decrypt_logs.py "" path/to/log_file.ulge
-
-# Default key + specific folder
-python3 decrypt_logs.py "" path/to/log_folder
+optional arguments:
+  -h, --help  show this help message and exit
 ```

 :::

 ## Generate RSA Public & Private Keys

-The [Tools/log_encryption/generate_keys.py](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/log_encryption/generate_keys.py) script can be used to generate the public key that is used on the device for encryption, and the private key that is used on the computer as part of log decryption.
-
-:::details
-The script depends on OpenSSL.
-
-Run the following command to check if OpenSSL is present:
+To generate a RSA2048 private and public key, you can use OpenSSL:

 ```sh
-openssl version
+openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
 ```

-If there is no output you can install OpenSSL as shown below:
-
- Ubuntu/Debian
-
-  ```sh
-  sudo apt update
-  sudo apt install openssl
-  ```
-
- macOS
-
-  ```sh
-  brew install openssl
-  ```
-
-:::
-
-The script is used as shown:
+Then you can create a public key from this private key:

 ```sh
-cd PX4-Autopilot/Tools/log_encryption
-python3 generate_keys.py
+# Convert private_key.pem to a DER file
+openssl rsa -pubout -in private_key.pem -outform DER -out public_key.der
+# From the DER file, generate a public key in hex format, separated by commas
+xxd -p public_key.der | tr -d '\n' | sed 's/\(..\)/0x\1, /g' > public_key.pub
 ```

-The private and public key will be generated into the folder structure below.
-The private key should be stored safely and used when you need to [decrypt log files](#decrypt-ulogs).
-
-```sh
-PX4-Autopilot/
-│
-├── keys/ # Main directory for keys
-│ ├── private/ # Stores private keys
-│ │ ├── private_key.pem # RSA private key (2048-bit)
-│ │
-│ ├── public/ # Stores public keys
-│ │ ├── public_key.der # Public key in DER format
-│ │ ├── public_key.pub # Public key in hex format
-```
-
-참고:
-
- The script will not overwrite any existing keys in the folders.
-  It will generate a new public key if the folder only includes a private key.
- The public key is created with the default name and location expected by the toolchain when building PX4 (i.e. in `CONFIG_PUBLIC_KEY1`), and the private key is created in the default location expected by the script we use for [decrypting ulogs](#decrypt-ulogs).
-
-### Manual Key Generation
-
-This section explains how you might manually run the same steps as the script (should you so wish):
-
-1. First install OpenSSL, as described in the previous section.
-
-2. Use OpenSSL to generate a RSA2048 private and public key:
-
-  ```sh
-  openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
-  ```
-
-3. Create a public key from this private key:
-
-  ```sh
-  # Convert private_key.pem to a DER file
-  openssl rsa -pubout -in private_key.pem -outform DER -out public_key.der
-  # From the DER file, generate a public key in hex format, separated by commas
-  xxd -p public_key.der | tr -d '\n' | sed 's/\(..\)/0x\1, /g' > public_key.pub
-  ```
-
-4. Copy the keys into the appropriate locations expected by the rest of the toolchain (as shown in previous section).
-
-5. To use this key, modify your `.px4board` file to point `CONFIG_PUBLIC_KEY1` to the file location of `public_key.pub`.
-
-  ```sh
-  CONFIG_PUBLIC_KEY1="../../../keys/public/public_key.pub"
-  ```
+To use this key you would modify your `.px4board` file to point `CONFIG_PUBLIC_KEY1` to the file location of `public_key.pub`.
+The private key generated should be stored safely and used when you need to decrypt log files.
@@ -1,6 +1,6 @@
-# MAVLink Peripherals (GCS/OSD/Gimbal/Camera/Companion)
+# MAVLink 주변 장치(OSD/GCS/보조 컴퓨터 등)

-Ground Control Stations (GCS), On-Screen Displays (OSD), MAVLink Cameras & Gimbals, Remote IDs, Companion Computers, ADS-B receivers, and other MAVLink peripherals interact with PX4 using separate MAVLink streams, sent via different serial ports.
+GCS(Ground Control Station), OSD(On-Screen Display), 보조 컴퓨터, ADS-B 수신기와 기타 MAVLink 주변 장치들은 서로 다른 직렬 포트를 통하여 전송되는 별도의 MAVLink 스트림을 통하여 PX4와 상호 작용합니다.

 In order to configure that a particular serial port is used for MAVLink traffic with a particular peripheral, we use [Serial Port Configuration](../peripherals/serial_configuration.md), assigning one of the abstract "MAVLink instance" configuration parameters to the desired port.
 We then set other properties of the MAVLink channel using the parameters associated with our selected MAVLink instance, so that they match the requirements of our particular peripheral.
@@ -37,10 +37,8 @@ The number in the name means nothing; you can assign any instance to any port.
  - _OSD_: Standard set of messages for an OSD system.
  - _Config_: Standard set of messages and rate configuration for a fast link (e.g. USB).
  - _Minimal_: Minimal set of messages for use with a GCS connected on a high latency link.
-  - _External Vision_: Messages for offboard vision systems.
-  - _Gimbal_: Messages for a gimbal. Note this also enables [message forwarding](#MAV_X_FORWARD)
-  - _Onboard Low Bandwidth_: Standard set of messages for a companion computer connected on a lower speed link.
-  - _uAvionix_: Messages for a uAvionix ADS-B beacon.
+  - _ExtVision_ or _ExtVisionMin_: Messages for offboard vision systems (ExtVision needed for VIO).
+  - _Iridium_: Messages for an [Iridium satellite communication system](../advanced_features/satcom_roadblock.md).

  ::: info
  If you need to find the specific set of message for each mode search for `MAVLINK_MODE_` in [/src/modules/mavlink/mavlink_main.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/mavlink/mavlink_main.cpp).
@@ -70,7 +68,9 @@ You will need to reboot PX4 to make the parameter available (i.e. in QGroundCont
 The parameter used will depend on the [assigned serial port](../advanced_config/parameter_reference.md#serial) - for example: `SER_GPS1_BAUD`, `SER_TEL2_BAUD`, etc.
 사용하는 값은 연결 유형과 연결된 MAVLink 주변 장치에 따라 달라집니다.

-## Default MAVLink Ports {#default_ports}
+<a id="default_ports"></a>
+
+## 기본 MAVLink 포트

 ### TELEM1

@@ -112,16 +112,8 @@ On this hardware, there is a [default serial port mapping](../peripherals/serial

 For more information see: [PX4 Ethernet Setup](../advanced_config/ethernet_setup.md)

-## Device Specific Setup
-
-Links to setup instructions for specific MAVLink components:
-
- [MAVLink Cameras (Camera Protocol v2) > PX4 Configuration](../camera/mavlink_v2_camera.md#px4-configuration)
- [Gimbal Configuration > MAVLink Gimbal (MNT_MODE_OUT=MAVLINK)](../advanced/gimbal_control.md#mavlink-gimbal-mnt-mode-out-mavlink)
-
 ## See Also

 - [Serial Port Configuration](../peripherals/serial_configuration.md)
 - [PX4 Ethernet Setup > PX4 MAVLink Serial Port Configuration](../advanced_config/ethernet_setup.md#px4-mavlink-serial-port-configuration)
 - [Serial Port Mapping](../hardware/serial_port_mapping.md)
-
@@ -10,14 +10,13 @@ PX4는 다양한 텔레메트리 라디오 타입을 지원합니다:
  - <del>_HKPilot Telemetry Radio_</del> (Discontinued)
  - <del>_3DR Telemetry Radio_</del> (Discontinued)
 - [Telemetry Wifi](../telemetry/telemetry_wifi.md)
- [J.Fi Wireless Telemetry Module](../telemetry/jfi_telemetry.md)
 - [Microhard Serial Telemetry Radio](../telemetry/microhard_serial.md)
  - [ARK Electron Microhard Serial Telemetry Radio](../telemetry/ark_microhard_serial.md)
  - [Holybro Microhard P900 Telemetry Radio](../telemetry/holybro_microhard_p900_radio.md)
 - CUAV Serial Telemetry Radio
  - [CUAV P8 Telemetry Radio](../telemetry/cuav_p8_radio.md)
 - XBee Serial Telemetry Radio
-  - <del>[HolyBro XBP9X Telemetry Radio](../telemetry/holybro_xbp9x_radio.md)</del> (Discontinued)
+  - [HolyBro XBP9X Telemetry Radio](../telemetry/holybro_xbp9x_radio.md) (Discontinued)

 PX4 is protocol compatible with [SiK Radio](../telemetry/sik_radio.md) and will generally work out of the box (though you may need to change/use an appropriate connector).

@@ -1,134 +0,0 @@
-# J.Fi Wireless Telemetry Module
-
-The J.MARPLE [J.Fi telemetry module](https://jmarple.ai/j-fi/) is a compact and lightweight wireless communication device featuring a PCB-integrated antenna or external antenna, enabling seamless telemetry connections between various drone flight controllers (FC) and ground control stations.
-
-This module includes a Pixhawk-standard JST 6-pin `TELEM` connector, ensuring compatibility with all PX4-based flight controllers.
-It supports quick plug-and-play operation to `TELEM1` with default settings, requiring no additional configuration.
-
-The J.Fi telemetry module provides reliable communication up to approximately 500 meters when using a PCB-integrated antenna.
-Operating in the 2.4GHz frequency band, it allows unrestricted global use without regulatory limitations.
-
-![J.Fi Wireless Telemetry Module](../../assets/hardware/telemetry/jmarple/jfi_telemetry_module.png)
-
-## 구매처
-
- [https://jmarple.ai/j-fi/](https://jmarple.ai/j-fi/)
-
-## 기술 사양
-
-### Wireless Performance
-
- **Frequency Band:** 2.4GHz
- **Speed:** Up to 11 Mbps (adjustable)
- **Range:** Up to 500 meters (varies upon environments)
- **Payload Capacity:** Up to 1400 bytes
-
-### Network Schemes
-
- **Supported Topologies:** 1:1, 1:N, N:N
- **Collision Management:** Time Slot-Based Response Delay
-
-### User-Friendly Features
-
- **Buttons:** Pairing and Mode Switching
- **LED Indicators:** Real-time status updates
- **Configuration:** Web browser-based setup
- **Micro USB Port for connecting to PC or GCS**
-
-## Broadcast Communication
-
-With default settings enabled, the device automatically broadcasts data to all nearby J.Fi devices.
-Connect your external device or system to the **Broadcast port**.
-No additional setup is required.
-
-![J.Fi Wireless Telemetry Broadcast Communication](../../assets/hardware/telemetry/jmarple/jfi_telemetry_broadcast.png)
-
-## Paired Communication
-
- Modules must first undergo an initial pairing procedure.
- Once paired, communication is _restricted to paired J.Fi devices_. Connect your external device or system to the **Pair port.**
-
-![J.Fi Wireless Telemetry Paired Communication](../../assets/hardware/telemetry/jmarple/jfi_telemetry_paired.png)
-
-### 1:1 Pairing
-
-![J.Fi Wireless Telemetry Buttons](../../assets/hardware/telemetry/jmarple/jfi_telemetry_buttons.png)
-
- On **each device,** press and hold _button A_, then click the _RST button_.
-  Release _button A_ when _LED 1_ blinks.
-  - Both devices will enter pairing mode
- Choose one module and double-click _button A_
- On the other module, click _button A_ once
- On the first module, click _button A_ once again to finish pairing
-  - Pairing complete
-
-### 1:N Pairing
-
- On **each device,** press and hold _button A_, then click the _RST button_.
-  Release _button A_ when _LED 1_ blinks.
-  - All devices will enter pairing mode
- **Host module (1):** Double-click _button A_
- **Client modules (N):** Click _button A_ once on each module to pair
- **Host module (1):** Click _button A_ again to finish pairing
-  - Pairing complete.
-
-<lite-youtube videoid="CnjhTfvARmw" title="J.Fi Wireless Telemetry Module Pairing Guide"/>
-
-## PX4 Setup
-
-PX4 is plug-and-play with J.Fi if connected to the `TELEM1` port, and should connect without further connection.
-
-If you want to use another port you will need to assign a MAVLink instance to the serial port (see [MAVLink Peripherals (GCS/OSD/Companion)](../peripherals/mavlink_peripherals.md)) (and possibly unassign whatever is currently using the port).
-
-### One-to-one (1:1) Setups
-
-The `TELEM1` port is set to use `57600` as the baud rate by default (and J.Fi is set to match).
-This default baud rate is calibrated for inexpensive low-power telemetry radios.
-While this should be sufficient for 1:1 setups, J.Fi will work with much higher rates (i.e., `115200`).
-
-If you want to change the baud rate:
-
-1. Change [SER_TEL1_BAUD](../advanced_config/parameter_reference.md#SER_TEL1_BAUD) if you're using the `TELEM1` port (see [Serial Port Configuration](../peripherals/serial_configuration.md) for other ports).
-2. Update the baud rate in the [J.Fi Configuration](#j-fi-configuration) to match.
-
-### One-to-many (1:N) Setups
-
-For one-to-many (1:N) setups a higher baud rate is _highly recommended_ to ensure stable data reception.
-All J.Fi devices should be set to the same baud rate (although communication may work even when when devices use different baud rates).
-This should be changed in both PX4 and the J.Fi modules as explained in the previous section.
-
-You will also need to make sure that all vehicles on the MAVLink network are assigned a unique **System ID** ([MAV_SYS_ID](../advanced_config/parameter_reference.md#MAV_SYS_ID)).
-
-![J.Fi Wireless Telemetry Broadcast Communication](../../assets/hardware/telemetry/jmarple/jfi_telemetry_usage.png)
-
-<lite-youtube videoid="tPeJA2gn7Zw" title="Simultaneous Control using J.Fi Wireless Telemetry Module"/>
-
-## QGroundControl Configuration
-
-The J.Fi will connect plug-and-play to **QGroundControl** and automatically connect just like a SiK Radio.
-
-However if you change the baud rate from 57600 you will need to create and use a new link configuration:
-
-1. Disable SiK Radio in QGC (**Application Settings → General → AutoConnect**).
-2. Create a new link configuration:
-  - Go to **Application Settings → Comms Links**.
-  - Click **Add**.
-  - Set **Type** to **Serial**, configure the **Serial Port** and **Baud Rate** to match the J.Fi device.
-3. Select **Connect** to connect with the new configuration.
-
-## J.Fi Configuration
-
- **Device:** Press and hold _button B_, then click the _RST button_.
-  Release _button B_ when _LED 2_ blinks.
-  - Device enters configuration mode
- **Smart device:** Connect to Wi-Fi network named `J.Fi-xxxxxx` (x: alphanumeric characters)
- **Browser:** Go to `192.168.4.1` to open the **configuration page**.
- **Configuration page:** Adjust settings as needed, then click **Save**
-  - _LED 1_ blinks once upon saving
-
-![J.Fi Wireless Telemetry Broadcast Communication](../../assets/hardware/telemetry/jmarple/jfi_telemetry_config.jpg)
-
-## 추가 정보
-
- [User Manual](https://docs.google.com/document/d/1NaVwOLuMCuNpd0uxgilXZ_qfHAnsFgBmaPxX9WGY2h4/edit?usp=sharing)
- [ROS Github](https://github.com/SUV-Lab/J-Fi)
@@ -314,7 +314,6 @@
  - [Джойстики](config/joystick.md)
  - [Посилання даних](data_links/index.md)
    - [MAVLink Telemetry (OSD/GCS)](peripherals/mavlink_peripherals.md)
-
    - [Телеметричні радіостанції](telemetry/index.md)
      - [SiK Radio](telemetry/sik_radio.md)
        - [Телеметричне радіо RFD900 (SiK)](telemetry/rfd900_telemetry.md)
@@ -327,13 +326,9 @@
        - [ARK Electron Microhard Серійне Телеметрійне Радіо](telemetry/ark_microhard_serial.md)
        - [Holybro Microhard P900 Телеметрійне Радіо](telemetry/holybro_microhard_p900_radio.md)
      - [CUAV P8 Телеметрійне радіо](telemetry/cuav_p8_radio.md)
-      - [J.Fi Wireless Telemetry Module](telemetry/jfi_telemetry.md)
      - [Holybro XBP9X - Припинено](telemetry/holybro_xbp9x_radio.md)
-
    - [FrSky телеметрія](peripherals/frsky_telemetry.md)
-
    - [TBS Crossfire (CRSF) телеметрія](telemetry/crsf_telemetry.md)
-
    - [Супутниковий зв'язок (Iridium/RockBlock)](advanced_features/satcom_roadblock.md)
  - [Енергетичні системи](power_systems/index.md)
    - [Налаштування оцінки батареї](config/battery.md)
@@ -846,4 +841,4 @@
  - [1.15 (stable)](releases/1.15.md)
  - [1.14](releases/1.14.md)
  - [1.13](releases/1.13.md)
-  - [1.12](releases/1.12.md)
+  - [1.12](releases/1.12.md)
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Pernilla	7b902efdca	Update description	2025-04-07 11:52:45 +02:00
Pernilla	a3657c1396	Allow user to set choke position through parameter	2025-04-04 15:26:31 +02:00