From b37733459d329e1ec3996d44a37824274f489356 Mon Sep 17 00:00:00 2001 From: Hamish Willee Date: Thu, 5 Mar 2026 12:50:59 +1100 Subject: [PATCH] docs: Codespell check on English sources + swd fixes (#26657) --- docs/en/advanced/computer_vision.md | 2 +- docs/en/advanced/gimbal_control.md | 2 +- .../bootloader_update_v6xrt.md | 6 +- docs/en/assembly/_assembly.md | 4 +- docs/en/assembly/quick_start_pixracer.md | 2 +- docs/en/camera/camera_architecture.md | 2 +- docs/en/camera/fc_connected_camera.md | 2 +- docs/en/camera/mavlink_v1_camera.md | 4 +- .../holybro_pixhawk_jetson_baseboard.md | 2 +- docs/en/companion_computer/index.md | 2 +- docs/en/companion_computer/pixhawk_rpi.md | 2 +- docs/en/complete_vehicles_rover/aion_r1.md | 2 +- .../computer_vision/collision_prevention.md | 2 +- docs/en/concept/events_interface.md | 2 +- docs/en/concept/flight_tasks.md | 2 +- docs/en/config/_autotune.md | 4 +- docs/en/config/safety.md | 6 +- .../pid_tuning_guide_multicopter_basic.md | 2 +- docs/en/config_rover/attitude_tuning.md | 4 +- docs/en/config_rover/basic_setup.md | 2 +- docs/en/config_rover/index.md | 2 +- docs/en/config_rover/rate_tuning.md | 2 +- docs/en/config_rover/velocity_tuning.md | 4 +- docs/en/config_vtol/vtol_ice_shedding.md | 2 +- docs/en/contribute/dev_call.md | 2 +- docs/en/contribute/index.md | 2 +- docs/en/contribute/support.md | 2 +- docs/en/debug/debug_values.md | 2 +- docs/en/debug/eclipse_jlink.md | 2 +- docs/en/debug/plotting_realtime_uorb_data.md | 2 +- docs/en/debug/probe_mculink.md | 2 +- docs/en/debug/swd_debug.md | 78 ++++++++++--------- docs/en/dev_log/log_encryption.md | 2 +- docs/en/dronecan/ark_cannode.md | 4 +- docs/en/dronecan/ark_g5_rtk_heading_gps.md | 2 +- docs/en/dronecan/holybro_h_rtk_zed_f9p_gps.md | 2 +- docs/en/dronecan/index.md | 4 +- docs/en/flight_controller/airlink.md | 4 +- .../flight_controller/mro_control_zero_f7.md | 4 +- docs/en/flight_controller/pixhawk5x.md | 2 +- docs/en/flight_controller/x-mav_ap-h743r1.md | 2 +- docs/en/flight_modes_fw/mission.md | 10 +-- docs/en/flight_modes_fw/takeoff.md | 4 +- docs/en/flight_modes_mc/follow_me.md | 4 +- docs/en/flight_modes_mc/mission.md | 2 +- docs/en/flight_modes_mc/return.md | 2 +- docs/en/flight_modes_vtol/mission.md | 2 +- docs/en/flight_stack/controller_diagrams.md | 2 +- docs/en/flying/basic_flying_mc.md | 2 +- docs/en/frames_multicopter/kits.md | 2 +- docs/en/frames_plane/reptile_dragon_2.md | 6 +- .../en/frames_plane/turbo_timber_evolution.md | 12 +-- docs/en/frames_sub/bluerov2.md | 2 +- .../vtol_tiltrotor_omp_hobby_zmo_fpv.md | 4 +- docs/en/gps_compass/index.md | 4 +- docs/en/gps_compass/magnetometer.md | 4 +- docs/en/gps_compass/rtk_gps_cuav_c-rtk2.md | 2 +- docs/en/gps_compass/rtk_gps_gem1305.md | 2 +- docs/en/gps_compass/rtk_gps_locosys_r1.md | 2 +- docs/en/gps_compass/rtk_gps_locosys_r2.md | 4 +- docs/en/gps_compass/septentrio_mosaic-go.md | 2 +- docs/en/hardware/board_support_guide.md | 2 +- docs/en/hardware/drone_parts.md | 2 +- docs/en/mavlink/adding_messages.md | 2 +- docs/en/middleware/uorb.md | 2 +- docs/en/middleware/uxrce_dds.md | 2 +- .../en/neural_networks/nn_module_utilities.md | 4 +- docs/en/peripherals/adsb_flarm.md | 10 +-- docs/en/peripherals/dshot.md | 10 +-- docs/en/peripherals/esc_motors.md | 2 +- docs/en/peripherals/frsky_telemetry.md | 2 +- docs/en/peripherals/pwm_escs_and_servo.md | 2 +- docs/en/peripherals/serial_configuration.md | 2 +- docs/en/power_module/index.md | 2 +- docs/en/releases/1.12.md | 2 +- docs/en/releases/1.14.md | 6 +- docs/en/releases/1.15.md | 2 +- docs/en/releases/1.16.md | 2 +- docs/en/robotics/index.md | 2 +- docs/en/ros/ros1.md | 2 +- docs/en/ros2/index.md | 6 +- docs/en/ros2/offboard_control.md | 2 +- docs/en/ros2/px4_ros2_msg_translation_node.md | 2 +- docs/en/ros2/user_guide.md | 2 +- docs/en/sensor/thunderfly_tachometer.md | 2 +- docs/en/sim_gazebo_gz/index.md | 2 +- docs/en/sim_gazebo_gz/tools_avl_automation.md | 2 +- docs/en/sim_gazebo_gz/vehicles.md | 2 +- docs/en/sim_gazebo_gz/worlds.md | 2 +- docs/en/sim_jmavsim/index.md | 2 +- docs/en/sim_sih/index.md | 2 +- docs/en/smart_batteries/index.md | 2 +- docs/en/telemetry/jfi_telemetry.md | 2 +- docs/en/test_and_ci/test_flights.md | 2 +- docs/en/test_cards/mc_02_full_autonomous.md | 2 +- .../mc_10_optical_flow_gps_mixed.md | 2 +- 96 files changed, 180 insertions(+), 174 deletions(-) diff --git a/docs/en/advanced/computer_vision.md b/docs/en/advanced/computer_vision.md index a87182f6b91..8a21f6017cc 100644 --- a/docs/en/advanced/computer_vision.md +++ b/docs/en/advanced/computer_vision.md @@ -67,7 +67,7 @@ The consensus [appears to be](https://discuss.px4.io/t/vio-vs-optical-flow/34680 Optical flow: -- Downward facing optical flow gives you a planar velocity thats corrected for angular velocity with the gyro. +- Downward facing optical flow gives you a planar velocity that's corrected for angular velocity with the gyro. - Requires an accurate distance to the ground and assumes a planar surface. Given those conditions it can be just as accurate/reliable as VIO (such as indoor flight) - Is more robust than VIO as it has fewer states. diff --git a/docs/en/advanced/gimbal_control.md b/docs/en/advanced/gimbal_control.md index f449b745870..c14f9ef2c8c 100644 --- a/docs/en/advanced/gimbal_control.md +++ b/docs/en/advanced/gimbal_control.md @@ -20,7 +20,7 @@ By default this is set to `Disabled (-1)` and the driver does not run. After selecting the input mode, reboot the vehicle to start the mount driver. You should set `MNT_MODE_IN` to one of: `RC (1)`, `MAVlink gimbal protocol v2 (4)` or `Auto (0)` (the other options are deprecated). -If you select `Auto (0)`, the gimbal will automatically select either RC or or MAVLink input based on the latest input. +If you select `Auto (0)`, the gimbal will automatically select either RC or MAVLink input based on the latest input. Note that the auto-switch from MAVLink to RC requires a large stick motion! The output is set using the [MNT_MODE_OUT](../advanced_config/parameter_reference.md#MNT_MODE_OUT) parameter. diff --git a/docs/en/advanced_config/bootloader_update_v6xrt.md b/docs/en/advanced_config/bootloader_update_v6xrt.md index 9d7f92a4aaf..5211ad2dd21 100644 --- a/docs/en/advanced_config/bootloader_update_v6xrt.md +++ b/docs/en/advanced_config/bootloader_update_v6xrt.md @@ -1,6 +1,6 @@ # Bootloader Update Pixhawk V6X-RT via USB -This topic explains explains to flash [Pixhawk FMUv6X-RT](../flight_controller/pixhawk6x-rt.md) bootloader via USB _without needing a debug probe_. +This topic explains how to flash [Pixhawk FMUv6X-RT](../flight_controller/pixhawk6x-rt.md) bootloader via USB _without needing a debug probe_. ## Overview @@ -33,7 +33,7 @@ arm-none-eabi-objcopy -O ihex build/px4_fmu-v6xrt_bootloader/px4_fmu-v6xrt_bootl ## Flashing the bootloader through USB -The Pixhawk V6X-RT comes with a build-in bootloader located on the ROM. +The Pixhawk V6X-RT comes with a built-in bootloader located on the ROM. To flash a new bootloader through USB you've got to download the [NXP MCUXpresso Secure Provisioning tool](https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-secure-provisioning-tool:MCUXPRESSO-SECURE-PROVISIONING). The tool is available for Windows, Linux and macOS. @@ -79,7 +79,7 @@ The tool is available for Windows, Linux and macOS. ![Flash bootloader through Secure provisioning - Step 7](../../assets/advanced_config/bootloader_6xrt/bootloader_update_v6xrt_step7.png) -1. When the Target Memory configuration is succesful you can press the the **Erase All** button +1. When the Target Memory configuration is successful you can press the **Erase All** button ![Flash bootloader through Secure provisioning - Step 8](../../assets/advanced_config/bootloader_6xrt/bootloader_update_v6xrt_step8.png) diff --git a/docs/en/assembly/_assembly.md b/docs/en/assembly/_assembly.md index b5082bedd1c..0d56615a6ae 100644 --- a/docs/en/assembly/_assembly.md +++ b/docs/en/assembly/_assembly.md @@ -337,7 +337,7 @@ Note: Note that the PWM outputs are often labeled `AUX` or `MAIN`. Use the `AUX` bus if both are present, and `MAIN` otherwise. - [DShot ESC](../peripherals/dshot.md) (recommended) can only be used on the FMU PWM outputs. -- Motor outputs should be grouped together as much as possible rather than spread randomly across both the FMU and IO busses. +- Motor outputs should be grouped together as much as possible rather than spread randomly across both the FMU and IO buses. This is because if you assign some function to an output, such as DShot ESC, you can't then assign adjacent unused pins for anything other than a DShot ESC. ### Servos @@ -363,7 +363,7 @@ If you don't use servos that all accept the same voltage, you'll need to separat Other peripherals, such as high-power radios, cameras, and so on have their own power requirements. These will usually be supplied off a separate BEC. -The wiring and configuration of optional/less common components is covered within the [Hardware Hardware Selection & Setup](../hardware/drone_parts.md) topics for individual peripherals. +The wiring and configuration of optional/less common components is covered within the [Hardware Selection & Setup](../hardware/drone_parts.md) topics for individual peripherals. ## Build Tutorials diff --git a/docs/en/assembly/quick_start_pixracer.md b/docs/en/assembly/quick_start_pixracer.md index dccbec98dd0..ce4cbeac784 100644 --- a/docs/en/assembly/quick_start_pixracer.md +++ b/docs/en/assembly/quick_start_pixracer.md @@ -52,7 +52,7 @@ The instructions below show how to connect the different types of receivers: Pixracer has inbuilt WiFi, but also supports telemetry via external Wi-Fi or radio telemetry modules connected to the `TELEM1` or `TELEM2` ports. This is shown in the wiring diagram below. -![Pixracer external telemtry options](../../assets/flight_controller/pixracer/pixracer_top_telemetry.jpg) +![Pixracer external telemetry options](../../assets/flight_controller/pixracer/pixracer_top_telemetry.jpg) ::: info The `TELEM2` port must be configured as a second MAVLink instance using the [MAV_2_CONFIG](../advanced_config/parameter_reference.md#MAV_2_CONFIG) parameter. diff --git a/docs/en/camera/camera_architecture.md b/docs/en/camera/camera_architecture.md index b7de079bc24..5390641c38e 100644 --- a/docs/en/camera/camera_architecture.md +++ b/docs/en/camera/camera_architecture.md @@ -36,7 +36,7 @@ The `camera_trigger`, `camera_capture` and `camera_feedback` modules are not use This work is handled by three PX4 components: [`camera_trigger` driver](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/camera_trigger), [`camera_capture` driver](https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/camera_capture), [`camera-feedback` module](../modules/modules_system.md#camera-feedback). `camera_trigger` subscribes to the [VehicleCommand](../msg_docs/VehicleCommand.md) topic and monitors for updates to its [supported commands](../camera/fc_connected_camera.md#mavlink-command-interface). -Thes updates occur when either a command is received via MAVLink or when a [camera item is reached in a mission](#camera-commands-in-missions). +These updates occur when either a command is received via MAVLink or when a [camera item is reached in a mission](#camera-commands-in-missions). The commands enable and disable triggering, and configure triggering at time and distance intervals. The driver tracks these intervals, and when needed triggers the outputs. diff --git a/docs/en/camera/fc_connected_camera.md b/docs/en/camera/fc_connected_camera.md index 1f181791227..69ce7ee7378 100644 --- a/docs/en/camera/fc_connected_camera.md +++ b/docs/en/camera/fc_connected_camera.md @@ -78,7 +78,7 @@ The shutter integration setting (`param2`) is only obeyed with a GPIO backend. ## Trigger Configuration -Cameras can be connected to the FC for triggering using different intefaces, such as PWM, and GPIO, by specifying the appropriate [trigger interface backend](#trigger-interface-backends). +Cameras can be connected to the FC for triggering using different interfaces, such as PWM, and GPIO, by specifying the appropriate [trigger interface backend](#trigger-interface-backends). You can also indicate the camera [trigger mode](#trigger-modes). This configuration can most easily be done from the _QGroundControl_ [Vehicle Setup > Camera](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/setup_view/camera.html#px4-camera-setup) section. diff --git a/docs/en/camera/mavlink_v1_camera.md b/docs/en/camera/mavlink_v1_camera.md index ac39e743f81..9f6c97ecb23 100644 --- a/docs/en/camera/mavlink_v1_camera.md +++ b/docs/en/camera/mavlink_v1_camera.md @@ -1,4 +1,4 @@ -# Simple MAVLink Cameras (Camera Protcol v1) +# Simple MAVLink Cameras (Camera Protocol v1) This topic explains how to use PX4 with a MAVLink [camera](../camera/index.md) that implements the [Camera Protocol v1 (Simple Trigger Protocol)](https://mavlink.io/en/services/camera_v1.html) with PX4 and a Ground Station. @@ -18,7 +18,7 @@ This approach is retained for use with older MAVLink cameras. PX4 supports this command set for triggering cameras with native support for the protocol (as described in this topic), and also for [cameras attached to flight controller outputs](../camera/fc_connected_camera.md). Ground stations and MAVLink SDKs generally address camera commands to the autopilot, which then forwards them to a connected MAVLink channel of type `onboard`. -PX4 also re-emits any camera mission items it encouters in a mission as camera commands: commands that aren't accepted are logged. +PX4 also re-emits any camera mission items it encounters in a mission as camera commands: commands that aren't accepted are logged. In all cases the commands are sent with the system id of the autopilot and the component ID of 0 (i.e. addressed to all components, including cameras). PX4 will also emit a [CAMERA_TRIGGER](https://mavlink.io/en/messages/common.html#CAMERA_TRIGGER) whenever an image capture is triggered (the camera itself may also emit this message on triggering). diff --git a/docs/en/companion_computer/holybro_pixhawk_jetson_baseboard.md b/docs/en/companion_computer/holybro_pixhawk_jetson_baseboard.md index 5f515770433..7aa1ac35305 100644 --- a/docs/en/companion_computer/holybro_pixhawk_jetson_baseboard.md +++ b/docs/en/companion_computer/holybro_pixhawk_jetson_baseboard.md @@ -783,7 +783,7 @@ sudo apt install build-essential cmake git genromfs kconfig-frontends libncurses ## Building/Flashing the Pixhawk The recommended way to update PX4 is on the Pixhawk part of the board is to use your development computer. -You can either install install prebuilt binaries with QGroundControl, or first build and then upload custom firmware. +You can either install prebuilt binaries with QGroundControl, or first build and then upload custom firmware. Alternatively, you can build and deploy PX4 firmware to the Pixhawk part from the Jetson. diff --git a/docs/en/companion_computer/index.md b/docs/en/companion_computer/index.md index 7315e48cd51..0418c7de2c8 100644 --- a/docs/en/companion_computer/index.md +++ b/docs/en/companion_computer/index.md @@ -33,7 +33,7 @@ They are listed here as they can be updated with "vanilla" PX4 firmware for test ## Companion Computer Options -PX4 can be used with computers that can be configured to communicate via MAVLink or microROS/uXRCE-DDS over over a serial port (or Ethernet port, if present). +PX4 can be used with computers that can be configured to communicate via MAVLink or microROS/uXRCE-DDS over a serial port (or Ethernet port, if present). A small subset of possible alternatives are listed below. Larger high power examples: diff --git a/docs/en/companion_computer/pixhawk_rpi.md b/docs/en/companion_computer/pixhawk_rpi.md index b998f897a1a..69eb1d7c3cc 100644 --- a/docs/en/companion_computer/pixhawk_rpi.md +++ b/docs/en/companion_computer/pixhawk_rpi.md @@ -1,6 +1,6 @@ # Raspberry Pi Companion with Pixhawk -This topic describes how to setup a Raspberry Pi ("RPi") companion companion running [ROS 2](../ros2/user_guide.md) on Linux Ubuntu OS, connecting to a [Pixhawk](../flight_controller/autopilot_pixhawk_standard.md) flight controller using a serial connection between the Pixhawk `TELEM2` port and the RPi's TX/RX pins. +This topic describes how to setup a Raspberry Pi ("RPi") companion running [ROS 2](../ros2/user_guide.md) on Linux Ubuntu OS, connecting to a [Pixhawk](../flight_controller/autopilot_pixhawk_standard.md) flight controller using a serial connection between the Pixhawk `TELEM2` port and the RPi's TX/RX pins. These instructions should be readily extensible to other RPi and flight controller configurations. diff --git a/docs/en/complete_vehicles_rover/aion_r1.md b/docs/en/complete_vehicles_rover/aion_r1.md index 2ca9b0203b1..1e4316e731f 100644 --- a/docs/en/complete_vehicles_rover/aion_r1.md +++ b/docs/en/complete_vehicles_rover/aion_r1.md @@ -33,7 +33,7 @@ For this build this includes an [Auterion Skynode](../companion_computer/auterio If using a standard Pixhawk you could connect the RoboClaw to the Autopilot without an Adapter Board. ::: -The RoboClaw should be connected to a suitable suitable serial (UART) port on the flight controller, such as `GPS2` or `TELEM1`. +The RoboClaw should be connected to a suitable serial (UART) port on the flight controller, such as `GPS2` or `TELEM1`. Other RoboClaw wiring is detailed in the [RoboClaw User Manual](https://downloads.basicmicro.com/docs/roboclaw_user_manual.pdf) 'Packet Serial Wiring' section and shown below (this setup has been validated for compatibility). ![Serial Wiring Encoders](../../assets/airframes/rover/aion_r1/wiring_r1.jpg) diff --git a/docs/en/computer_vision/collision_prevention.md b/docs/en/computer_vision/collision_prevention.md index 1fad93be3df..06ecd76898a 100644 --- a/docs/en/computer_vision/collision_prevention.md +++ b/docs/en/computer_vision/collision_prevention.md @@ -143,7 +143,7 @@ If you wish to move freely into directions without sensor coverage, this can be ### Acceleration Constraining -For this we split out the acceleration setpoint into two components, one parallel to the closest distance to the obstacle and one normal to it. Then we scale each of these components according the the figure below. +For this we split out the acceleration setpoint into two components, one parallel to the closest distance to the obstacle and one normal to it. Then we scale each of these components according to the figure below. ![Scalefactor](../../assets/computer_vision/collision_prevention/scalefactor.png) diff --git a/docs/en/concept/events_interface.md b/docs/en/concept/events_interface.md index 6c29ebe798f..71e37f8f997 100644 --- a/docs/en/concept/events_interface.md +++ b/docs/en/concept/events_interface.md @@ -92,7 +92,7 @@ Explanations and requirements: ``` - Above we specify a separate external and internal log level, which are the levels displayed to GCS users and in the log file, respectively: `{events::Log::Error, events::LogInternal::Info}`. - For the majority of cases you can pass a single log level, and this will be used for both exernal and internal cases. + For the majority of cases you can pass a single log level, and this will be used for both external and internal cases. There are cases it makes sense to have two different log levels. For example an RTL failsafe action: the user should see it as Warning/Error, whereas in the log, it is an expected system response, so it can be set to `Info`. diff --git a/docs/en/concept/flight_tasks.md b/docs/en/concept/flight_tasks.md index 242a1e96fe5..83043322ea4 100644 --- a/docs/en/concept/flight_tasks.md +++ b/docs/en/concept/flight_tasks.md @@ -114,7 +114,7 @@ The instructions below might be used to create a task named _MyTask_: ::: tip The task added above will be built on all boards, including those with constrained flash such as Pixhawk FMUv2. - If your task is not indended for use on boards with constrained flash it should instead be added to the conditional block shown below (as shown). + If your task is not intended for use on boards with constrained flash it should instead be added to the conditional block shown below (as shown). ```cmake ... diff --git a/docs/en/config/_autotune.md b/docs/en/config/_autotune.md index fe5373b169d..4c502555345 100644 --- a/docs/en/config/_autotune.md +++ b/docs/en/config/_autotune.md @@ -124,7 +124,7 @@ Additional notes:
- The instructions above tune the vehicle in [Altitude mode](../flight_modes_mc/altitude.md). - You can instead takeoff in [Takeoff mode](../flight_modes_mc/takeoff.md) and tune in [Position mode](../flight_modes_mc/position.md) if the vehicle is is _known_ to be stable in these modes. + You can instead takeoff in [Takeoff mode](../flight_modes_mc/takeoff.md) and tune in [Position mode](../flight_modes_mc/position.md) if the vehicle is _known_ to be stable in these modes.
@@ -241,7 +241,7 @@ To map a switch: 2. Set [RC_MAP_AUX1](../advanced_config/parameter_reference.md#RC_MAP_AUX1) to match the RC channel for your switch (you can use any of `RC_MAP_AUX1` to `RC_MAP_AUX6`). 3. Set [FW_AT_MAN_AUX](../advanced_config/parameter_reference.md#FW_AT_MAN_AUX) to the selected channel (i.e. `1: Aux 1` if you mapped `RC_MAP_AUX1`). -The auto tuner will be disabled when the switch is below `0.5` (on the manual control setpoint range of of `[-1, 1]`) and enabled when the switch channel is above `0.5`. +The auto tuner will be disabled when the switch is below `0.5` (on the manual control setpoint range of `[-1, 1]`) and enabled when the switch channel is above `0.5`. If using an RC AUX switch to enable autotuning, make sure to [select the tuning axes](#select-tuning-axis) before flight. diff --git a/docs/en/config/safety.md b/docs/en/config/safety.md index 020dfec57af..863bf138539 100644 --- a/docs/en/config/safety.md +++ b/docs/en/config/safety.md @@ -274,7 +274,7 @@ The parameters that control when the quad-chute will trigger are listed in the t ## High Wind Failsafe -The high wind failsafe can trigger a warning and/or other mode change when the wind speed exceeds the warning and maximum wind-speed threshhold values. +The high wind failsafe can trigger a warning and/or other mode change when the wind speed exceeds the warning and maximum wind-speed threshold values. The relevant parameters are listed in the table below. | Parameter | Description | @@ -328,8 +328,8 @@ The failure detector can be configured to detect a motor failure while armed (an | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [FD_ACT_EN](../advanced_config/parameter_reference.md#FD_ACT_EN) | Enable/disable the motor failure trigger completely. | | [FD_ACT_MOT_THR](../advanced_config/parameter_reference.md#FD_ACT_MOT_THR) | Minimum normalized [0,1] motor command below which motor under current is ignored. | -| [FD_ACT_MOT_C2T](../advanced_config/parameter_reference.md#FD_ACT_MOT_C2T) | Scale between normalized [0,1] motor command and expected minimally reported currrent when the rotor is healthy. | -| [FD_ACT_MOT_TOUT](../advanced_config/parameter_reference.md#FD_ACT_MOT_TOUT) | Time in miliseconds for which the under current detection condition needs to stay true. | +| [FD_ACT_MOT_C2T](../advanced_config/parameter_reference.md#FD_ACT_MOT_C2T) | Scale between normalized [0,1] motor command and expected minimally reported current when the rotor is healthy. | +| [FD_ACT_MOT_TOUT](../advanced_config/parameter_reference.md#FD_ACT_MOT_TOUT) | Time in milliseconds for which the under current detection condition needs to stay true. | | [CA_FAILURE_MODE](../advanced_config/parameter_reference.md#CA_FAILURE_MODE) | Configure to not only warn about a motor failure but remove the first motor that detects a failure from the allocation effectiveness which turns off the motor and tries to operate the vehicle without it until disarming the next time. | ### External Automatic Trigger System (ATS) diff --git a/docs/en/config_mc/pid_tuning_guide_multicopter_basic.md b/docs/en/config_mc/pid_tuning_guide_multicopter_basic.md index dcadf60b94e..c843c1dfe83 100644 --- a/docs/en/config_mc/pid_tuning_guide_multicopter_basic.md +++ b/docs/en/config_mc/pid_tuning_guide_multicopter_basic.md @@ -13,7 +13,7 @@ For example, different ESCs or motors change the optimal tuning gains. ## Introduction -PX4 uses **P**roportional, **I**ntegral, **D**erivative (PID) controllers (these are the most widespread control technique). +PX4 uses **P**roportional, **I**integral, **D**erivative (PID) controllers (these are the most widespread control technique). The _QGroundControl_ **PID Tuning** setup provides real-time plots of the vehicle setpoint and response curves. The goal of tuning is to set the P/I/D values such that the _Response_ curve matches the _Setpoint_ curve as closely as possible (i.e. a fast response without overshoots). diff --git a/docs/en/config_rover/attitude_tuning.md b/docs/en/config_rover/attitude_tuning.md index e588daad969..1427591bb5e 100644 --- a/docs/en/config_rover/attitude_tuning.md +++ b/docs/en/config_rover/attitude_tuning.md @@ -16,7 +16,7 @@ Configure the following [parameters](../advanced_config/parameters.md) in QGroun Put the rover into stabilized mode and move the left stick of your controller up to drive forwards. Disarm the rover and from the flight log plot the `measured_yaw` and the `adjusted_yaw_setpoint` from the [RoverAttitudeStatus](../msg_docs/RoverAttitudeStatus.md) message over each other. Increase/Decrease the parameter until you are satisfied with the setpoint tracking. - If you observe a steady state error in the yaw setpoint increase the the integrator of the rate controller: [RO_YAW_RATE_I](../advanced_config/parameter_reference.md#RO_YAW_RATE_I) . + If you observe a steady state error in the yaw setpoint increase the integrator of the rate controller: [RO_YAW_RATE_I](../advanced_config/parameter_reference.md#RO_YAW_RATE_I) . ::: The rover is now ready to drive in [Stabilized mode](../flight_modes_rover/manual.md#stabilized-mode) and the configuration can be continued with [velocity tuning](velocity_tuning.md). @@ -29,7 +29,7 @@ The attitude controller uses the following structure: ![Rover Attitude Controller](../../assets/config/rover/rover_attitude_controller.png) -The rate and attitude controllers are cascaded, therefor we only require one integrator in the structure to eliminate steady state errors. +The rate and attitude controllers are cascaded, therefore we only require one integrator in the structure to eliminate steady state errors. We placed the integrator in the rate controller since it can run without the attitude controller but not the other way around. ## Parameter Overview diff --git a/docs/en/config_rover/basic_setup.md b/docs/en/config_rover/basic_setup.md index e729fc63284..9f99507acdc 100644 --- a/docs/en/config_rover/basic_setup.md +++ b/docs/en/config_rover/basic_setup.md @@ -129,7 +129,7 @@ In [Manual mode](../flight_modes_rover/manual.md#manual-mode) we can additionall - Differential Rover: $r=$ [RD_YAW_STK_GAIN](#RD_YAW_STK_GAIN), which enables adjusting the slope of the input mapping. This leads to a normalized steering input $\hat{\delta} = \delta \cdot r \in$ [-[RD_YAW_STK_GAIN](#RD_YAW_STK_GAIN), [RD_YAW_STK_GAIN](#RD_YAW_STK_GAIN)]. - Mecanum Rover: $r=$ [RM_YAW_STK_GAIN](#RM_YAW_STK_GAIN), which enables adjusting the slope of the input mapping. This leads to a normalized steering input $\hat{\delta} = \delta \cdot r \in$ [-[RM_YAW_STK_GAIN](#RM_YAW_STK_GAIN), [RM_YAW_STK_GAIN](#RM_YAW_STK_GAIN)]. -This scaling is useful to limit the normalized steering setpoint, if it is too aggresive for your rover in manual mode. +This scaling is useful to limit the normalized steering setpoint, if it is too aggressive for your rover in manual mode. You can experiment with the relationships graphically using the [PX4 SuperExpo Rover calculator](https://www.desmos.com/calculator/gwm8lrlanx). diff --git a/docs/en/config_rover/index.md b/docs/en/config_rover/index.md index 366377c8ab3..917c6911928 100644 --- a/docs/en/config_rover/index.md +++ b/docs/en/config_rover/index.md @@ -39,7 +39,7 @@ make px4_fmu-v6x_rover Note that configuration targets are constructed with the format "VENDOR_MODEL_VARIANT". -The built firmware can be installed as custom firmware, as shown above in in [Flashing the Rover Build](#flashing-the-rover-build). +The built firmware can be installed as custom firmware, as shown above in [Flashing the Rover Build](#flashing-the-rover-build). ::: info You can also enable the modules in default builds by adding these lines to your [board configuration](../hardware/porting_guide_config.md) (e.g. for fmu-v6x you might add them to [`main/boards/px4/fmu-v6x/default.px4board`](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6x/default.px4board)): diff --git a/docs/en/config_rover/rate_tuning.md b/docs/en/config_rover/rate_tuning.md index fd327d34efc..2bb44fe25d8 100644 --- a/docs/en/config_rover/rate_tuning.md +++ b/docs/en/config_rover/rate_tuning.md @@ -11,7 +11,7 @@ Configure the following [parameters](../advanced_config/parameters.md) in QGroun 1. [RO_YAW_RATE_LIM](#RO_YAW_RATE_LIM): Maximum yaw rate you want to allow for your rover. :::tip - Limiting the yaw rate is necessary if the rover is prone rolling over, loosing traction at high speeds or if passenger comfort is important. + Limiting the yaw rate is necessary if the rover is prone rolling over, losing traction at high speeds or if passenger comfort is important. Small rovers especially can be prone to rolling over when steering aggressively at high speeds. If this is the case: diff --git a/docs/en/config_rover/velocity_tuning.md b/docs/en/config_rover/velocity_tuning.md index bf0429d43f8..76463aca46d 100644 --- a/docs/en/config_rover/velocity_tuning.md +++ b/docs/en/config_rover/velocity_tuning.md @@ -54,7 +54,7 @@ To tune the velocity controller configure the following [parameters](../advanced ## Manual Position Mode Parameters -These steps are only necessary if you are tuning/want to unlock the manual [Position mode](../flight_modes_rover/manual.md#position-mode). Othwerwise, you can continue with [position tuning](position_tuning.md) where these same parameters will also be configured. +These steps are only necessary if you are tuning/want to unlock the manual [Position mode](../flight_modes_rover/manual.md#position-mode). Otherwise, you can continue with [position tuning](position_tuning.md) where these same parameters will also be configured. 1. [PP_LOOKAHD_GAIN](#PP_LOOKAHD_GAIN): When driving in a straight line (right stick centered) position mode leverages the same path following algorithm used in [auto modes](../flight_modes_rover/auto.md) called [pure pursuit](position_tuning.md#pure-pursuit-guidance-logic-info-only) to achieve the best possible straight line driving behaviour. This parameter determines how aggressive the controller will steer towards the path. @@ -99,7 +99,7 @@ The speed controller uses the following structure: The feed forward mapping is done by interpolating the speed setpoint from [-[RO_MAX_THR_SPEED](../advanced_config/parameter_reference.md#RO_MAX_THR_SPEED), [RO_MAX_THR_SPEED](../advanced_config/parameter_reference.md#RO_MAX_THR_SPEED)] to [-1, 1]. -For ackermann and differential rovers the bearing is aligned with the vehicle yaw. Therefor the bearing is simply sent as a yaw setpoint to the [yaw controller](attitude_tuning.md#attitude-controller-structure-info-only) and the speed setpoint is always defined in body x direction. +For ackermann and differential rovers the bearing is aligned with the vehicle yaw. Therefore the bearing is simply sent as a yaw setpoint to the [yaw controller](attitude_tuning.md#attitude-controller-structure-info-only) and the speed setpoint is always defined in body x direction. For mecanum vehicles, the bearing and yaw are decoupled. The direction is controlled by splitting the velocity vector into one speed component in body x direction and one in body y direction. Both these setpoint are then sent to their own closed loop speed controllers. diff --git a/docs/en/config_vtol/vtol_ice_shedding.md b/docs/en/config_vtol/vtol_ice_shedding.md index bf9ccc80afd..bf7f1b14593 100644 --- a/docs/en/config_vtol/vtol_ice_shedding.md +++ b/docs/en/config_vtol/vtol_ice_shedding.md @@ -6,7 +6,7 @@ Ice shedding is a feature that periodically spins unused motors in fixed-wing flight, to break off any ice that is starting to build up in the motors while it is still feasible to do so. -It is configured by the paramter `CA_ICE_PERIOD`. When it is 0, the feature is +It is configured by the parameter `CA_ICE_PERIOD`. When it is 0, the feature is disabled, when it is above 0, it sets the duration of the ice shedding cycle in seconds. In each cycle, the rotors are spun for two seconds at a motor output of 0.01. diff --git a/docs/en/contribute/dev_call.md b/docs/en/contribute/dev_call.md index fe0ecf558c5..2c5d4f63610 100644 --- a/docs/en/contribute/dev_call.md +++ b/docs/en/contribute/dev_call.md @@ -7,7 +7,7 @@ const { site } = useData();
-

This page may be out out of date. See the latest version.

+

This page may be out of date. See the latest version.

diff --git a/docs/en/contribute/index.md b/docs/en/contribute/index.md index adf08e6a79f..38a3124e147 100644 --- a/docs/en/contribute/index.md +++ b/docs/en/contribute/index.md @@ -7,7 +7,7 @@ const { site } = useData();
-

This page may be out out of date. See the latest version.

+

This page may be out of date. See the latest version.

diff --git a/docs/en/contribute/support.md b/docs/en/contribute/support.md index 71642e7aee9..ad90e3c4079 100644 --- a/docs/en/contribute/support.md +++ b/docs/en/contribute/support.md @@ -7,7 +7,7 @@ const { site } = useData();
-

This page may be out out of date. See the latest version.

+

This page may be out of date. See the latest version.

diff --git a/docs/en/debug/debug_values.md b/docs/en/debug/debug_values.md index ee27780c011..ba2c183c8ac 100644 --- a/docs/en/debug/debug_values.md +++ b/docs/en/debug/debug_values.md @@ -22,7 +22,7 @@ This tutorial shows how to send the MAVLink message `NAMED_VALUE_FLOAT` using th The code for this tutorial is available here: - [Debug Tutorial Code](https://github.com/PX4/PX4-Autopilot/blob/main/src/examples/px4_mavlink_debug/px4_mavlink_debug.cpp) -- [Enable the tutorial app](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v5/default.px4board) by ensuring the MAVLink debug app (**CONFIG_EXAMPLES_PX4_MAVLINK_DEBUG**) is in the config of your board and set set to 'y'. +- [Enable the tutorial app](https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v5/default.px4board) by ensuring the MAVLink debug app (**CONFIG_EXAMPLES_PX4_MAVLINK_DEBUG**) is in the config of your board and set to 'y'. All required to set up a debug publication is this code snippet. First add the header file: diff --git a/docs/en/debug/eclipse_jlink.md b/docs/en/debug/eclipse_jlink.md index 056f8ea1b57..ea622b7ee70 100644 --- a/docs/en/debug/eclipse_jlink.md +++ b/docs/en/debug/eclipse_jlink.md @@ -107,7 +107,7 @@ To enable this feature for use in Eclipse: ![NuttX: Menuconfig: CONFIG_DEBUG_TCBINFO](../../assets/debug/nuttx_tcb_task_aware.png) 1. Compile the **jlink-nuttx.so** library in the terminal by running the following command in the terminal: `make jlink-nuttx` -1. Modify Eclipse to use this libary. +1. Modify Eclipse to use this library. In the _J-Link GDB Server Setup_ configuration, update **Other options** to include `-rtos /home//Tools/jlink-nuttx.so`, as shown in the image below. ![Eclipse: GDB Segger Debug config RTOS aware: debugger tab](../../assets/debug/eclipse_settings_debug_config_gdb_segger_task_aware.png) diff --git a/docs/en/debug/plotting_realtime_uorb_data.md b/docs/en/debug/plotting_realtime_uorb_data.md index 6bb79ca1e40..118dc3d9580 100644 --- a/docs/en/debug/plotting_realtime_uorb_data.md +++ b/docs/en/debug/plotting_realtime_uorb_data.md @@ -70,7 +70,7 @@ cd ~/PX4-Autopilot make px4_sitl gz_x500 ``` -Open another terminal and start the `MicroXRCEAgent` to connect to the the simulator: +Open another terminal and start the `MicroXRCEAgent` to connect to the simulator: ```sh MicroXRCEAgent udp4 -p 8888; exec bash diff --git a/docs/en/debug/probe_mculink.md b/docs/en/debug/probe_mculink.md index ece2c2e9653..2912d59a89a 100644 --- a/docs/en/debug/probe_mculink.md +++ b/docs/en/debug/probe_mculink.md @@ -1,6 +1,6 @@ # MCU-Link Debug Probe -The [MCU-Link Debug Probe](https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcu-link-debug-probe:MCU-LINK) is a cheap, fast and highly capable debug probe that can serve as a stand-alone debug and console communicator whn working with Pixhawk boards. +The [MCU-Link Debug Probe](https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcu-link-debug-probe:MCU-LINK) is a cheap, fast and highly capable debug probe that can serve as a stand-alone debug and console communicator when working with Pixhawk boards. Key features: diff --git a/docs/en/debug/swd_debug.md b/docs/en/debug/swd_debug.md index 89188f6560f..d68a55e1e38 100644 --- a/docs/en/debug/swd_debug.md +++ b/docs/en/debug/swd_debug.md @@ -1,6 +1,6 @@ # SWD Debug Port -PX4 runs on ARM Cortex-M microcontrollers, which contain dedicated hardware for interactive debugging via the [_Serial Wire Debug (SWD)_][swd] interface and non-invasive profiling and high-bandwidth tracing via the [_Serial Wire Ouput (SWO)_][itm] and [_TRACE_ pins][etm]. +PX4 runs on ARM Cortex-M microcontrollers, which contain dedicated hardware for interactive debugging via the [_Serial Wire Debug (SWD)_][swd] interface and non-invasive profiling and high-bandwidth tracing via the [_Serial Wire Output (SWO)_][itm] and [_TRACE_ pins][etm]. The SWD debug interface allows direct, low-level, hardware access to the microcontroller's processor and peripherals, so it does not depend on any software on the device. Therefore it can be used to debug bootloaders and operating systems such as NuttX. @@ -27,9 +27,7 @@ The SWO pin can emit low-overhead, real-time profiling data with nanosecond time The TRACE pins require specialized debug probes to deal with the high bandwidth and subsequent datastream decoding. They are usually not accessible and are typically only used to debug very specific timing issues. - - -## Autopilot Debug Ports +## Autopilot Debug Ports {#debug-ports} Flight controllers commonly provide a single debug port that exposes both the [SWD Interface](#debug-signals) and [System Console](system_console). @@ -40,40 +38,52 @@ The debug port location and pinouts for a subset of autopilots are linked below: -| Autopilot | Debug Port | -| :---------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Holybro Pixhawk 6X-RT (FMUv6X-RT) | [Pixhawk Debug Full](#pixhawk-debug-full) | -| Holybro Pixhawk 6X (FMUv6x) | [Pixhawk Debug Full](#pixhawk-debug-full) | -| Holybro Pixhawk 5X (FMUv5x) | [Pixhawk Debug Full](#pixhawk-debug-full) | -| [Holybro Durandal](../flight_controller/durandal.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | -| [Holybro Kakute F7](../flight_controller/kakutef7.md#debug-port) | Solder pads | -| [Holybro Pixhawk 4 Mini](../flight_controller/pixhawk4_mini.md#debug-port) (FMUv5) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | -| [Holybro Pixhawk 4](../flight_controller/pixhawk4.md#debug_port) (FMUv5) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | -| [Drotek Pixhawk 3 Pro](../flight_controller/pixhawk3_pro.md#debug-port) (FMU-v4pro) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | -| [CUAV V5+](../flight_controller/cuav_v5_plus.md#debug-port) | 6-pin JST GH
Digikey: [BM06B-GHS-TBT(LF)(SN)(N)][bm06b-ghs-tbt(lf)(sn)(n)] (vertical mount), [SM06B-GHS-TBT(LF)(SN)(N)][sm06b-ghs-tbt(lf)(sn)(n)] (side mount) | -| [CUAV V5nano](../flight_controller/cuav_v5_nano.md#debug_port) | 6-pin JST GH
Digikey: [BM06B-GHS-TBT(LF)(SN)(N)][bm06b-ghs-tbt(lf)(sn)(n)] (vertical mount), [SM06B-GHS-TBT(LF)(SN)(N)][sm06b-ghs-tbt(lf)(sn)(n)] (side mount) | -| [3DR Pixhawk](../flight_controller/pixhawk.md#swd-port) | ARM 10-pin JTAG Connector (also used for FMUv2 boards including: _mRo Pixhawk_, _HobbyKing HKPilot32_). | +| Autopilot | Debug Port | +| :----------------------------------------------------------------------------------- | :---------------------------------------- | +| [Holybro Pixhawk 6X-RT](../flight_controller/pixhawk6x-rt.md#debug_port) (FMUv6X-RT) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [Holybro Pixhawk 6X](../flight_controller/pixhawk6x.md#debug_port) (FMUv6x) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [Holybro Pixhawk 5X](../flight_controller/pixhawk5x.md#debug_port) (FMUv5x) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [Holybro Durandal](../flight_controller/durandal.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | +| [Holybro Pixhawk 4](../flight_controller/pixhawk4.md#debug_port) (FMUv5) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | +| [Holybro Pixhawk 6X Pro](../flight_controller/pixhawk6x_pro.md#debug-port) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [Holybro Pixhawk 6C](../flight_controller/pixhawk6c.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [Holybro Pixhawk 6C Mini](../flight_controller/pixhawk6c_mini.md#debug_port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | +| [Holybro Pix32 v6](../flight_controller/holybro_pix32_v6.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [Holybro Pix32 v5](../flight_controller/holybro_pix32_v5.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | +| [Holybro Kakute H7](../flight_controller/kakuteh7.md#debug-port) | SWD pads and system console | +| [Holybro Kakute H7 mini](../flight_controller/kakuteh7mini.md#debug-port) | SWD pads and system console | +| [Holybro Kakute H7 V2](../flight_controller/kakuteh7v2.md#debug-port) | SWD pads and system console | +| [CUAV V5+](../flight_controller/cuav_v5_plus.md#debug-port) | Custom port but comes with adaptor cable | +| [CUAV V5nano](../flight_controller/cuav_v5_nano.md#debug_port) | Custom port but comes with adaptor cable | +| [CUAV Pixhawk V6X](../flight_controller/cuav_pixhawk_v6x.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [CUAV X25-SUPER](../flight_controller/cuav_x25-super.md#debug_port) | [Pixhawk Debug Mini] | +| [CUAV X25-EVO](../flight_controller/cuav_x25-evo.md#debug_port) | [Pixhawk Debug Mini] | +| [CUAV Nora](../flight_controller/cuav_nora.md#debug-port) | Custom port but comes with adaptor cable. | +| [ARK Pixhawk Autopilot Bus Carrier](../flight_controller/ark_pab.md#debug-port) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [NXP MR-VMU-RT1176](../flight_controller/nxp_mr_vmu_rt1176.md#debug_port) | [Pixhawk Debug Full](#pixhawk-debug-full) | +| [mRo Pixracer](../flight_controller/pixracer.md#debug-port) | [Pixhawk Debug Mini](#pixhawk-debug-mini) | +| [S-Vehicle E2](../flight_controller/svehicle_e2.md#debug-port) | [Pixhawk Debug Mini] | +| [AP-H743-R1](../flight_controller/x-mav_ap-h743r1.md#debug-port) | 4-pin JST GH (SWD only) | +| [mRo Control Zero F7](../flight_controller/mro_control_zero_f7.md#debug_port) | | - - -## Pixhawk Connector Standard Debug Ports +## Pixhawk Connector Standard Debug Ports {#pixhawk-standard-debug-ports} The Pixhawk project has defines a standard pinout and connector type for different Pixhawk FMU releases: -:::tip +::: tip Check your [specific board](#port-information) to confirm the port used. ::: -| FMU Version | Pixhawk Version | Debug Port | -| :---------- | :-------------------------------------------------------------- | :---------------------------------------- | -| FMUv2 | [Pixhawk / Pixhawk 1](../flight_controller/pixhawk.md#swd-port) | 10 pin ARM Debug | -| FMUv3 | Pixhawk 2 | 6 pin SUR Debug | -| FMUv4 | Pixhawk 3 | [Pixhawk Debug Mini](#pixhawk-debug-mini) | -| FMUv5 | Pixhawk 4 FMUv5 | [Pixhawk Debug Mini](#pixhawk-debug-mini) | -| FMUv5X | Pixhawk 5X | [Pixhawk Debug Full](#pixhawk-debug-full) | -| FMUv6 | Pixhawk 6 | [Pixhawk Debug Full](#pixhawk-debug-full) | -| FMUv6X | Pixhawk 6X | [Pixhawk Debug Full](#pixhawk-debug-full) | -| FMUv6X-RT | Pixhawk 6X-RT | [Pixhawk Debug Full](#pixhawk-debug-full) | +| FMU Version | Pixhawk Version | Debug Port | +| :---------- | :------------------ | :---------------------------------------- | +| FMUv2 | Pixhawk / Pixhawk 1 | 10 pin ARM Debug | +| FMUv3 | Pixhawk 2 | 6 pin SUR Debug | +| FMUv4 | Pixhawk 3 | [Pixhawk Debug Mini](#pixhawk-debug-mini) | +| FMUv5 | Pixhawk 4 FMUv5 | [Pixhawk Debug Mini](#pixhawk-debug-mini) | +| FMUv5X | Pixhawk 5X | [Pixhawk Debug Full](#pixhawk-debug-full) | +| FMUv6 | Pixhawk 6 | [Pixhawk Debug Full](#pixhawk-debug-full) | +| FMUv6X | Pixhawk 6X | [Pixhawk Debug Full](#pixhawk-debug-full) | +| FMUv6X-RT | Pixhawk 6X-RT | [Pixhawk Debug Full](#pixhawk-debug-full) | ::: info There FMU and Pixhawk versions are (only) consistent after FMUv5X. @@ -142,9 +152,7 @@ You can connect to the debug port using a [cable like this one](https://www.digi ![10-pin JST SH Cable](../../assets/debug/cable_10pin_jst_sh.jpg) - - -## Debug Probes for PX4 Hardware +## Debug Probes for PX4 Hardware {#debug-probes} Flight controllers commonly provide a [single debug port](#autopilot-debug-ports) that exposes both the [SWD Interface](#debug-signals) and [System Console](system_console). @@ -217,5 +225,3 @@ This reduces the risk or poor wiring contributing to debugging problems, and has [swd]: https://developer.arm.com/documentation/ihi0031/a/The-Serial-Wire-Debug-Port--SW-DP- [itm]: https://developer.arm.com/documentation/ddi0403/d/Appendices/Debug-ITM-and-DWT-Packet-Protocol?lang=en [etm]: https://developer.arm.com/documentation/ihi0064/latest/ -[bm06b-ghs-tbt(lf)(sn)(n)]: https://www.digikey.com/en/products/detail/jst-sales-america-inc/BM06B-GHS-TBT/807804 -[sm06b-ghs-tbt(lf)(sn)(n)]: https://www.digikey.com/en/products/detail/jst-sales-america-inc/SM06B-GHS-TB/807790 diff --git a/docs/en/dev_log/log_encryption.md b/docs/en/dev_log/log_encryption.md index e57bbba8410..c13a6080321 100644 --- a/docs/en/dev_log/log_encryption.md +++ b/docs/en/dev_log/log_encryption.md @@ -141,7 +141,7 @@ Note that the value is generated fresh for each log, and any value specified in You can use choose different locations for your keys as long as they aren't used by anything else. ::: -The key in `CONFIG_PUBLIC_KEY1` is the public key used to wrap the symmetric key in the the beginning of `.ulge` file (by default: see [SDLOG_EXCH_KEY](../advanced_config/parameter_reference.md#SDLOG_EXCH_KEY)). +The key in `CONFIG_PUBLIC_KEY1` is the public key used to wrap the symmetric key in the beginning of `.ulge` file (by default: see [SDLOG_EXCH_KEY](../advanced_config/parameter_reference.md#SDLOG_EXCH_KEY)). You can use the `rsa2048.pub` key for testing, or replace it with the path to your own public key in the file (see [Generate RSA Public & Private Keys](#generate-rsa-public-private-keys)). Build the firmware like this: diff --git a/docs/en/dronecan/ark_cannode.md b/docs/en/dronecan/ark_cannode.md index fdb403f7175..0c04ae1bcfd 100644 --- a/docs/en/dronecan/ark_cannode.md +++ b/docs/en/dronecan/ark_cannode.md @@ -28,7 +28,7 @@ Order this module from: - Pixhawk Standard SPI Connector - 7 Pin JST GH - PWM Connector - - 10 Pin JST JST + - 10 Pin JST - 8 PWM Outputs - Matches Pixhawk 4 PWM Connector Pinout - Pixhawk Standard Debug Connector @@ -77,7 +77,7 @@ DroneCAN configuration in PX4 is explained in more detail in [DroneCAN > Enablin You will need to enable the subscriber appropriate for each of the sensors that are connected to the ARK CANnode. -This is done using the the parameters named like `UAVCAN_SUB_*` in the parameter reference (such as [UAVCAN_SUB_ASPD](../advanced_config/parameter_reference.md#UAVCAN_SUB_ASPD), [UAVCAN_SUB_BARO](../advanced_config/parameter_reference.md#UAVCAN_SUB_BARO) etc.). +This is done using the parameters named like `UAVCAN_SUB_*` in the parameter reference (such as [UAVCAN_SUB_ASPD](../advanced_config/parameter_reference.md#UAVCAN_SUB_ASPD), [UAVCAN_SUB_BARO](../advanced_config/parameter_reference.md#UAVCAN_SUB_BARO) etc.). ## Ark CANNode Configuration diff --git a/docs/en/dronecan/ark_g5_rtk_heading_gps.md b/docs/en/dronecan/ark_g5_rtk_heading_gps.md index 80505235ce1..c42aff95f7d 100644 --- a/docs/en/dronecan/ark_g5_rtk_heading_gps.md +++ b/docs/en/dronecan/ark_g5_rtk_heading_gps.md @@ -103,7 +103,7 @@ You need to set necessary [DroneCAN](index.md) parameters and define offsets if ### Parameter references -This GPS is using ARK's private driver, the prameters below only exist on the firmware we ship the GPS with. You can set these params either in QGC or using the DroneCAN GUI Tool. +This GPS is using ARK's private driver, the parameters below only exist on the firmware we ship the GPS with. You can set these params either in QGC or using the DroneCAN GUI Tool. #### SEP_OFFS_YAW (float) diff --git a/docs/en/dronecan/holybro_h_rtk_zed_f9p_gps.md b/docs/en/dronecan/holybro_h_rtk_zed_f9p_gps.md index de1de365107..db45481cb0f 100644 --- a/docs/en/dronecan/holybro_h_rtk_zed_f9p_gps.md +++ b/docs/en/dronecan/holybro_h_rtk_zed_f9p_gps.md @@ -86,7 +86,7 @@ DroneCAN configuration in PX4 is explained in more detail in [DroneCAN > Enablin ### Sensor Position Configuration -- For the the single Rover the module should be mounted with the included mast. +- For the single Rover the module should be mounted with the included mast. - For the Dual ZED-F9P setup (moving baseline), the DroneCAN modules should be placed at least 30cm apart on the airframe and elevated on a mast also. See the following [mast](https://holybro.com/products/30-antenna-mount?_pos=20&_sid=67b49d76b&_ss=r). - F9P module arrow(s) should be pointing forward with respect to the autopilot orientation. diff --git a/docs/en/dronecan/index.md b/docs/en/dronecan/index.md index 4d4f1343d62..7fc99878875 100644 --- a/docs/en/dronecan/index.md +++ b/docs/en/dronecan/index.md @@ -152,7 +152,7 @@ DroneCAN peripherals connected to PX4 can also be [configured using parameters v By convention, parameters named with the prefix [CANNODE\_](../advanced_config/parameter_reference.md#CANNODE_BITRATE) have prefined meaning, and may be documented in the parameter reference. `CANNODE_` parameters prefixed with `CANNODE_PUB_` and `CANNODE_SUB_` enable the peripheral to publish or subscribe the associated DroneCAN message. These allow DroneCAN peripherals to be configured to only subscribe and publish messages that they actually need (in the same way that PX4 uses the corresponding `UAVCAN_PUB_`/`UAVCAN_SUB_` parameters). -Note that a peripheral might might not use `CANNODE_` parameters, in which case it may have to publish/subscribe to particular messages whether or not they are needed. +Note that a peripheral might not use `CANNODE_` parameters, in which case it may have to publish/subscribe to particular messages whether or not they are needed. The following sections provide additional detail on the PX4 and DroneCAN peripheral parameters used to enable particular features. @@ -285,7 +285,7 @@ Note that DroneCAN ESCs should be on their own dedicated CAN interface(s) becaus PX4 can control external LEDs on a connected DroneCAN peripheral using the standard DroneCAN [LightsCommand](https://dronecan.github.io/Specification/7._List_of_standard_data_types/#lightscommand) message. Up to 2 lights acan be controlled. -Each light can independently show [system status colours](../getting_started/led_meanings.md#ui-led), a fixed colour (commonly used for indciating aircraft orientation), or switch between both depending on arm state. +Each light can independently show [system status colours](../getting_started/led_meanings.md#ui-led), a fixed colour (commonly used for indicating aircraft orientation), or switch between both depending on arm state. See [DroneCAN Lights](lights.md) for full configuration details. diff --git a/docs/en/flight_controller/airlink.md b/docs/en/flight_controller/airlink.md index 76594fa2896..b59abb04c4e 100644 --- a/docs/en/flight_controller/airlink.md +++ b/docs/en/flight_controller/airlink.md @@ -59,7 +59,7 @@ AIRLink has two computers and integrated LTE Module: - Ethernet 10/100/1000 Native Gigabit - WiFi 802.11a/b/g/n/ac, Bluetooth - USB 3.0 Type C - - 2x Video: 4-Lane MIPI CSI (FPV Camera) and 4-Lane MIPI CSI with HMDI Input (Payload Camera) + - 2x Video: 4-Lane MIPI CSI (FPV Camera) and 4-Lane MIPI CSI with HDMI Input (Payload Camera) - **LTE/5G Connectivity Module** - Up to 600 Mbps bandwidth @@ -327,7 +327,7 @@ For PPM receivers please use RC Connector PPM pin located on the left side of th ## Outputs -AIRLink has 16 PWM ouputs. Main outputs 1-8 and connected to IO MCU. AUX outputs 1-8 are connected to FMU. +AIRLink has 16 PWM outputs. Main outputs 1-8 and connected to IO MCU. AUX outputs 1-8 are connected to FMU. | Output | Timer | Channel | | ------ | -------- | --------- | diff --git a/docs/en/flight_controller/mro_control_zero_f7.md b/docs/en/flight_controller/mro_control_zero_f7.md index 5848e7338fe..d40d8882a0e 100644 --- a/docs/en/flight_controller/mro_control_zero_f7.md +++ b/docs/en/flight_controller/mro_control_zero_f7.md @@ -73,14 +73,14 @@ To [build PX4](../dev_setup/building_px4.md) for this target: make mro_ctrl-zero-f7 ``` -## Debug Ports +## Debug Ports {#debug_port} ### Console Port The [PX4 System Console](../debug/system_console.md) runs on `USART7` using the pins listed below. This is a standard serial pinout, designed to connect to a [3.3V FTDI](https://www.digikey.com/en/products/detail/TTL-232R-3V3/768-1015-ND/1836393) cable (5V tolerant). -| mRo control zero f7 | | FTDI | +| mRo control zero f7 | | FTDI | | | ------------------- | ----------- | ---- | ---------------- | | 17 | USART7 Tx | 5 | FTDI RX (yellow) | | 19 | USART7 Rx | 4 | FTDI TX (orange) | diff --git a/docs/en/flight_controller/pixhawk5x.md b/docs/en/flight_controller/pixhawk5x.md index ad8b97e2328..8989739038d 100644 --- a/docs/en/flight_controller/pixhawk5x.md +++ b/docs/en/flight_controller/pixhawk5x.md @@ -132,7 +132,7 @@ Connector pin assignments are left to right (i.e. Pin 1 is the left-most pin). ::: - The [camera capture pin](../camera/fc_connected_camera.md#camera-capture-configuration) (`PI0`) is pin 2 on the AD&IO port, marked above as `FMU_CAP1`. -- _Pixhawk 5X_ pinouts can be downloaded in PDF from from [here](https://github.com/PX4/PX4-user_guide/blob/main/assets/flight_controller/pixhawk5x/pixhawk5x_pinout.pdf) or [here](https://cdn.shopify.com/s/files/1/0604/5905/7341/files/Holybro_Pixhawk5X_Pinout.pdf). +- _Pixhawk 5X_ pinouts can be downloaded in PDF from [here](https://github.com/PX4/PX4-user_guide/blob/main/assets/flight_controller/pixhawk5x/pixhawk5x_pinout.pdf) or [here](https://cdn.shopify.com/s/files/1/0604/5905/7341/files/Holybro_Pixhawk5X_Pinout.pdf). ## Serial Port Mapping diff --git a/docs/en/flight_controller/x-mav_ap-h743r1.md b/docs/en/flight_controller/x-mav_ap-h743r1.md index cb2ced1f67f..183f9c2a455 100644 --- a/docs/en/flight_controller/x-mav_ap-h743r1.md +++ b/docs/en/flight_controller/x-mav_ap-h743r1.md @@ -131,7 +131,7 @@ make x-mav_ap-h743r1_default Any multirotor/airplane/rover or boat that can be controlled using normal RC servos or Futaba S-Bus servos. The complete set of supported configurations can be found in the [Airframe Reference](../airframes/airframe_reference.md). -## Debug Port +## Debug Port {#debug_port} ### SWD diff --git a/docs/en/flight_modes_fw/mission.md b/docs/en/flight_modes_fw/mission.md index 20951630474..6dfde8ae1e4 100644 --- a/docs/en/flight_modes_fw/mission.md +++ b/docs/en/flight_modes_fw/mission.md @@ -56,7 +56,7 @@ Missions can be paused by switching out of mission mode to any other mode (such If the vehicle was not capturing images when it was paused, on resuming it will head from its _current position_ towards the same waypoint as it as was heading towards originally. If the vehicle was capturing images (has camera trigger items) it will instead head from its current position towards the last waypoint it traveled through (before pausing), and then retrace its path at the same speed and with the same camera triggering behaviour. This ensures that in survey/camera missions the planned path is captured. -A mission can be uploaded while the vehicle is paused, in which which case the current active mission item is set to 1. +A mission can be uploaded while the vehicle is paused, in which case the current active mission item is set to 1. ::: info When a mission is paused while the camera on the vehicle was triggering, PX4 sets the current active mission item to the previous waypoint, so that when the mission is restarted the vehicle will retrace its last mission leg. @@ -210,7 +210,7 @@ The diagram below shows the sorts of paths that you might expect. ![acc-rad](../../assets/flying/acceptance_radius_mission.png) Vehicles switch to the next waypoint as soon as they enter the acceptance radius. -This is defined by the "L1 distance", which is is computed from two parameters: [NPFG_DAMPING](../advanced_config/parameter_reference.md#NPFG_DAMPING) and [NPFG_PERIOD](../advanced_config/parameter_reference.md#NPFG_PERIOD), and the current ground speed. +This is defined by the "L1 distance", which is computed from two parameters: [NPFG_DAMPING](../advanced_config/parameter_reference.md#NPFG_DAMPING) and [NPFG_PERIOD](../advanced_config/parameter_reference.md#NPFG_PERIOD), and the current ground speed. By default, it's about 70 meters. The equation is: @@ -312,7 +312,7 @@ On _QGroundControl_ a popup button appears during landing to enable this. Aborting the landing results in a climb out to an orbit pattern centered above the land waypoint. The maximum of the aircraft's current altitude and [MIS_LND_ABRT_ALT](#MIS_LND_ABRT_ALT) is set as the abort orbit altitude height relative to (above) the landing waypoint. -Landing configuration (e.g. flaps, spoilers, landing airspeed) is disabled during abort and the aicraft flies in cruise conditions. +Landing configuration (e.g. flaps, spoilers, landing airspeed) is disabled during abort and the aircraft flies in cruise conditions. The abort command is disabled during the flare for safety. Operators may still manually abort the landing by switching to any manual mode, such as [Stabilized mode](../flight_modes_fw/stabilized.md)), though it should be noted that this is risky! @@ -352,7 +352,7 @@ Note that if the wheel controller is enabled ([FW_W_EN](#FW_W_EN)), the controll ::: info Nudging should not be used to supplement poor position control tuning. -If the vehicle is regularly showing poor tracking peformance on a defined path, please refer to the [fixed-wing control tuning guide](../flight_modes_fw/position.md) for instruction. +If the vehicle is regularly showing poor tracking performance on a defined path, please refer to the [fixed-wing control tuning guide](../flight_modes_fw/position.md) for instruction. ::: | Parameter | Description | @@ -363,7 +363,7 @@ If the vehicle is regularly showing poor tracking peformance on a defined path, ### Near Ground Safety Constraints -In landing mode, the distance sensor is used to determine proximity to the ground, and the airframe's geometry is used to calculate roll contraints to prevent wing strike. +In landing mode, the distance sensor is used to determine proximity to the ground, and the airframe's geometry is used to calculate roll constraints to prevent wing strike. ![Fixed-wing landing nudging](../../assets/flying/wing_geometry.png) diff --git a/docs/en/flight_modes_fw/takeoff.md b/docs/en/flight_modes_fw/takeoff.md index b95d0806e1d..9f837eda0e8 100644 --- a/docs/en/flight_modes_fw/takeoff.md +++ b/docs/en/flight_modes_fw/takeoff.md @@ -14,7 +14,7 @@ Vehicles are [hand or catapult launched](#catapult-hand-launch) by default, but - Flying vehicles will failsafe if they lose the altitude estimate. - Disarmed vehicles can switch to mode without valid altitude estimate but can't arm. - RC control switches can be used to change flight modes. -- RC stick movement is ignored in catapult takeoff but can can be used to nudge the vehicle in runway takeoff. +- RC stick movement is ignored in catapult takeoff but can be used to nudge the vehicle in runway takeoff. - The [Failure Detector](../config/safety.md#failure-detector) will automatically stop the engines if there is a problem on takeoff. @@ -111,7 +111,7 @@ The _launch detector_ is affected by the following parameters: ## Runway Takeoff {#runway_launch} -Runway takeoffs can be used by vehicles with landing gear and and steerable wheel (only). +Runway takeoffs can be used by vehicles with landing gear and steerable wheel (only). You will first need to enable the wheel controller using the parameter [FW_W_EN](#FW_W_EN). Vehicle should be centered and aligned with runway when takeoff is initiated. diff --git a/docs/en/flight_modes_mc/follow_me.md b/docs/en/flight_modes_mc/follow_me.md index 33b02a896e4..9392a697ae1 100644 --- a/docs/en/flight_modes_mc/follow_me.md +++ b/docs/en/flight_modes_mc/follow_me.md @@ -31,7 +31,7 @@ By default it will follow from directly behind the target at a distance of 8 met Users can adjust the follow angle, height and distance using an RC controller as shown above: - _Follow Height_ is controlled with the `up-down` input ("Throttle"). - Center the stick to keep follow the target at a constant hight. Raise or lower the stick to adjust height. + Center the stick to keep follow the target at a constant height. Raise or lower the stick to adjust height. - _Follow Distance_ is controlled with the `forward-back` input ("Pitch"). Pushing the stick forward increases the follow distance, pulling it back decreases the distance. - _Follow Angle_ is controlled with the `left-right` input ("Roll"). @@ -117,7 +117,7 @@ The altitude control mode determine whether the vehicle altitude is relative to - `2D + Terrain` makes the drone follow at a fixed height relative to the terrain underneath it, using information from a distance sensor. - If the vehicle does not have a distance sensor following will be identical to `2D tracking`. - Distance sensors aren't always accurate and vehicles may be "jumpy" when flying in this mode. - - Note that that height is relative to the ground underneath the vehicle, not the follow target. + - Note that height is relative to the ground underneath the vehicle, not the follow target. The drone may not follow altitude changes of the target! - `3D tracking` mode makes the drone follow at a height relative to the follow target, as supplied by its GPS sensor. diff --git a/docs/en/flight_modes_mc/mission.md b/docs/en/flight_modes_mc/mission.md index 1adf90e64f7..d49685bc147 100644 --- a/docs/en/flight_modes_mc/mission.md +++ b/docs/en/flight_modes_mc/mission.md @@ -59,7 +59,7 @@ Missions can be paused by switching out of mission mode to any other mode (such If the vehicle was not capturing images when it was paused, on resuming it will head from its _current position_ towards the same waypoint as it as was heading towards originally. If the vehicle was capturing images (has camera trigger items) it will instead head from its current position towards the last waypoint it traveled through (before pausing), and then retrace its path at the same speed and with the same camera triggering behaviour. This ensures that in survey/camera missions the planned path is captured. -A mission can be uploaded while the vehicle is paused, in which which case the current active mission item is set to 1. +A mission can be uploaded while the vehicle is paused, in which case the current active mission item is set to 1. ::: info When a mission is paused while the camera on the vehicle was triggering, PX4 sets the current active mission item to the previous waypoint, so that when the mission is restarted the vehicle will retrace its last mission leg. diff --git a/docs/en/flight_modes_mc/return.md b/docs/en/flight_modes_mc/return.md index f5aef18d38a..c3b45ccb598 100644 --- a/docs/en/flight_modes_mc/return.md +++ b/docs/en/flight_modes_mc/return.md @@ -48,7 +48,7 @@ This is useful when there are few obstacles near the destination, because it may ![Return mode cone](../../assets/flying/rtl_cone.jpg) -The cone affects the minimum return altitude if return mode is triggered within the cylinder defined by the maximum cone radius and `RTL_RETURN_ALT`: outside this cyclinder `RTL_RETURN_ALT` is used. +The cone affects the minimum return altitude if return mode is triggered within the cylinder defined by the maximum cone radius and `RTL_RETURN_ALT`: outside this cylinder `RTL_RETURN_ALT` is used. Inside the code the minimum return altitude is the intersection of the vehicle position with the cone, or `RTL_DESCEND_ALT` (whichever is higher). In other words, the vehicle must always ascend to at least `RTL_DESCEND_ALT` if below that value. diff --git a/docs/en/flight_modes_vtol/mission.md b/docs/en/flight_modes_vtol/mission.md index be4d19cf582..09693107fa1 100644 --- a/docs/en/flight_modes_vtol/mission.md +++ b/docs/en/flight_modes_vtol/mission.md @@ -11,7 +11,7 @@ For more information see the specific docs for each mode: - [Mission Mode (MC)](../flight_modes_mc/mission.md) - [Mission Mode (FW)](../flight_modes_fw/mission.md) -The following sections outline mission mode behaviour that is VTOL specificL. +The following sections outline mission mode behaviour that is VTOL specific. ## Mission Commands diff --git a/docs/en/flight_stack/controller_diagrams.md b/docs/en/flight_stack/controller_diagrams.md index 2a63e7e6d70..99440cf9134 100644 --- a/docs/en/flight_stack/controller_diagrams.md +++ b/docs/en/flight_stack/controller_diagrams.md @@ -109,7 +109,7 @@ Increasing aircraft pitch angle will cause an increase in height but also a decr Increasing the throttle will increase airspeed but also height will increase due to the increase in lift. Therefore, we have two inputs (pitch angle and throttle) which both affect the two outputs (airspeed and altitude) which makes the control problem challenging. -TECS offers a solution by respresenting the problem in terms of energies rather than the original setpoints. +TECS offers a solution by representing the problem in terms of energies rather than the original setpoints. The total energy of an aircraft is the sum of kinetic and potential energy. Thrust (via throttle control) increases the total energy state of the aircraft. A given total energy state can be achieved by arbitrary combinations of potential and kinetic energies. In other words, flying at a high altitude but at a slow speed can be equivalent to flying at a low altitude but at a faster airspeed in a total energy sense. We refer to this as the specific energy balance and it is calculated from the current altitude and true airspeed setpoint. The specific energy balance is controlled via the aircraft pitch angle. diff --git a/docs/en/flying/basic_flying_mc.md b/docs/en/flying/basic_flying_mc.md index 2d162396816..d6e781779d3 100644 --- a/docs/en/flying/basic_flying_mc.md +++ b/docs/en/flying/basic_flying_mc.md @@ -71,7 +71,7 @@ If you see the vehicle "twitch" during landing (turn down the motors, and then i ## Flight Controls/Commands Vehicle movement is controlled using the 4 basic commands: roll, yaw, pitch and throttle. -As the throttle is increased the rotors spin faster and the vehicle moves up, if the vehicle pitches forward then some of that that force will move the vehicle forward, if it rolls to the left/right, then some of that force will move the vehicle left/right, and changing the yaw spins the vehicle on its axis over the ground plane. +As the throttle is increased the rotors spin faster and the vehicle moves up, if the vehicle pitches forward then some of that force will move the vehicle forward, if it rolls to the left/right, then some of that force will move the vehicle left/right, and changing the yaw spins the vehicle on its axis over the ground plane. These commands therefore allow you to move left/right, spin left/right, forward/back, and up/down, respectively, as shown on the [Mode 2](../getting_started/rc_transmitter_receiver.md#remote-control-units-for-aircraft) RC controller shown below. diff --git a/docs/en/frames_multicopter/kits.md b/docs/en/frames_multicopter/kits.md index 2ba4018578d..96336fd1aa4 100644 --- a/docs/en/frames_multicopter/kits.md +++ b/docs/en/frames_multicopter/kits.md @@ -27,7 +27,7 @@ The following kits are currently available: ## Build Guides The build guides below show how to assemble a number of kits. -Many kits vary only a little between revisions (for example, the new kit might simply upgrade the flight controller used, and is otherwise identical), so these are likely to be be useful for building the kits in the section above. +Many kits vary only a little between revisions (for example, the new kit might simply upgrade the flight controller used, and is otherwise identical), so these are likely to be useful for building the kits in the section above. - [Holybro X500 v2 (Pixhawk 6C)](../frames_multicopter/holybro_x500v2_pixhawk6c.md) - [Holybro X500 v2 (Pixhawk 5X)](../frames_multicopter/holybro_x500V2_pixhawk5x.md) — Discontinued (v2 kit uses Pixhawk 6c) diff --git a/docs/en/frames_plane/reptile_dragon_2.md b/docs/en/frames_plane/reptile_dragon_2.md index be2aa272748..9ae56737914 100644 --- a/docs/en/frames_plane/reptile_dragon_2.md +++ b/docs/en/frames_plane/reptile_dragon_2.md @@ -81,7 +81,7 @@ The airplane needs some assembly out of the box. Servos, wings, and the tail will need to be installed. ::: info -For this portion of assembly, the instructions included with the kit should be sufficent, but some helpful tips are listed below. +For this portion of assembly, the instructions included with the kit should be sufficient, but some helpful tips are listed below. ::: ### Gluing Foam @@ -209,7 +209,7 @@ An alternative carrier board is the Holybro Pixhawk 5X carrier. The carrier comes installed in a plastic case. While the case does look nice, it is extra weight, so the carrier was removed from the case. -Once removed from the case, the ARK6X was installed, and a protective cover fitted ontop. +Once removed from the case, the ARK6X was installed, and a protective cover fitted on top. ![Flight computer carrier board](../../assets/airframes/fw/reptile_dragon_2/holybro_5x.jpg) @@ -337,7 +337,7 @@ For more information see [TBS Crossfire (CRSF) Telemetry](../telemetry/crsf_tele ### `msp_osd` Module -The `msp_osd` module steams MSP telemetry to a selected serial port. +The `msp_osd` module streams MSP telemetry to a selected serial port. The Caddx Vista Air Unit supports listening to MSP telemetry and will show the received telemetry values in its OSD (on screen display). 1. In the PX4 board config tool, navigate to the `drivers` submenu, then scroll down to highlight `OSD`. diff --git a/docs/en/frames_plane/turbo_timber_evolution.md b/docs/en/frames_plane/turbo_timber_evolution.md index 325aada1f94..b18d83916c1 100644 --- a/docs/en/frames_plane/turbo_timber_evolution.md +++ b/docs/en/frames_plane/turbo_timber_evolution.md @@ -78,7 +78,7 @@ A long M3 nylon screw and a washer on the underside, followed by a washer and st ![Window and front fuselage (hatch) with FPV Pod mounted on top](../../assets/airframes/fw/turbo_timber_evolution/fpv_pod_hatch.jpg) -![Underside of hatch showing the FPV pod attachement screws and wires pulled through](../../assets/airframes/fw/turbo_timber_evolution/hatch_underside.jpg) +![Underside of hatch showing the FPV pod attachment screws and wires pulled through](../../assets/airframes/fw/turbo_timber_evolution/hatch_underside.jpg) ## Pitot Pod @@ -138,7 +138,7 @@ Power for the servo and lighting will be provided by the "BEC" power supply in t The TTE is very flexible when it comes to battery options. I use both a 3.6Ah 4S Turnigy pack as well as a Upgrade Energy 4s2p liion pack. -While the 3.6Ah LiPo is inexpensive, nearly twice the flight time (24 minutes vs 12 minutes) can be acheived with the Upgrade Energy Liion pack. +While the 3.6Ah LiPo is inexpensive, nearly twice the flight time (24 minutes vs 12 minutes) can be achieved with the Upgrade Energy Liion pack. ![Image of batteries used for the build](../../assets/airframes/fw/turbo_timber_evolution/batteries.jpg) @@ -165,10 +165,10 @@ Similarly, a JST PH to std spaced headers adapter was made, and it was also left #### RC Receiver -A custom cable was made to connect the ExpressLRS RX ([RC Reciever](../getting_started/rc_transmitter_receiver.md)) to the Pixhawk 4 Mini. +A custom cable was made to connect the ExpressLRS RX ([RC Receiver](../getting_started/rc_transmitter_receiver.md)) to the Pixhawk 4 Mini. Because the Pixhawk 4 Mini has limited uarts, the RX was connected to RC input which does not have a TX pin. -This means that the RX will only send control data to the FCU but telemtry cannot be sent to the RX from the FCU. +This means that the RX will only send control data to the FCU but telemetry cannot be sent to the RX from the FCU. Heatshrink was used to secure the dupont connector of the cable such that it cannot back out off the headers of the ExpressLRS RX. #### FPV Pod & Airspeed Cable @@ -177,7 +177,7 @@ Another custom cable was made to connect the Caddx Vista FPV transmitter to the A Molex microfit was added close to the Vista so that it could be easily disconnected without needing to gain access to the Pixhawk. As the name implies, the `UART/I2C B` port provides both a UART and I2C interface. This port is split with the custom cable and one side provides power and data to the I2C airspeed sensor, while the other side provides power and UART TX/RX to the Caddx Vista. -From the UART/I2C B port, 5V, GND, and I2C SCL/SDA, are connected to the I2C airspeed sensor, while just serial RX and TX are connected to the Caddx Vista (Ground is provided the seperate battery power/gnd leads for the Vista) +From the UART/I2C B port, 5V, GND, and I2C SCL/SDA, are connected to the I2C airspeed sensor, while just serial RX and TX are connected to the Caddx Vista (Ground is provided the separate battery power/gnd leads for the Vista) The [msp_osd](../modules/modules_driver.md#msp-osd) module is used to stream telemetry to the Caddx Vista which can be seen on the DJI Goggles with the "custom OSD" feature enabled. @@ -192,7 +192,7 @@ Heatshrink was used to electrically insulate the bare board and the radio was in Overall, this build was a success. -Even with the added weight of the Pixhawk 4 Mini installation, the airplane balances well and has plenty of power to retain its original STOL characterisitics. +Even with the added weight of the Pixhawk 4 Mini installation, the airplane balances well and has plenty of power to retain its original STOL characteristics. PX4 is easily capable of stabilizing the airplane and fine tuning of the rate loops were accomplished using [fixed-wing autotuning](../config/autotune_fw.md). The results of tuning can be found in the [parameter file linked below](#parameter-file). diff --git a/docs/en/frames_sub/bluerov2.md b/docs/en/frames_sub/bluerov2.md index 7a163ba2bba..4810ba855be 100644 --- a/docs/en/frames_sub/bluerov2.md +++ b/docs/en/frames_sub/bluerov2.md @@ -40,7 +40,7 @@ the [Airframe Reference](../airframes/airframe_reference.md#vectored-6-dof-uuv): | Manual | Direct manual control of yaw and thrust. | | Acro | Manual control of yaw/thrust, but keeps roll/pitch zero | | Altitude | Manual control of x/y thrust and yaw. Control of height with PID, manually controlled by user. Keeps roll/pitch zero | -| Position | Controlls x/y/z and yaw. Manually controlled by user. Keeps roll/pitch zero | +| Position | Controls x/y/z and yaw. Manually controlled by user. Keeps roll/pitch zero | ## Airframe Configuration diff --git a/docs/en/frames_vtol/vtol_tiltrotor_omp_hobby_zmo_fpv.md b/docs/en/frames_vtol/vtol_tiltrotor_omp_hobby_zmo_fpv.md index d92f9eb0f66..af6bcfe46ea 100644 --- a/docs/en/frames_vtol/vtol_tiltrotor_omp_hobby_zmo_fpv.md +++ b/docs/en/frames_vtol/vtol_tiltrotor_omp_hobby_zmo_fpv.md @@ -79,7 +79,7 @@ The following tools were used for this build. ### Preparations Remove the original flight controller, ESC and wing connector cables. -Also remove the the propellers. +Also remove the propellers. This will help you with the handling of the vehicle and will reduce the risk of an injury due to an unintentional motor startup. ZMO FPV in it's original state. @@ -97,7 +97,7 @@ Flight controller and wing connectors removed from the vehicle. 1. Unsolder the 3 female banana plug connectors of the rear motor (might not be necessary for the Pixhawk 6 integration). 1. Screw the ESC back in place with 4 M2.5 x 12 screws. 1. Shorten the rear motor wires and solder them as shown in the picture into place. -1. Solder signal and GND wires to the PWM input ot the ESC. +1. Solder signal and GND wires to the PWM input to the ESC. ![ESC 01](../../assets/airframes/vtol/omp_hobby_zmo_fpv/esc-01.jpg) diff --git a/docs/en/gps_compass/index.md b/docs/en/gps_compass/index.md index 60b22b9558e..322ab6d9bb4 100644 --- a/docs/en/gps_compass/index.md +++ b/docs/en/gps_compass/index.md @@ -186,9 +186,9 @@ Some of GNSS terms that are useful for interpreting the data include: - `DOP`: Dilution of position (dimensionless). This is a measure of the geometric quality of satellite positions and their effect on the precision of the GPS receiver's calculations. - `EPH`: Standard deviation of horizontal position error (metres). - This represents the the uncertainty in the GPS fix latitude and longitude. + This represents the uncertainty in the GPS fix latitude and longitude. - `EPV`: Standard deviation of vertical position error (metres). - This represents the the uncertainty in the GPS fix altitude. + This represents the uncertainty in the GPS fix altitude. ### DOP vs EPH/EPV diff --git a/docs/en/gps_compass/magnetometer.md b/docs/en/gps_compass/magnetometer.md index 2e6ce4f524e..1e79c546aeb 100644 --- a/docs/en/gps_compass/magnetometer.md +++ b/docs/en/gps_compass/magnetometer.md @@ -22,7 +22,7 @@ If it fails before flight, arming will be denied. ### Compass Parts PX4 can be used with many magnetometer parts, including: Bosch BMM 150 MEMS (via I2C bus), HMC5883 / HMC5983 (I2C or SPI), IST8310 (I2C), LIS3MDL (I2C or SPI), RM3100, and more. -Other supported magnetometer parts and their busses can be inferred from the drivers listed in [Modules Reference: Magnetometer (Driver)](../modules/modules_driver_magnetometer.md). +Other supported magnetometer parts and their buses can be inferred from the drivers listed in [Modules Reference: Magnetometer (Driver)](../modules/modules_driver_magnetometer.md). These parts are included in stand alone compass modules, combined compass/GNSS modules, and also in many flight controllers, @@ -55,7 +55,7 @@ Note: Internal compasses are not recommended for real use as a heading source, because the performance is almost always very poor. -This is particularly true on on small vehicles where the flight controller has to be mounted close to motor/ESC power lines and other sources of electromagnetic interference. +This is particularly true on small vehicles where the flight controller has to be mounted close to motor/ESC power lines and other sources of electromagnetic interference. While they may be better on larger vehicles (e.g. VTOL), where it is possible to reduce electromagnetic interference by mounting the flight controller a long way from power supply lines, an external compass will almost always be better. ::: tip diff --git a/docs/en/gps_compass/rtk_gps_cuav_c-rtk2.md b/docs/en/gps_compass/rtk_gps_cuav_c-rtk2.md index bb8c4630e3d..d304416748c 100644 --- a/docs/en/gps_compass/rtk_gps_cuav_c-rtk2.md +++ b/docs/en/gps_compass/rtk_gps_cuav_c-rtk2.md @@ -10,7 +10,7 @@ In addition to surveying/mapping, it is suitable for many other use-cases, inclu - High-performance H7 processor - High precision industrial grade IMU -- Support RTK and save RAW raw data (PPK) at the same time +- Support RTK and save raw data (PPK) at the same time - Multi-satellite and multi-frequency receivers - UAVCAN/Dronecan protocol - Support hotshoe and shutter trigger diff --git a/docs/en/gps_compass/rtk_gps_gem1305.md b/docs/en/gps_compass/rtk_gps_gem1305.md index 3872b53faa6..9309c85ff35 100644 --- a/docs/en/gps_compass/rtk_gps_gem1305.md +++ b/docs/en/gps_compass/rtk_gps_gem1305.md @@ -77,7 +77,7 @@ The 1.25mm pitch 6P connector (from left: PIN1 to PIN6) supports UART for GNSS a ## Hardware Setup RTK requires a base RTK module attached to the ground station, and a rover RTK module on the vehicle. -The data from the base needs to be transmitted to the drone via telemetry radio and inputed into the RTK receiver on the rover. +The data from the base needs to be transmitted to the drone via telemetry radio and inputted into the RTK receiver on the rover. ![RTK setup overview](../../assets/hardware/gps/datagnss_gem1305/setup_overview.png) diff --git a/docs/en/gps_compass/rtk_gps_locosys_r1.md b/docs/en/gps_compass/rtk_gps_locosys_r1.md index a42ae306278..a8b4200e03d 100644 --- a/docs/en/gps_compass/rtk_gps_locosys_r1.md +++ b/docs/en/gps_compass/rtk_gps_locosys_r1.md @@ -26,7 +26,7 @@ For an equivalent GPS module with a compass try: [LOCOSYS Hawk R2](../gps_compas - Fast TTFF at low signal level - Free hybrid ephemeris prediction to achieve faster cold start - Default 5Hz, up to 10 Hz update rate (SBAS support 5Hz only). -- Build-in super capacitor to reserve system data for rapid satellite acquisition +- Built-in super capacitor to reserve system data for rapid satellite acquisition ![LOCOSYS Hawk R1](../../assets/hardware/gps/locosys_hawk_a1/locosys_hawk_a1_gps.png) diff --git a/docs/en/gps_compass/rtk_gps_locosys_r2.md b/docs/en/gps_compass/rtk_gps_locosys_r2.md index 0f45196913a..d39fe4bdb16 100644 --- a/docs/en/gps_compass/rtk_gps_locosys_r2.md +++ b/docs/en/gps_compass/rtk_gps_locosys_r2.md @@ -22,8 +22,8 @@ The fast time-to-first-fix, RTK convergence, superior sensitivity, low power con - Fast TTFF at low signal level - Free hybrid ephemeris prediction to achieve faster cold start - Default 5Hz, up to 10 Hz update rate (SBAS support 5Hz only) -- Build-in super capacitor to reserve system data for rapid satellite acquisition -- Build-in 3 axis compass function +- Built-in super capacitor to reserve system data for rapid satellite acquisition +- Built-in 3 axis compass function - Three LED indicator for Power, PPS and Data transmit ![LOCOSYS Hawk R2](../../assets/hardware/gps/locosys_hawk_a1/locosys_hawk_a1_gps.png) diff --git a/docs/en/gps_compass/septentrio_mosaic-go.md b/docs/en/gps_compass/septentrio_mosaic-go.md index d77e94112f2..85a1c55e99f 100644 --- a/docs/en/gps_compass/septentrio_mosaic-go.md +++ b/docs/en/gps_compass/septentrio_mosaic-go.md @@ -108,7 +108,7 @@ To enable multi-antenna attitude determination, follow the following procedure: These can be compensated for with the heading parameters provided by the Septentrio driver in PX4. ::: info -For optimal heading results, the two antennas should be seperated by at least 30cm / 11.8 in (ideally 50cm / 19.7in or more). +For optimal heading results, the two antennas should be separated by at least 30cm / 11.8 in (ideally 50cm / 19.7in or more). For additional configuration of the dual antenna setup, please refer to our [Knowledge Base](https://support.septentrio.com/l/858493/2022-04-19/xgrqd) or the [hardware manual](https://web.septentrio.com/l/858493/2022-04-19/xgrql). ::: diff --git a/docs/en/hardware/board_support_guide.md b/docs/en/hardware/board_support_guide.md index 24e12c77823..7f952135f8f 100644 --- a/docs/en/hardware/board_support_guide.md +++ b/docs/en/hardware/board_support_guide.md @@ -53,7 +53,7 @@ PX4 generally only supports boards that are commercially available, which typica ### VER and REV ID (Hardware Revision and Version Sensing) {#ver_rev_id} FMUv5 and onwards have an electrical sensing mechanism. -This sensing coupled with optional configuration data will be used to define hardware’s configuration with respect to a mandatory device and power supply configuration. Manufacturers must obtain the VER and REV ID from PX4 board maintainers by issuing a PR to ammend the [DS-018 Pixhawk standard](https://github.com/pixhawk/Pixhawk-Standards) for board versions and revisions. +This sensing coupled with optional configuration data will be used to define hardware’s configuration with respect to a mandatory device and power supply configuration. Manufacturers must obtain the VER and REV ID from PX4 board maintainers by issuing a PR to amend the [DS-018 Pixhawk standard](https://github.com/pixhawk/Pixhawk-Standards) for board versions and revisions. Because these boards are 100% compliant with the Pixhawk standard, the values assigned for VER and REV ID are the defaults for that FMU Version. diff --git a/docs/en/hardware/drone_parts.md b/docs/en/hardware/drone_parts.md index 405b79b08e3..e4d80f79647 100644 --- a/docs/en/hardware/drone_parts.md +++ b/docs/en/hardware/drone_parts.md @@ -1,4 +1,4 @@ -# Hardware Hardware Selection & Setup +# Hardware Selection & Setup This section contains information the components that might be used in a drone, and how they are set up. diff --git a/docs/en/mavlink/adding_messages.md b/docs/en/mavlink/adding_messages.md index 74a97e8664d..de0091a4ae6 100644 --- a/docs/en/mavlink/adding_messages.md +++ b/docs/en/mavlink/adding_messages.md @@ -39,7 +39,7 @@ Once the message headers for your definitions are generated in the PX4 build, yo 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 []` command to verify in real-time that your message is published and the rate (see [uORB Messaging](../middleware/uorb.md#uorb-top-command)). +You should first use the `uorb top []` 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: diff --git a/docs/en/middleware/uorb.md b/docs/en/middleware/uorb.md index 5c29c366656..3c8e78e0105 100644 --- a/docs/en/middleware/uorb.md +++ b/docs/en/middleware/uorb.md @@ -163,7 +163,7 @@ For the full list of versioned and non-versioned messages see: [uORB Message Ref For more on PX4 and ROS 2 communication, see [PX4-ROS 2 Bridge](../ros/ros2_comm.md). ::: info -ROS 2 plans to natively support message versioning in the future, but this is not implememented yet. +ROS 2 plans to natively support message versioning in the future, but this is not implemented yet. See the related ROS Enhancement Proposal ([REP 2011](https://github.com/ros-infrastructure/rep/pull/358)). See also this [Foxglove post](https://foxglove.dev/blog/sending-ros2-message-types-over-the-wire) on message hashing and type fetching. ::: diff --git a/docs/en/middleware/uxrce_dds.md b/docs/en/middleware/uxrce_dds.md index f273efb476f..aa0bd8cd4f7 100644 --- a/docs/en/middleware/uxrce_dds.md +++ b/docs/en/middleware/uxrce_dds.md @@ -34,7 +34,7 @@ Code that wants to subscribe/publish to PX4 does have a dependency on client-sid ## Code Generation -The PX4 [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) is generated at build time and included in PX4 firmare by default. +The PX4 [uxrce_dds_client](../modules/modules_system.md#uxrce-dds-client) is generated at build time and included in PX4 firmware by default. The agent has no dependency on client code. It can be built standalone or in a ROS 2 workspace, or installed as a snap package on Ubuntu. diff --git a/docs/en/neural_networks/nn_module_utilities.md b/docs/en/neural_networks/nn_module_utilities.md index b1df217ded8..cf6e29d5d22 100644 --- a/docs/en/neural_networks/nn_module_utilities.md +++ b/docs/en/neural_networks/nn_module_utilities.md @@ -41,7 +41,7 @@ This only works for some flight controllers, so you might have to use an RC cont This specifies what you want to create, you can read more about this in the [Control Interface](../ros2/px4_ros2_control_interface.md). In this case we register an arming check and a mode. 2. Wait for a [RegisterExtComponentReply](../msg_docs/RegisterExtComponentReply.md). - This will give feedback on wether the mode registration was successful, and what the mode and arming check id is for the new mode. + This will give feedback on whether the mode registration was successful, and what the mode and arming check id is for the new mode. 3. [Optional] With the mode id, publish a [VehicleControlMode](../msg_docs/VehicleControlMode.md) message on the `config_control_setpoints` topic. Here you can configure what other modules run in parallel. The example controller replaces everything, so it turns off allocation. @@ -71,7 +71,7 @@ For these messages to be saved in your logs you need to include `debug` in the [ The module has two includes for measuring the inference times. The first one is a driver that works on the actual flight controller units, but a second one, `chrono`, is loaded for SITL testing. -Which timing library is included and used is based on wether PX4 is built with NUTTX or not. +Which timing library is included and used is based on whether PX4 is built with NUTTX or not. ## Changing the setpoint diff --git a/docs/en/peripherals/adsb_flarm.md b/docs/en/peripherals/adsb_flarm.md index 1e5207cc5d8..b43c2a082a1 100644 --- a/docs/en/peripherals/adsb_flarm.md +++ b/docs/en/peripherals/adsb_flarm.md @@ -53,7 +53,7 @@ The TX and RX on the flight controller must be connected to the RX and TX on the ### Port Configuration -The recievers are configured in the same way as any other [MAVLink Peripheral](../peripherals/mavlink_peripherals.md). +The receivers are configured in the same way as any other [MAVLink Peripheral](../peripherals/mavlink_peripherals.md). The only _specific_ setup is that the port baud rate must be set to 57600 and the a low-bandwidth profile (`MAV_X_MODE`). Assuming you have connected the device to the TELEM2 port, [set the parameters](../advanced_config/parameters.md) as shown: @@ -74,7 +74,7 @@ Configure the action when there is a potential collision using the parameter bel | Parameter | Description | | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [NAV_TRAFF_AVOID](../advanced_config/parameter_reference.md#NAV_TRAFF_AVOID) | Enable traffic avoidance mode specify avoidance response. 0: Disable, 1: Warn only, 2: Return mode, 3: Land mode. | -| [NAV_TRAFF_A_HOR](../advanced_config/parameter_reference.md#NAV_TRAFF_A_HOR) | Horizonal radius of cylinder around the vehicle that defines its airspace (i.e. the airspace in the ground plane). | +| [NAV_TRAFF_A_HOR](../advanced_config/parameter_reference.md#NAV_TRAFF_A_HOR) | Horizontal radius of cylinder around the vehicle that defines its airspace (i.e. the airspace in the ground plane). | | [NAV_TRAFF_A_VER](../advanced_config/parameter_reference.md#NAV_TRAFF_A_VER) | Vertical height above and below vehicle of the cylinder that defines its airspace (also see [NAV_TRAFF_A_HOR](#NAV_TRAFF_A_HOR)). | | [NAV_TRAFF_COLL_T](../advanced_config/parameter_reference.md#NAV_TRAFF_COLL_T) | Collision time threshold. Avoidance will trigger if the estimated time until collision drops below this value (the estimated time is based on relative speed of traffic and UAV). | @@ -136,8 +136,8 @@ Use with care in real flight! To enable this feature: 1. Uncomment the code in `AdsbConflict::run_fake_traffic()`([AdsbConflict.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/adsb/AdsbConflict.cpp#L342C1-L342C1)). -1. Rebuild and run PX4. -1. Execute the [`navigator fake_traffic` command](../modules/modules_controller.md#navigator) in the [QGroundControl MAVLink Shell](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html) (or some other [PX4 Console or MAVLink shell](../debug/consoles.md), such as the PX4 simulator terminal). +2. Rebuild and run PX4. +3. Execute the [`navigator fake_traffic` command](../modules/modules_controller.md#navigator) in the [QGroundControl MAVLink Shell](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_console.html) (or some other [PX4 Console or MAVLink shell](../debug/consoles.md), such as the PX4 simulator terminal). The code in `run_fake_traffic()` is then executed. You should see ADS-B warnings in the Console/MAVLink shell, and QGC should also show an ADS-B traffic popup. @@ -147,7 +147,7 @@ These simulate ADS-B traffic where there may be a conflict, where there won't be ::: details Information about the test methods -The relevent methods are defined in [AdsbConflict.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/adsb/AdsbConflict.cpp#L342C1-L342C1). +The relevant methods are defined in [AdsbConflict.cpp](https://github.com/PX4/PX4-Autopilot/blob/main/src/lib/adsb/AdsbConflict.cpp#L342C1-L342C1). #### `run_fake_traffic()` method diff --git a/docs/en/peripherals/dshot.md b/docs/en/peripherals/dshot.md index 2030946d1a9..23de5453402 100644 --- a/docs/en/peripherals/dshot.md +++ b/docs/en/peripherals/dshot.md @@ -56,7 +56,7 @@ See [here](../modules/modules_driver.md#dshot) for a full reference of the suppo The most important ones are: -- Make a motor connected to to FMU output pin 1 beep (helps with identifying motors) +- Make a motor connected to FMU output pin 1 beep (helps with identifying motors) ```sh dshot beep1 -m 1 @@ -128,7 +128,7 @@ The provided telemetry includes: To enable this feature (on ESCs that support it): 1. Join all the telemetry wires from all the ESCs together, and then connect them to one of the RX pins on an unused flight controller serial port. -1. Enable telemetry on that serial port using [DSHOT_TEL_CFG](../advanced_config/parameter_reference.md#DSHOT_TEL_CFG). +2. Enable telemetry on that serial port using [DSHOT_TEL_CFG](../advanced_config/parameter_reference.md#DSHOT_TEL_CFG). After a reboot you can check if telemetry is working (make sure the battery is connected) using: @@ -136,11 +136,11 @@ After a reboot you can check if telemetry is working (make sure the battery is c dshot esc_info -m 1 ``` -:::tip +::: tip You may have to configure [MOT_POLE_COUNT](../advanced_config/parameter_reference.md#MOT_POLE_COUNT) to get the correct RPM values. ::: -:::tip +::: tip Not all DSHOT-capable ESCs support `[esc_info]`(e.g. APD 80F3x), even when telemetry is supported and enabled. The resulting error is: @@ -170,7 +170,7 @@ It's setup and use is independent of bidirectional DShot. The ESC must be connected to FMU outputs only. These will be labeled `MAIN` on flight controllers that only have one PWM bus, and `AUX` on controllers that have both `MAIN` and `AUX` ports (i.e. FCs that have an IO board). -:::warning **Limited hardware support** +::: warning **Limited hardware support** This feature is only supported on flight controllers with the following processors: - STM32H7: First four FMU outputs diff --git a/docs/en/peripherals/esc_motors.md b/docs/en/peripherals/esc_motors.md index 7fddeb999dc..8849c357de5 100644 --- a/docs/en/peripherals/esc_motors.md +++ b/docs/en/peripherals/esc_motors.md @@ -11,7 +11,7 @@ The following list is non-exhaustive. | ESC Device | Protocols | Firmwares | Notes | | ------------------------------ | ------------------------------------ | ------------------------ | ----------------------------------------------------- | -| [ARK 4IN1 ESC] | [Dshot], [PWM] | [AM32] | Has versions with/without connnectors | +| [ARK 4IN1 ESC] | [Dshot], [PWM] | [AM32] | Has versions with/without connectors | | [Holybro Kotleta 20] | [DroneCAN], [PWM] | [PX4 Sapog ESC Firmware] | | | [Vertiq Motor & ESC modules] | [Dshot], [OneShot], Multishot, [PWM] | Vertiq firmware | Larger modules support DroneCAN, ESC and Motor in one | | [RaccoonLab CAN PWM ESC nodes] | [DroneCAN], Cyphal | | Cyphal and DroneCAN notes for PWM ESC | diff --git a/docs/en/peripherals/frsky_telemetry.md b/docs/en/peripherals/frsky_telemetry.md index 42da72065f5..b0f17e1dab9 100644 --- a/docs/en/peripherals/frsky_telemetry.md +++ b/docs/en/peripherals/frsky_telemetry.md @@ -166,7 +166,7 @@ D-Port receivers transmit the following messages (from [here](https://github.com ## FrSky Telemetry Receivers -Pixhawk/PX4 supports D (old) and S (new) FrSky telemetry. The table belows all FrSky receivers that support telemetry via a D/S.PORT (in theory all of these should work). +Pixhawk/PX4 supports D (old) and S (new) FrSky telemetry. The table below lists all FrSky receivers that support telemetry via a D/S.PORT (in theory all of these should work). :::tip Note that the X series receivers listed below are recommended (e.g. XSR, X8R). The R and G series have not been tested/validated by the test team, but should work. diff --git a/docs/en/peripherals/pwm_escs_and_servo.md b/docs/en/peripherals/pwm_escs_and_servo.md index f1bd89a7ef8..df523713af7 100644 --- a/docs/en/peripherals/pwm_escs_and_servo.md +++ b/docs/en/peripherals/pwm_escs_and_servo.md @@ -65,7 +65,7 @@ In this case the wire will normally be connected to the flight controller servo PWM motors and servos are configured using the [Actuator Configuration](../config/actuators.md) screen in QGroundControl. -After assigning outputs and basic calibration, you may then wish to peform an [ESC Calibration](../advanced_config/esc_calibration.md). +After assigning outputs and basic calibration, you may then wish to perform an [ESC Calibration](../advanced_config/esc_calibration.md). Additional PX4 PWM configuration parameters can be found here: [PWM Outputs](../advanced_config/parameter_reference.md#pwm-outputs). diff --git a/docs/en/peripherals/serial_configuration.md b/docs/en/peripherals/serial_configuration.md index 65650feef51..50dfabe1fc7 100644 --- a/docs/en/peripherals/serial_configuration.md +++ b/docs/en/peripherals/serial_configuration.md @@ -106,7 +106,7 @@ The following ports are commonly mapped to specific functions on all boards: This is configured by default as a MAVLink port the onboard profile (for companion computers). The configuration for MAVLink is unique to this port (it doesn't use the `MAV_X_CONFIG` parameters). - - [SYS_USB_AUTO](../advanced_config/parameter_reference.md#SYS_USB_AUTO) sets whether the port is set to no partiular protocol, autodetects the protocol, or sets the comms link to MAVLink. + - [SYS_USB_AUTO](../advanced_config/parameter_reference.md#SYS_USB_AUTO) sets whether the port is set to no particular protocol, autodetects the protocol, or sets the comms link to MAVLink. - [USB_MAV_MODE](../advanced_config/parameter_reference.md#USB_MAV_MODE) sets the MAVLink profile that is used if MAVLink is set or detected. Other ports generally have no assigned functions by default (are disabled). diff --git a/docs/en/power_module/index.md b/docs/en/power_module/index.md index fe78d1c2236..e982218f5a5 100644 --- a/docs/en/power_module/index.md +++ b/docs/en/power_module/index.md @@ -13,7 +13,7 @@ The PX4 battery/power module configuration (via the ADC interface) is covered in For easiest assembly use a power module or PDB recommended by your FC manufacturer, and sized for your power requirements. The Pixhawk connector standard requires that the VCC line must provide at least 2.5A continuous current and default to 5.3V. -In in practice flight controllers may have different recommendations or preferences, so if you don't (or can't) use a recommended module, check that the module matches your FC's requirements. +In practice flight controllers may have different recommendations or preferences, so if you don't (or can't) use a recommended module, check that the module matches your FC's requirements. ::: This section provides information about a number of power modules and power distribution boards (see FC manufacturer docs for more options): diff --git a/docs/en/releases/1.12.md b/docs/en/releases/1.12.md index 209d36411fa..60b1c0b7ff8 100644 --- a/docs/en/releases/1.12.md +++ b/docs/en/releases/1.12.md @@ -28,7 +28,7 @@ - **RTL Trigger based on remaining flight range ([PR#16399](https://github.com/PX4/PX4-Autopilot/pull/16399))** - Calculates time to home, on RTL, taking into account vehicle speed, wind speed, and destination distance/direction -- **Pre-emptive geofence breach ([PR#16400](https://github.com/PX4/PX4-Autopilot/pull/16400))** +- **Preemptive geofence breach ([PR#16400](https://github.com/PX4/PX4-Autopilot/pull/16400))** - Triggers a breach if the _predicted_ current trajectory will result in a breach, allowing the vehicle to be re-routed to a safe hold position. - **Airframe Scripts** - The syntax for setting defaults was changed and custom scripts require an update diff --git a/docs/en/releases/1.14.md b/docs/en/releases/1.14.md index ad5c81ff56d..85548b2ac88 100644 --- a/docs/en/releases/1.14.md +++ b/docs/en/releases/1.14.md @@ -84,7 +84,7 @@ For users upgrading from previous versions, please take a moment to review the f 1. Fast-RTPS users must port their code to the new uXRCE-DDS interface. Application code should only require minor modifications. These include (minimally): -Modifying topic names to match the new naming pattern, which changed from `fmu//out` to `fmu/out/`, and [Adusting the QoS settings](../ros2/user_guide.md#ros-2-subscriber-qos-settings). +Modifying topic names to match the new naming pattern, which changed from `fmu//out` to `fmu/out/`, and [Adjusting the QoS settings](../ros2/user_guide.md#ros-2-subscriber-qos-settings). For more information see [Fast-RTPS to uXRCE-DDS Migration Guidelines](../middleware/uxrce_dds.md#fast-rtps-to-uxrce-dds-migration-guidelines) @@ -101,7 +101,7 @@ For more information see [Fast-RTPS to uXRCE-DDS Migration Guidelines](../middle - Failsafe state machine rewrite and [web simulation](../config/safety_simulation.md) - Improved preflight failure check reporting (requires QGC [v4.2.0](https://github.com/mavlink/qgroundcontrol/releases/tag/v4.2.0) or later): [PX4-Autopilot#20030](https://github.com/PX4/PX4-Autopilot/pull/20030) and [qgroundcontrol#10362](https://github.com/mavlink/qgroundcontrol/pull/10362) -- [Package delivery in mission](../advanced/package_delivery.md): For package delivery applications, inital support for payload delivery in mission for gripper actuator was added +- [Package delivery in mission](../advanced/package_delivery.md): For package delivery applications, initial support for payload delivery in mission for gripper actuator was added - Manual control setpoint message redefinition: `manual_control_setpoint.x`, `y`, `z`, `w` -> `roll`, `pitch`, `yaw`, `throttle`; `throttle scale [0,1] -> [-1,1]` - [PX4-Autopilot#15949](https://github.com/PX4/PX4-Autopilot/pull/15949) - Default motor PWM configuration - [PX4-Autopilot#21800](https://github.com/PX4/PX4-Autopilot/pull/21800) - Fix PWM/Oneshot calibration - [PX4-Autopilot#21726](https://github.com/PX4/PX4-Autopilot/pull/21726) @@ -134,7 +134,7 @@ For more information see [Fast-RTPS to uXRCE-DDS Migration Guidelines](../middle - [Gazebo-classic] Addition of Omnicopter model: A fully actuated omnidirectional vehicle model has been added to Gazebo SITL - https://github.com/PX4/PX4-SITL_gazebo-classic/pull/866 - [Gazebo-classic] Addition of Advanced liftdrag plugin: Advanced liftdrag plugin that models nonlinear aerodynamics based on AVL - [PX4-SITL_gazebo-classic#901](https://github.com/PX4/PX4-SITL_gazebo-classic/pull/901) - [Gazebo-classic] Addition of Safe landing world: Addition of safe landing world, for testing safe landing - [PX4-SITL_gazebo-classic#93](https://github.com/PX4/PX4-SITL_gazebo-classic/pull/93) -- [Gazebo-classic] Depricated Ubuntu Bionic reated tests: Removed testing due to EOL of Ubuntu Bionic - [PX4-SITL_gazebo-classic#974](https://github.com/PX4/PX4-SITL_gazebo-classic/pull/974) +- [Gazebo-classic] Deprecated Ubuntu Bionic reated tests: Removed testing due to EOL of Ubuntu Bionic - [PX4-SITL_gazebo-classic#974](https://github.com/PX4/PX4-SITL_gazebo-classic/pull/974) - [SIH] Standalone sensor simulations in tree: Ability to simulate sensors in tree that was part of SIH is now a stand alone sensor module. Sensors include magnetometer, GPS, Barometer, Airspeed - [PX4-Autopilot#20137](https://github.com/PX4/PX4-Autopilot/pull/20137), https://github.com/PX4/PX4-Autopilot/tree/main/src/modules/simulation/sensor_airspeed_sim - [SIH] Failure injection for battery simulation - https://github.com/PX4/PX4-Autopilot/commit/ebc1d7544e8146788c9e7cf5e8b64f60199240e4 diff --git a/docs/en/releases/1.15.md b/docs/en/releases/1.15.md index c63d1c708b2..536c6e6a544 100644 --- a/docs/en/releases/1.15.md +++ b/docs/en/releases/1.15.md @@ -79,7 +79,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide). - Correct way of describing the quaternion uncertainty using Lie group theory - Use Joseph stabilized covariance update algorithm for better covariance stability and allow use of "consider states" (inactive states with non-zero variance) ([PX4-Autopilot#22770](https://github.com/PX4/PX4-Autopilot/pull/22770)) - Covariance prediction, measurement jacobians, state struct and covariance index auto-generated using SymForce -- Manual position update throught MAVLink (`MAV_CMD_EXTERNAL_POSITION_ESTIMATE`) +- Manual position update through MAVLink (`MAV_CMD_EXTERNAL_POSITION_ESTIMATE`) - Add Auxiliary Global Position (AGP) fusion (for e.g.: external map matching vision algorithm) **Mag:** diff --git a/docs/en/releases/1.16.md b/docs/en/releases/1.16.md index 5cd1175dd1b..e4aa448dd6c 100644 --- a/docs/en/releases/1.16.md +++ b/docs/en/releases/1.16.md @@ -138,7 +138,7 @@ Please continue reading for [upgrade instructions](#upgrade-guide). - mavlink_ftp: handle relative paths correctly. ([PX4-Autopilot#22980](https://github.com/PX4/PX4-Autopilot/pull/22980)) - Parameter to always start mavlink stream via USB. ([PX4-Autopilot#22234](https://github.com/PX4/PX4-Autopilot/pull/22234)) - Refactor: MAVLink message handling in one function, reference instead of pointer to main instance ([PX4-Autopilo#23219](https://github.com/PX4/PX4-Autopilot/pull/22234)) -- mavlink log handler rewrite for improved effeciency ([PX4-Autopilo#23219](https://github.com/PX4/PX4-Autopilot/pull/22234)) +- mavlink log handler rewrite for improved efficiency ([PX4-Autopilo#23219](https://github.com/PX4/PX4-Autopilot/pull/22234)) ### Multi-Rotor diff --git a/docs/en/robotics/index.md b/docs/en/robotics/index.md index 04f0e1a1137..1f9231736eb 100644 --- a/docs/en/robotics/index.md +++ b/docs/en/robotics/index.md @@ -4,7 +4,7 @@ Drone APIs let you write code to control and integrate with PX4-powered vehicles For example, you might want to create new "smart" flight modes, or custom geofence modes, or integrate new hardware. Drone APIs allow you to do this using high level instructions in your programming language of choice, and the code can then run on-vehicle in a [companion computer](../companion_computer/index.md), or from a ground station. -Under the the hood the APIs communicate with PX4 using [MAVLink](../middleware/mavlink.md) or [uXRCE-DDS](../middleware/uxrce_dds.md). +Under the hood the APIs communicate with PX4 using [MAVLink](../middleware/mavlink.md) or [uXRCE-DDS](../middleware/uxrce_dds.md). PX4 supports the following SDKs/Robotics tools: diff --git a/docs/en/ros/ros1.md b/docs/en/ros/ros1.md index c347933b9a3..507c8275458 100644 --- a/docs/en/ros/ros1.md +++ b/docs/en/ros/ros1.md @@ -21,7 +21,7 @@ This version of ROS uses the [MAVROS](../ros/mavros_installation.md) package to - [ROS Installation on RPi](../ros/raspberrypi_installation.md) - [External Position Estimation (Vision/Motion based)](../ros/external_position_estimation.md) -## Further Infomration +## Further Information - [XTDrone](https://github.com/robin-shaun/XTDrone/blob/master/README.en.md) - ROS + PX4 simulation environment for computer vision. The [XTDrone Manual](https://www.yuque.com/xtdrone/manual_en) has everything you need to get started! diff --git a/docs/en/ros2/index.md b/docs/en/ros2/index.md index 50043ad978d..5767d4a90f4 100644 --- a/docs/en/ros2/index.md +++ b/docs/en/ros2/index.md @@ -35,9 +35,9 @@ The main topics in this section are: - [ROS 2 User Guide](../ros2/user_guide.md): A PX4-centric overview of ROS 2, covering installation, setup, and how to build ROS 2 applications that communicate with PX4. - [ROS 2 Offboard Control Example](../ros2/offboard_control.md): A C++ tutorial examples showing how to do position control in [offboard mode](../flight_modes/offboard.md) from a ROS 2 node. - [ROS 2 Multi Vehicle Simulation](../ros2/multi_vehicle.md): Instructions for connecting to multipole PX4 simulations via single ROS 2 agent. -- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md): A C++ library that simplies interacting with PX4 from ROS 2. - Can be used to create and register flight modes wrtten using ROS2 and send position estimates from ROS2 applications such as a VIO system. -- [ROS 2 Message Translation Node](../ros2/px4_ros2_msg_translation_node.md): A ROS 2 message translation node that enables communcation between PX4 and ROS 2 applications that were compiled with different sets of messages versions. +- [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md): A C++ library that simplifies interacting with PX4 from ROS 2. + Can be used to create and register flight modes written using ROS2 and send position estimates from ROS2 applications such as a VIO system. +- [ROS 2 Message Translation Node](../ros2/px4_ros2_msg_translation_node.md): A ROS 2 message translation node that enables communication between PX4 and ROS 2 applications that were compiled with different sets of messages versions. ## Further Information diff --git a/docs/en/ros2/offboard_control.md b/docs/en/ros2/offboard_control.md index f16256cd4d5..e288092f963 100644 --- a/docs/en/ros2/offboard_control.md +++ b/docs/en/ros2/offboard_control.md @@ -140,7 +140,7 @@ The setpoints are still sent in every cycle so that the vehicle does not fall ou The implementations of the `publish_offboard_control_mode()` and `publish_trajectory_setpoint()` methods are shown below. These publish the [OffboardControlMode](../msg_docs/OffboardControlMode.md) and [TrajectorySetpoint](../msg_docs/TrajectorySetpoint.md) messages to PX4 (respectively). -The `OffboardControlMode` is required in order to inform PX4 of the _type_ of offboard control behing used. +The `OffboardControlMode` is required in order to inform PX4 of the _type_ of offboard control being used. Here we're only using _position control_, so the `position` field is set to `true` and all the other fields are set to `false`. ```cpp diff --git a/docs/en/ros2/px4_ros2_msg_translation_node.md b/docs/en/ros2/px4_ros2_msg_translation_node.md index 5587c4fdbb1..527e75c8265 100644 --- a/docs/en/ros2/px4_ros2_msg_translation_node.md +++ b/docs/en/ros2/px4_ros2_msg_translation_node.md @@ -105,7 +105,7 @@ For example, the following implements a minimal subscriber and publisher node th #include // Template function to get the message version suffix -// The correct message version is directly inferred from the message defintion +// The correct message version is directly inferred from the message definition template std::string getMessageNameVersion() { if (T::MESSAGE_VERSION == 0) return ""; diff --git a/docs/en/ros2/user_guide.md b/docs/en/ros2/user_guide.md index a06c6d05c58..36ac3c15608 100644 --- a/docs/en/ros2/user_guide.md +++ b/docs/en/ros2/user_guide.md @@ -134,7 +134,7 @@ To install ROS 2 and its dependencies: 1. Some Python dependencies must also be installed (using **`pip`** or **`apt`**): ```sh - pip install --user -U empy==3.3.4 pyros-genmsg setuptools + pip install --user -U empty==3.3.4 pyros-genmsg setuptools ``` ### Setup Micro XRCE-DDS Agent & Client diff --git a/docs/en/sensor/thunderfly_tachometer.md b/docs/en/sensor/thunderfly_tachometer.md index 96f7763ac65..b4f7c0bb711 100644 --- a/docs/en/sensor/thunderfly_tachometer.md +++ b/docs/en/sensor/thunderfly_tachometer.md @@ -90,7 +90,7 @@ pcf8583 status ``` If the driver is running, the I²C port will be printed along with other basic parameters of the running instance. -If the driver is not running it can be started started using theprocedure described above. +If the driver is not running it can be started using theprocedure described above. The [listener](../modules/modules_command.md#listener) command allows you to monitor RPM UORB messages from the running driver. diff --git a/docs/en/sim_gazebo_gz/index.md b/docs/en/sim_gazebo_gz/index.md index 4f6686acfc4..100b6e8f06a 100644 --- a/docs/en/sim_gazebo_gz/index.md +++ b/docs/en/sim_gazebo_gz/index.md @@ -301,7 +301,7 @@ where `ARGS` is a list of environment variables including: - `PX4_GZ_FOLLOW_OFFSET_X`, `PX4_GZ_FOLLOW_OFFSET_Y`, `PX4_GZ_FOLLOW_OFFSET_Z`: Set the relative offset of the follow camera to the vehicle. -The PX4 Gazebo worlds and and models databases [can be found on GitHub here](https://github.com/PX4/PX4-gazebo-models). +The PX4 Gazebo worlds and models databases [can be found on GitHub here](https://github.com/PX4/PX4-gazebo-models). ::: info `gz_env.sh.in` is compiled and made available in `$PX4_DIR/build/px4_sitl_default/rootfs/gz_env.sh` diff --git a/docs/en/sim_gazebo_gz/tools_avl_automation.md b/docs/en/sim_gazebo_gz/tools_avl_automation.md index 68ecaade047..a1a884cfe04 100644 --- a/docs/en/sim_gazebo_gz/tools_avl_automation.md +++ b/docs/en/sim_gazebo_gz/tools_avl_automation.md @@ -118,7 +118,7 @@ From the stability derivatives log file, the following advanced lift drag plugin | CYa | CYa | dCy/da (sideforce slope wrt alpha) | | Cla | Cell | dCl/da (roll moment slope wrt alpha) | | Cma | Cema | dCm/da (pitching moment slope wrt aLpha - before stall) | -| Cna | Cena | dCn/da (yaw moment slope wrt alpha) | +| Can | Cena | dCn/da (yaw moment slope wrt alpha) | | CLb | CLb | dCL/dbeta (lift coefficient slope wrt beta) | | CYb | CYb | dCY/dbeta (side force slope wrt beta) | | Clb | Cell | dCl/dbeta (roll moment slope wrt beta) | diff --git a/docs/en/sim_gazebo_gz/vehicles.md b/docs/en/sim_gazebo_gz/vehicles.md index 10f377d4653..04d5253eded 100644 --- a/docs/en/sim_gazebo_gz/vehicles.md +++ b/docs/en/sim_gazebo_gz/vehicles.md @@ -8,7 +8,7 @@ Supported vehicle types include: mutirotor, VTOL, Plane, Rover. :::warning See [Gazebo Classic Vehicles](../sim_gazebo_classic/vehicles.md) for vehicles that work with the older [Gazebo "Classic" simulation](../sim_gazebo_classic/index.md). -Note that vehicle models are not interchangable between the two versions of the simulator: the vehicles on this page only work with (new) [Gazebo](../sim_gazebo_gz/index.md). +Note that vehicle models are not interchangeable between the two versions of the simulator: the vehicles on this page only work with (new) [Gazebo](../sim_gazebo_gz/index.md). ::: ## Multicopter diff --git a/docs/en/sim_gazebo_gz/worlds.md b/docs/en/sim_gazebo_gz/worlds.md index 8d10d507549..32f047db393 100644 --- a/docs/en/sim_gazebo_gz/worlds.md +++ b/docs/en/sim_gazebo_gz/worlds.md @@ -104,4 +104,4 @@ The PX4 toolchain will automatically spawn a world that has the same name as the The model specific worlds are: -- [Aruco world](#aruco): Default world with an [ArUco marker](https://docs.opencv.org/4.x/d5/dae/tutorial_aruco_detection.html) that can be used with with [x500_mono_cam_down](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-monocular-camera-down-facing) for testing [precision landing](../advanced_features/precland.md). +- [Aruco world](#aruco): Default world with an [ArUco marker](https://docs.opencv.org/4.x/d5/dae/tutorial_aruco_detection.html) that can be used with [x500_mono_cam_down](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-monocular-camera-down-facing) for testing [precision landing](../advanced_features/precland.md). diff --git a/docs/en/sim_jmavsim/index.md b/docs/en/sim_jmavsim/index.md index f8e25ef6078..ae3267ccd14 100644 --- a/docs/en/sim_jmavsim/index.md +++ b/docs/en/sim_jmavsim/index.md @@ -307,7 +307,7 @@ sudo gedit /etc/java-8-openjdk/accessibility.properties and comment out the line indicated below: ```sh -#assistive_technologies=org.GNOME.Acessibility.AtkWrapper +#assistive_technologies=org.GNOME.Accessibility.AtkWrapper ``` For more info, check [this GitHub issue](https://github.com/PX4/PX4-Autopilot/issues/9557). diff --git a/docs/en/sim_sih/index.md b/docs/en/sim_sih/index.md index 07312cca953..36fba12d223 100644 --- a/docs/en/sim_sih/index.md +++ b/docs/en/sim_sih/index.md @@ -114,7 +114,7 @@ CONFIG_MODULES_SIMULATION_SENSOR_MAG_SIM=y ::: -As an alterative to updating configuration files manually, you can use the following command to launch a GUI configuration tool, and interactively enable the required modules at the path: **modules > Simulation > simulator_sih**. +As an alternative to updating configuration files manually, you can use the following command to launch a GUI configuration tool, and interactively enable the required modules at the path: **modules > Simulation > simulator_sih**. For example, to update the fmu-v6x configuration you would use: ```sh diff --git a/docs/en/smart_batteries/index.md b/docs/en/smart_batteries/index.md index 805ad60619b..45d726e1ef0 100644 --- a/docs/en/smart_batteries/index.md +++ b/docs/en/smart_batteries/index.md @@ -1,7 +1,7 @@ # Smart Batteries Smart Batteries provide more accurate (and often more detailed) information about the state of a battery than an autopilot can estimate for "dumb" batteries. -This allows for more more reliable flight planning notification of failure conditions. +This allows for more reliable flight planning notification of failure conditions. The information may include some of: remaining charge, time-to-empty (estimated), cell voltages (rated max/min, current voltage, etc.), temperature, currents, fault information, battery vendor, chemistry, etc. PX4 supports (at least) following smart batteries: diff --git a/docs/en/telemetry/jfi_telemetry.md b/docs/en/telemetry/jfi_telemetry.md index a6e70733796..67e9484ce43 100644 --- a/docs/en/telemetry/jfi_telemetry.md +++ b/docs/en/telemetry/jfi_telemetry.md @@ -94,7 +94,7 @@ If you want to change the baud rate: ### 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). +All J.Fi devices should be set to the same baud rate (although communication may work even 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)). diff --git a/docs/en/test_and_ci/test_flights.md b/docs/en/test_and_ci/test_flights.md index a120578703d..d23f42988fb 100644 --- a/docs/en/test_and_ci/test_flights.md +++ b/docs/en/test_and_ci/test_flights.md @@ -7,7 +7,7 @@ const { site } = useData();
-

This page may be out out of date. See the latest version.

+

This page may be out of date. See the latest version.

diff --git a/docs/en/test_cards/mc_02_full_autonomous.md b/docs/en/test_cards/mc_02_full_autonomous.md index e3d015fbf2e..e040ed0b7a4 100644 --- a/docs/en/test_cards/mc_02_full_autonomous.md +++ b/docs/en/test_cards/mc_02_full_autonomous.md @@ -54,7 +54,7 @@ Plan a mission on the ground. Ensure the mission has - Take-off should be smooth as throttle is raised - Mission should upload on first attempt - Vehicle should automatically take-off upon engaging Auto -- Vehicle shoud adjust height to RTL altitude before returning home +- Vehicle should adjust height to RTL altitude before returning home - Upon landing, copter should not bounce on the ground