mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-10-25 03:13:34 +08:00
Move PX4 Guide source into /docs (#24490)
* Add vitepress tree * Update existing workflows so they dont trigger on changes in the docs path * Add nojekyll, package.json, LICENCE etc * Add crowdin docs upload/download scripts * Add docs flaw checker workflows * Used docs prefix for docs workflows * Crowdin obvious fixes * ci: docs move to self hosted runner runs on a beefy server for faster builds Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci: don't run build action for docs or ci changes Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci: update runners Signed-off-by: Ramon Roche <mrpollo@gmail.com> * Add docs/en * Add docs assets and scripts * Fix up editlinks to point to PX4 sources * Download just the translations that are supported * Add translation sources for zh, uk, ko * Update latest tranlsation and uorb graphs * update vitepress to latest --------- Signed-off-by: Ramon Roche <mrpollo@gmail.com> Co-authored-by: Ramon Roche <mrpollo@gmail.com>
This commit is contained in:
Hamish Willee
co-authored by
Ramon Roche
Ramon Roche
parent
8e6d2ebe4a
commit
88d623bedb
@@ -0,0 +1 @@
|
||||
<Redirect to="../flying/basic_flying_mc" />
|
||||
@@ -0,0 +1,113 @@
|
||||
# Basic Flying (Fixed Wing)
|
||||
|
||||
This topic explains the basics of flying a vehicle using an [RC Transmitter](../getting_started/rc_transmitter_receiver.md) in a manual or autopilot-assisted flight mode (for autonomous flight see: [Missions](../flying/missions.md)).
|
||||
|
||||
::: info
|
||||
Before you fly for the first time you should read our [First Flight Guidelines](../flying/first_flight_guidelines.md).
|
||||
:::
|
||||
|
||||
## Arm the Vehicle
|
||||
|
||||
Before you can fly the vehicle it must first be [armed](../getting_started/px4_basic_concepts.md#arming-and-disarming).
|
||||
This will power all motors and actuators, and may start propellers turning.
|
||||
|
||||
To arm the drone:
|
||||
|
||||
- First disengage the [safety switch](../getting_started/px4_basic_concepts.md#safety-switch) (if present).
|
||||
- Use the arm command for your vehicle
|
||||
- Put the throttle stick in the bottom right corner (use the [arming gesture](../advanced_config/prearm_arm_disarm.md#arm_disarm_gestures)).
|
||||
- Alternatively configure an [arm/disarm switch](../config/safety.md#arm-disarm-switch).
|
||||
- You can also arm in _QGroundControl_ (PX4 does not require a radio control for flying autonomously).
|
||||
|
||||
:::tip
|
||||
The vehicle will not arm until it is [calibrated/configured](../config/index.md) and has a position lock.
|
||||
[Vehicle Status Notifications](../getting_started/vehicle_status.md) (including on-vehicle LEDs, audio notifications and _QGroundControl_ updates) can tell you when the vehicle is ready to fly (and help you work out the cause when it is not ready to fly).
|
||||
:::
|
||||
|
||||
::: info
|
||||
The vehicle will (by [default](../advanced_config/parameter_reference.md#COM_DISARM_PRFLT)) automatically [disarm](../advanced_config/prearm_arm_disarm.md#auto-disarming) (turn off motors) if you take too long to take off!
|
||||
This is a safety measure to ensure that vehicles return to a safe state when not in use.
|
||||
:::
|
||||
|
||||
<!--
|
||||
A VTOL vehicle can only arm in multicopter mode (by default - arming in fixed-wing mode can be enabled using [CBRK_VTOLARMING](../advanced_config/parameter_reference.md#CBRK_VTOLARMING)).
|
||||
-->
|
||||
|
||||
## Takeoff
|
||||
|
||||
::: info
|
||||
Taking off manually (and landing) is not easy!
|
||||
We recommend using with the automatic modes instead, especially for inexperienced pilots.
|
||||
:::
|
||||
|
||||
[Stabilized mode](../flight_modes_fw/stabilized.md), [Acro mode](../flight_modes_fw/acro.md) or [Manual mode](../flight_modes_fw/manual.md) mode are recommended for manual takeoff.
|
||||
[Position mode](../flight_modes_fw/position.md) and [Altitude mode](../flight_modes_fw/altitude.md) can also be used, but it is important to accelerate the vehicle sufficiently before bringing them airborne — strong thrust if hand-launched, long runway phase for runway takeoff (this is required because the controller in these modes can prioritize airspeed over altitude tracking).
|
||||
|
||||
Manual takeoffs with hand-launched planes:
|
||||
|
||||
- Ramp up the motor and throw the vehicle horizontally.
|
||||
- Do not pitch up too fast as this may stall the plane.
|
||||
- A good vehicle trim is crucial for safe hand-launch takeoffs, because if the vehicle doesn't fly level there is only a very short time for the pilot to react before the vehicle crashes!
|
||||
|
||||
Manual takeoffs with runway-launched planes:
|
||||
|
||||
- Accelerate on the runway until the speed is sufficient for takeoff.
|
||||
- If the plane has a steerable wheel, use the yaw stick to keep it on course.
|
||||
- Once the speed is sufficient pull up the nose with the pitch stick.
|
||||
|
||||
Automatic takeoffs are possible in the [Mission mode](../flight_modes_fw/mission.md#mission-takeoff) or [Takeoff mode (FW)](../flight_modes_fw/takeoff.md).
|
||||
The pilot can take over manual control over the vehicle at any moment during the takeoff process or after it by changing into a manual flight mode.
|
||||
|
||||
## Landing
|
||||
|
||||
[Stabilized mode](../flight_modes_fw/stabilized.md), [Acro mode](../flight_modes_fw/acro.md) or [Manual mode](../flight_modes_fw/manual.md) are recommended for landing (just as they are for takeoff).
|
||||
In these modes the pilot has full control over the motor thrust, which is required to perform a manual flaring maneuver when close to the ground (raising the vehicle nose without increasing throttle).
|
||||
You should perform the landing in headwind to reduce the groundspeed before touching down.
|
||||
|
||||
For auto landings you should use a [Fixed-Wing Mission Landing](../flight_modes_fw/mission.md#mission-landing).
|
||||
This landing is defined in a mission, and can be used in either [Mission](../flight_modes_fw/mission.md) or [Return](../flight_modes_fw/return.md) modes.
|
||||
|
||||
The automatic [Land mode](../flight_modes_fw/land.md) mode is not recommended unless absolutely necessary, as it cannot account for underlying terrain.
|
||||
|
||||
<!-- Added this to make it more generic: We'll split this out later -->
|
||||
|
||||
Note that vehicles automatically disarm on landing by default:
|
||||
|
||||
- Use [COM_DISARM_LAND](../advanced_config/parameter_reference.md#COM_DISARM_LAND) to set the time to auto-disarm after landing (or disable it altogether).
|
||||
- Manually disarm by putting the throttle stick in the bottom left corner.
|
||||
|
||||
## Flight Controls/Commands
|
||||
|
||||
All flying, including takeoff and landing, is controlled using the 4 basic commands: roll, yaw, pitch and throttle.
|
||||
|
||||
|
||||
|
||||
In order to control your aircraft you need to understand how the basic Roll, Pitch, Yaw and Throttle commands affect movement in 3D space.
|
||||
Forward-flying aircraft (planes, VTOL in forward flight) respond to the movement commands as shown below:
|
||||
|
||||
|
||||
|
||||
- Pitch => Up/down.
|
||||
- Roll => Left/right and a turn.
|
||||
- Yaw => Left/right tail rotation and turn.
|
||||
- Throttle => Changed forward speed.
|
||||
|
||||
::: info
|
||||
The best turn for airplanes is called a coordinated turn, and is performed using roll and little yaw at the same time.
|
||||
This maneuver requires experience!
|
||||
:::
|
||||
|
||||
## Assisted Flight
|
||||
|
||||
Even with an understanding of how the vehicle is controlled, flight in fully manual mode can be quite unforgiving.
|
||||
New users should [configure their transmitter](../config/flight_mode.md) to use flight modes where the autopilot automatically compensates for erratic user input or environmental factors.
|
||||
|
||||
The following three modes are highly recommended for new users:
|
||||
|
||||
- [Stabilized Mode](../flight_modes_fw/stabilized.md) - Vehicle hard to flip, and will level-out if the sticks are released (but not hold position)
|
||||
- [Altitude Mode)](../flight_modes_fw/altitude.md) - Climb and drop are controlled to have a maximum rate.
|
||||
- [Position Mode](../flight_modes_fw/position.md) - When sticks are released the vehicle will stop (and hold position against wind drift)
|
||||
|
||||
::: info
|
||||
You can also engage automatic modes through the _QGroundControl_ main flight screen.
|
||||
:::
|
||||
@@ -0,0 +1,100 @@
|
||||
# Basic Flying (Multicopter)
|
||||
|
||||
This topic explains the basics of flying a vehicle using an [RC Transmitter](../getting_started/rc_transmitter_receiver.md) or [Joystick](../config/joystick.md) in a manual or autopilot-assisted flight mode (for autonomous flight see: [Missions](../flying/missions.md)).
|
||||
|
||||
::: info
|
||||
Before you fly for the first time you should read our [First Flight Guidelines](../flying/first_flight_guidelines.md).
|
||||
:::
|
||||
|
||||
## Arm the Vehicle
|
||||
|
||||
Before you can fly the vehicle it must first be [armed](../getting_started/px4_basic_concepts.md#arming-and-disarming).
|
||||
This will power all motors and actuators.
|
||||
Unless you're doing a [Throw Launch](../flight_modes_mc/throw_launch.md) the propellers will also start turning.
|
||||
|
||||
To arm the drone:
|
||||
|
||||
- First disengage the [safety switch](../getting_started/px4_basic_concepts.md#safety-switch) (if present).
|
||||
- Use the arm command for your vehicle:
|
||||
- Put the throttle stick in the bottom right corner (use the [arming gesture](../advanced_config/prearm_arm_disarm.md#arm_disarm_gestures)).
|
||||
- Alternatively configure an [arm/disarm switch](../config/safety.md#arm-disarm-switch).
|
||||
- You can also arm in _QGroundControl_ (PX4 does not require a radio control for flying autonomously).
|
||||
|
||||
:::tip
|
||||
The vehicle will not arm until it is [calibrated/configured](../config/index.md) and has a position lock.
|
||||
[Vehicle Status Notifications](../getting_started/vehicle_status.md) (including on-vehicle LEDs, audio notifications and _QGroundControl_ updates) can tell you when the vehicle is ready to fly (and help you work out the cause when it is not ready to fly).
|
||||
:::
|
||||
|
||||
::: info
|
||||
The vehicle will (by [default](../advanced_config/parameter_reference.md#COM_DISARM_PRFLT)) automatically [disarm](../advanced_config/prearm_arm_disarm.md#auto-disarming) (turn off motors) if you take too long to take off!
|
||||
This is a safety measure to ensure that vehicles return to a safe state when not in use.
|
||||
:::
|
||||
|
||||
<!--
|
||||
A VTOL vehicle can only arm in multicopter mode (by default - arming in fixed-wing mode can be enabled using [CBRK_VTOLARMING](../advanced_config/parameter_reference.md#CBRK_VTOLARMING)).
|
||||
-->
|
||||
|
||||
## Takeoff
|
||||
|
||||
Multicopter pilots can take off _manually_ by enabling any manual mode, arming the vehicle and then raising the throttle stick until the motors produce enough thrust to leave the ground.
|
||||
In [Position mode](../flight_modes_mc/position.md) or [Altitude mode](../flight_modes_mc/altitude.md) the throttle stick has to be increased to above 62.5% to command a climb rate and make the vehicle leave the ground.
|
||||
Above this value all controllers are enabled and the vehicle goes to the throttle level required for hovering ([MPC_THR_HOVER](../advanced_config/parameter_reference.md#MPC_THR_HOVER)).
|
||||
|
||||
[Throw Launch](../flight_modes_mc/throw_launch.md) is also supported, in which the vehicle activates motors after it detects that it has reached the apex of a throw, and then operates according to its current mode.
|
||||
|
||||
Alternatively the takeoff can performed by switching to the automatic [Takeoff mode](../flight_modes_mc/takeoff.md).
|
||||
|
||||
::: info
|
||||
The vehicle may disarm if you take too long to take off after arming (tune the timeout using [COM_DISARM_PRFLT](../advanced_config/parameter_reference.md#COM_DISARM_PRFLT)).
|
||||
:::
|
||||
|
||||
::: info
|
||||
The [Failure Detector](../config/safety.md#failure-detector) will automatically stop the engines if there is a problem on takeoff.
|
||||
:::
|
||||
|
||||
## Landing
|
||||
|
||||
Multicopters can be landed in any manual mode.
|
||||
Make sure to keep the throttle stick pulled down after touching down until the motors have switched off.
|
||||
|
||||
Note that vehicles automatically disarm on landing by default:
|
||||
|
||||
- Use [COM_DISARM_LAND](../advanced_config/parameter_reference.md#COM_DISARM_LAND) to set the time to auto-disarm after landing (or disable it altogether).
|
||||
- Manually disarm by putting the throttle stick in the bottom left corner.
|
||||
|
||||
The vehicle can also be landed autonomously by engaging [Land mode](../flight_modes_mc/land.md) or [Return mode](../flight_modes_mc/return.md).
|
||||
|
||||
::: info
|
||||
If you see the vehicle "twitch" during landing (turn down the motors, and then immediately turn them back up) this is probably caused by a poor [Land Detector Configuration](../advanced_config/land_detector.md) (specifically, a poorly set [MPC_THR_HOVER](../advanced_config/parameter_reference.md#MPC_THR_HOVER)).
|
||||
:::
|
||||
|
||||
## 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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Assisted Flight
|
||||
|
||||
Even with an understanding of how the vehicle is controlled, flight in fully manual mode can be quite unforgiving.
|
||||
New users should [configure their transmitter](../config/flight_mode.md) to use flight modes where the autopilot automatically compensates for erratic user input or environmental factors.
|
||||
|
||||
The following three modes are highly recommended for new users:
|
||||
|
||||
- [Position mode](../flight_modes_mc/position.md) - When sticks are released the vehicle will stop (and hold position against wind drift)
|
||||
- [Altitude mode](../flight_modes_mc/altitude.md) - Climb and drop are controlled to have a maximum rate.
|
||||
- [Stabilized mode](../flight_modes_mc/manual_stabilized.md) - Vehicle hard to flip, and will level-out if the sticks are released (but not hold position)
|
||||
|
||||
::: info
|
||||
You can also engage automatic modes on the _QGroundControl_ main flight screen.
|
||||
:::
|
||||
|
||||
## See Also
|
||||
|
||||
- [Terrain Follow/Hold & Range Assistance](../flying/terrain_following_holding.md) — How to enable terrain following
|
||||
- [Missions](../flying/missions.md)
|
||||
@@ -0,0 +1,45 @@
|
||||
# First Flight Guidelines
|
||||
|
||||
Learning to fly is a lot of fun!
|
||||
These guidelines are designed to ensure that your first flight experience is enjoyable, educational, and safe.
|
||||
|
||||
## Know the Law
|
||||
|
||||
Many places have strict regulations related to using flying drones, including requiring a license when flying vehicles or a particular size/weight, or for a particular purpose.
|
||||
Familiarise yourself with the flight regulations in your area.
|
||||
|
||||
## Select a Good Location
|
||||
|
||||
Selecting the right location for your first flight is critical.
|
||||
The main things to look for are:
|
||||
|
||||
- Make sure the space is open.
|
||||
There should be no high trees, hills or buildings nearby, because those will impair the GNSS reception.
|
||||
- Make sure no people are within 100 m (300 feet).
|
||||
- Make sure there is nothing that you shouldn't crash onto within 100 m - no houses, structures, cars, water, corn fields (hard to find drones in).
|
||||
|
||||
::: info
|
||||
100m clearance is a good "rule of thumb", but in many cases there will be an appropriate regulartory distance, and this may depend on factors such as whether you have a license.
|
||||
:::
|
||||
|
||||
## Bring a Pro
|
||||
|
||||
Bring someone with experience for your first flight.
|
||||
Get them to help you to run through the pre-flight checks and let them intervene if something goes wrong!
|
||||
|
||||
## Plan the Flight
|
||||
|
||||
Plan the flight before taking off.
|
||||
Make sure you know the whole route and where/how the vehicle will land.
|
||||
|
||||
## Limit the Damage
|
||||
|
||||
Damaging property or injuring people with your UAV can have significant legal and financial consequences (far in excess of the value of the UAV itself).
|
||||
|
||||
The UAV should always be manually flown within a safe zone where there are no obstacles or people, and it must be clearly visible at all times.
|
||||
|
||||
If you start to lose control over the vehicle, and cannot bring it back under control, crash it in an empty area as soon as possible.
|
||||
|
||||
::: info
|
||||
It can be useful to [set an emergency switch on your transmitter](../config/safety.md#emergency-switches) to immediately return or crash the drone if necessary.
|
||||
:::
|
||||
@@ -0,0 +1,59 @@
|
||||
# Geofence
|
||||
|
||||
A Geofence is a virtual boundary that defines where a vehicle can travel.
|
||||
GeoFences can be used to prevent a vehicle flying out of range of the RC controller, or into unsafe or restricted airspace.
|
||||
|
||||
PX4 provides two independent mechanisms for specify a geofence:
|
||||
|
||||
- A basic "failsafe" geofence that defines a simple cylinder.
|
||||
- More complicated geometries can be defined using a Geofence Plan (_QGroundControl_).
|
||||
|
||||
::: info
|
||||
GeoFences apply in all modes, including both missions and manual flight.
|
||||
:::
|
||||
|
||||
## Failsafe Geofence
|
||||
|
||||
The [Geofence Failsafe](../config/safety.md#geofence-failsafe) defines a cylinder centered on the home position, with a specified maximum radius and altitude.
|
||||
|
||||
The settings also include a "failsafe action" in the event that the fence is breached.
|
||||
This may simply be a warning notification, but more commonly a vehicle will immediately [Return](../flight_modes/return.md) to a safe location.
|
||||
|
||||
For more information see: [Safety > Geofence Failsafe](../config/safety.md#geofence-failsafe).
|
||||
|
||||
## Geofence Plan
|
||||
|
||||
PX4 supports complex Geofence boundaries made up of multiple circular and polygonal regions, which may be defined as either inclusion (fly within) or exclusion (fly outside) areas.
|
||||
|
||||
The Geofence is planned in _QGroundControl_ alongside the mission and rally points.
|
||||
|
||||
|
||||
|
||||
Geofence planning is fully documented in [Plan View > GeoFence](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/plan_view/plan_geofence.html) (QGroundControl User Guide).
|
||||
|
||||
In summary:
|
||||
|
||||
1. Open _QGroundControl > Plan View_.
|
||||
1. Select the _Plan Type_ radio button: **Fence**.
|
||||
This will display the _GeoFence Editor_.
|
||||
|
||||
1. Select the **Polygon Fence** or **Circular Fence** button to add a _basic_ fence of the desired type to the map.
|
||||
This also adds an entry for the type of fence in the editor.
|
||||
1. Use the map to configure the shape and position of the fence.
|
||||
- The fence center marker can be used to move the fence to the correct position.
|
||||
- The marker on the border of a circular fence can be used to change the radius.
|
||||
- The markers on corners (vertices) can be used to change the geometry of a polygon.
|
||||
Additional vertices are created by clicking halfway along the lines between existing markers.
|
||||
1. Use the _Geofence Editor_ to set a fence as an inclusion or exclusion, and to select a fence to edit (**Edit** radio button) or Delete (**Del** button).
|
||||
1. Add as many fences as you like.
|
||||
1. Once finished, click on the **Upload** button (top right) to send the fence (along with rally points and mission) to the vehicle.
|
||||
1. Set the breach action in the [Geofence Failsafe](../config/safety.md#geofence-failsafe).
|
||||
|
||||
::: info
|
||||
Any geofence that does not include the Home position will be rejected by the flight controller and not uploaded.
|
||||
If the vehicle is flying, also any geofence that would immediately get breached after the upload is rejected.
|
||||
:::
|
||||
|
||||
::: info
|
||||
PX4 implements the MAVLink [Mission microservice](https://mavlink.io/en/services/mission.html), which includes support for GeoFences.
|
||||
:::
|
||||
@@ -0,0 +1,12 @@
|
||||
# Flying
|
||||
|
||||
Before flying you should ensure that your vehicle is calibrated and configured, and that you have followed the instructions in the [Safety](../config/safety.md) section.
|
||||
In particular, you should set appropriate [Safety Failsafes](../config/safety.md) and a [Geofence](../flying/geofence.md).
|
||||
You should also read the [First Flight Guidelines](../flying/first_flight_guidelines.md).
|
||||
|
||||
Basic instructions for flying are covered in the vehicle-specfic topics:
|
||||
|
||||
- [Multicopter](../flying/basic_flying_mc.md)
|
||||
- [Fixed-wing](../flying/basic_flying_fw.md)
|
||||
|
||||
How to fly an autonomous mission is covered in [Missions](../flying/missions.md).
|
||||
@@ -0,0 +1,80 @@
|
||||
# Missions
|
||||
|
||||
A mission is a predefined flight plan, which can be planned in QGroundControl and uploaded to the flight controller, and then executed autonomously in [Mission mode](../flight_modes_mc/mission.md).
|
||||
|
||||
Missions typically include items for controlling taking off, flying a sequence of waypoints, capturing images and/or video, deploying cargo, and landing.
|
||||
QGroundControl allows you to plan missions using a fully manual approach, or you can use its more advanced features to plan ground area surveys, corridor surveys, or structure surveys.
|
||||
|
||||
This topic provides an overview of how to plan and fly missions.
|
||||
|
||||
|
||||
|
||||
## Planning Missions
|
||||
|
||||
Manually planning missions is straightforward:
|
||||
|
||||
- Switch to the mission view
|
||||
- Select the **Add Waypoint** ("plus") icon in the top left.
|
||||
- Click on the map to add waypoints.
|
||||
- Use the waypoint list on the right to modify the waypoint parameters/type
|
||||
The altitude indicator on the bottom provides a sense of the relative altitude of each waypoint.
|
||||
- Once finished, click on the **Upload** button (top right) to send the mission to the vehicle.
|
||||
|
||||
You can also use the _Pattern_ tool to automate creation of survey grids.
|
||||
|
||||
:::tip
|
||||
For more information see the [QGroundControl User Guide](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/plan_view/plan_view.html).
|
||||
:::
|
||||
|
||||
|
||||
|
||||
### Mission Feasibility Checks
|
||||
|
||||
PX4 runs some basic sanity checks to determine if a mission is feasible.
|
||||
For example, whether the mission is close enough to the vehicle, if the mission will conflict with a geofence, or if a mission landing pattern is required but is not present.
|
||||
|
||||
The checks are run when the mission is uploaded and immediately before it is run.
|
||||
If any of the checks fail, the user is notified and it is not possible to start the mission.
|
||||
|
||||
For more detail on the checks and possible actions, see: [Mission Mode (FW) > Mission Feasibility Checks](../flight_modes_fw/mission.md#mission-feasibility-checks) and [Mission Mode (MC) > Mission Feasibility Checks](../flight_modes_mc/mission.md#mission-feasibility-checks).
|
||||
|
||||
### Setting Vehicle Yaw
|
||||
|
||||
If set, a multi-rotor vehicle will yaw to face the **Heading** value specified in the target waypoint (corresponding to [MAV_CMD_NAV_WAYPOINT.param4](https://mavlink.io/en/messages/common.html#MAV_CMD_NAV_WAYPOINT)).
|
||||
|
||||
If **Heading** has not been explicitly set for the target waypoint (`param4=NaN`) then the vehicle will yaw towards a location specified in the parameter [MPC_YAW_MODE](../advanced_config/parameter_reference.md#MPC_YAW_MODE).
|
||||
By default this is the next waypoint.
|
||||
|
||||
Vehicle types that cannot independently control yaw and direction of travel will ignore yaw settings (e.g. Fixed-wing).
|
||||
|
||||
### Setting Acceptance/Turning Radius
|
||||
|
||||
The _acceptance radius_ defines the circle around a waypoint within which a vehicle considers it has reached the waypoint, and will immediately switch to (and start turning towards) the next waypoint.
|
||||
|
||||
For a multi-rotor drones, the acceptance radius is tuned using the parameter [NAV_ACC_RAD](../advanced_config/parameter_reference.md#NAV_ACC_RAD).
|
||||
By default, the radius is small to ensure that multirotors pass above the waypoints, but it can be increased to create a smoother path such that the drone starts to turn before reaching the waypoint.
|
||||
|
||||
The image below shows the same mission flown with different acceptance radius parameters:
|
||||
|
||||
|
||||
|
||||
The speed in the turn is automatically computed based on the acceptance radius (= turning radius) and the maximum allowed acceleration and jerk (see [Jerk-limited Type Trajectory for Multicopters](../config_mc/mc_jerk_limited_type_trajectory.md#auto-mode)).
|
||||
|
||||
:::tip
|
||||
For more information about the impact of the acceptance radius around the waypoint see: [Mission Mode > Inter-waypoint Trajectory](../flight_modes_fw/mission.md#rounded-turns-inter-waypoint-trajectory).
|
||||
:::
|
||||
|
||||
### Package Delivery (Cargo) Missions
|
||||
|
||||
PX4 supports cargo delivery in missions using a gripper.
|
||||
|
||||
This kind of mission is planned in much the same as any other [waypoint mission](../flying/missions.md), with mission start, takeoff waypoint, various path waypoints, and possibly a return waypoint.
|
||||
The only difference is that a package delivery mission must include a mission items to indicate how the package is released and the deployment mechanism.
|
||||
For more information see: [Package Delivery Mission](../flying/package_delivery_mission.md).
|
||||
|
||||
## Flying Missions
|
||||
|
||||
Once the mission is uploaded, switch to the flight view.
|
||||
The mission is displayed in a way that makes it easy to track progress (it cannot be modified in this view).
|
||||
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
# Package Delivery Missions
|
||||
|
||||
A package delivery mission allows users to plan and execute cargo delivery using a [gripper](../peripherals/gripper.md).
|
||||
|
||||
::: info
|
||||
This feature was added in PX4 v1.14 with support for Gripper (only).
|
||||
Package delivery missions will be extended to support other cargo release hardware in future, including winches.
|
||||
:::
|
||||
|
||||
## Delivery Mechanism Configuration
|
||||
|
||||
Package delivery missions require some configuration, which must be done before a mission can be planned and executed.
|
||||
|
||||
The configuration is largely hardware-specific, and is hence covered in the setup page for each type of package delivery hardware:
|
||||
|
||||
- [Gripper > Package Delivery Configuration](../peripherals/gripper.md#package-delivery-configuration)
|
||||
|
||||
## Mission Planning
|
||||
|
||||
A package delivery mission is planned in much the same as any other [waypoint mission](../flying/missions.md), with mission start, takeoff waypoint, various path waypoints, and possibly a return waypoint.
|
||||
The only difference is that a package delivery mission must include a mission item that indicates whether the package should be released on the ground (`Land`) or in-air (`Waypoint`), followed by another mission item to deploy the package (`Gripper Mechanism`).
|
||||
|
||||
Whether or not you `Land` depends on whether the package can safely be deployed while flying, and if the vehicle is capable of landing at the deployment location.
|
||||
Since a gripper cannot lower packages safely, multicopter and VTOL vehicles will often land to deploy packages when using a gripper.
|
||||
|
||||
After the deployment device [indicates completion](#package-release-feedback), the vehicle will proceed to the next waypoint.
|
||||
Note that if landed, the next mission item after deployment should be another `Waypoint` or a `Takeoff` mission item ([it must not be a `RETURN`](#rtl-waypoint-for-package-delivery-with-landing).)
|
||||
|
||||
## Creating a Package Delivery Mission
|
||||
|
||||
To create a package delivery mission (with a Gripper):
|
||||
|
||||
1. Create a normal mission with a `Takeoff` mission item, and additional waypoints for your required flight path.
|
||||
1. Add a waypoint on the map for where you'd like to release the package.
|
||||
|
||||
- To drop the package while flying set an appropriate altitude for the waypoint (and ensure the waypoint is at a safe location to drop the package).
|
||||
|
||||
- If you'd like to land the vehicle to make the delivery you will need to change the `Waypoint` to a `Land` mission item.
|
||||
Do this by selecting the mission item heading, then selecting `Land` in the popup dialog.
|
||||
|
||||
|
||||
|
||||
1. Add a waypoint on the map (anywhere) for the gripper release.
|
||||
To change this to a `Gripper Mechanism` select the "Waypoint" heading, and in the popup changing the group to "Advanced", then selecting `Gripper Mechanism`.
|
||||
|
||||
|
||||
|
||||
1. Configure the action for the gripper in the editor.
|
||||
|
||||
|
||||
|
||||
- Set it to "Release" in order to release the package.
|
||||
- The gripper ID does not need to be set for now.
|
||||
|
||||
1. Add additional waypoints for the remainder of the path.
|
||||
If you landed, then remember that you must include a waypoint after the `Gripper Mechanism` before adding a `Return` mission item.
|
||||
|
||||
### Example Plans
|
||||
|
||||
#### Package Drop Mission
|
||||
|
||||
This shows a mission plan where the vehicle drops the package while flying.
|
||||
The initial mission item is a waypoint and the action is a `Gripper Release` (shown in mission item list)
|
||||
|
||||
|
||||
|
||||
Note how the altitude graph shows the pre-waypoint as an in-air waypoint, also on the right panel.
|
||||
|
||||
#### Land and Release Mission
|
||||
|
||||
This shows a mission plan that where the vehicle lands to deliver the package.
|
||||
|
||||
|
||||
|
||||
Note how the altitude graph shows the `Land` item.
|
||||
|
||||
### Notes
|
||||
|
||||
#### RTL Waypoint for Package Delivery with Landing
|
||||
|
||||
Do not plan a mission with a delivery like this: `LAND` > `GRIPPER` > `RETURN TO LAUNCH`.
|
||||
|
||||
For safety reasons "Return To Launch" is disabled when vehicle is landed ([related issue](https://github.com/PX4/PX4-Autopilot/pull/20044)).
|
||||
So if you land, release the cargo, then have an RTL waypoint, the vehicle will idle at the landing coordinate.
|
||||
|
||||
#### Manual Control of Gripper in Missions
|
||||
|
||||
A gripper can be [manually controlled using a joystick button](../peripherals/gripper.md#qgc-joystick-configuration) (if configured) in any mode, including during a mission.
|
||||
|
||||
Note however that if you manually command the gripper to close while a package delivery mission is opening the gripper, the gripper won't be able to finish the open action.
|
||||
The mission will resume after the mission command timeout ([MIS_COMMAND_TOUT](../advanced_config/parameter_reference.md#MIS_COMMAND_TOUT)) expires, even if it has not released the package.
|
||||
|
||||
#### Auto-disarming is Disabled in Missions
|
||||
|
||||
Auto disarming is disabled by default when in mission.
|
||||
This means that while landed for package delivery the vehicle will still be armed (and potentially dangerous!)
|
||||
|
||||
#### Package Release Feedback
|
||||
|
||||
The mission will proceed after a "package release" mission item (e.g. `GRIPPER`) completes.
|
||||
|
||||
Grippers and other delivery devices either use sensor feedback or a configurable timeout to indicate completion.
|
||||
@@ -0,0 +1,30 @@
|
||||
# Safety Points (Rally Points)
|
||||
|
||||
Safety points are alternative [Return Mode](../flight_modes/return.md) destinations/landing points.
|
||||
When enabled, the vehicle will choose the *closest return destination* of: home location, mission landing pattern or a *safety point*.
|
||||
|
||||
|
||||
|
||||
## Creating/Defining Safety Points
|
||||
|
||||
Safety points are created in *QGroundControl* (which calls them "Rally Points").
|
||||
|
||||
At high level:
|
||||
1. Open **QGroundControl > Plan View**
|
||||
1. Select the **Rally** tab/button on the *Plan Editor* (right of screen).
|
||||
1. Select the **Rally Point** button on the toolbar (left of screen).
|
||||
1. Click anywhere on the map to add a rally/safety point.
|
||||
- The *Plan Editor* displays and lets you edit the current rally point (shown as a green **R** on the map).
|
||||
- You can select another rally point (shown as a more orange/yellow **R** on the map) to edit it instead.
|
||||
1. Select the **Upload Required** button to upload the rally points (along with any [mission](../flying/missions.md) and [geofence](../flying/geofence.md)) to the vehicle.
|
||||
|
||||
:::tip
|
||||
More complete documentation can be found in the *QGroundControl User Guide*: [Plan View - Rally Points](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/plan_view/plan_rally_points.html).
|
||||
:::
|
||||
|
||||
## Using Safety Points
|
||||
|
||||
Safety points are not enabled by default (there are a number of different [Return Mode Types](../flight_modes/return.md#return_types)).
|
||||
|
||||
To enable safety points:
|
||||
1. [Use the QGroundControl Parameter Editor](../advanced_config/parameters.md) to set parameter: [RTL_TYPE=3](../advanced_config/parameter_reference.md#RTL_TYPE).
|
||||
@@ -0,0 +1,132 @@
|
||||
# QGroundControl Flight-Readiness Status
|
||||
|
||||
PX4 performs a number of preflight sensor quality and estimator checks to determine if, for example, there is a good enough position estimate to fly the vehicle in the current mode, and will block arming if the vehicle is not ready.
|
||||
|
||||
QGroundControl can be used to determine whether the vehicle is ready to fly, and more importantly what checks are failing.
|
||||
|
||||
::: tip
|
||||
You can also get readiness notifications from the [vehicle status LEDs](../getting_started/led_meanings.md) and [warning tunes](../getting_started/tunes.md).
|
||||
However QGC is the only way to determine the precise reasons why PX4 will not arm.
|
||||
:::
|
||||
|
||||
## Flight Readiness Status
|
||||
|
||||
The overall "readiness to fly" is displayed in QGroundControl in the top left corner near the **Q** menu icon, as shown below:
|
||||
|
||||
|
||||
|
||||
The three states are:
|
||||
|
||||
- "Ready to Fly" (Green background): The vehicle is ready to fly in all modes, and can be armed.
|
||||
- "Ready to Fly" (Amber background): The vehicle is ready to fly in the current mode and can be armed, but some check is failing that means it will not be able to switch to some other mode.
|
||||
- "Not Ready" (Amber background): The vehicle is not ready to fly in the current mode, and cannot be armed.
|
||||
|
||||
## QGC Arming Check Report
|
||||
|
||||
<Badge type="tip" text="PX4 v1.14" /> <Badge type="tip" text="QGC v4.2.0" />
|
||||
|
||||
You can find out what prearming checks are failing using the QGroundControl [Arming Check Report](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/fly_view/fly_view.html#arm) in _Fly View_.
|
||||
To access this UI select the [Flight Readiness Status](#flight-readiness-status) indicator in the top left corner of QGroundControl's Fly View.
|
||||
|
||||
|
||||
|
||||
The Arming Check Report will then pop up and list all current warnings, with a toggle on the right of each warning that expands each entry with additional information and possible solutions.
|
||||
|
||||
Once each issue is resolved it will disappear from the UI. When all issues blocking arming have been removed you can use the arm button to display the arming confirmation slider, and arm the vehicle (or you can just take off).
|
||||
|
||||
::: tip
|
||||
The QGC Arming Checks UI is available in the QGC Daily Build (QGC v4.2.0 and later), and works with PX4 v1.14 and later.
|
||||
:::
|
||||
|
||||
## Flight Logs
|
||||
|
||||
Preflight errors are also reported in _QGroundControl_ as `PREFLIGHT FAIL` messages.
|
||||
The `estimator_status.gps_check_fail_flags` message [in the logs](../getting_started/flight_reporting.md) shows which GPS quality checks are failing.
|
||||
|
||||
Note that the [Arming Check Report](#qgc-arming-check-report) is a much easier way to determine reasons for failure, but the logs may be useful in versions prior to PX4 v1.14.
|
||||
|
||||
## EKF Preflight Checks/Errors
|
||||
|
||||
This sections lists errors, with associated checks and parameters, that are reported by [EKF2](../advanced_config/tuning_the_ecl_ekf.md) (and propagate to _QGroundControl_).
|
||||
These are provided for information only (the QGC Arming Checks UI is the best way to get error and solution information).
|
||||
|
||||
#### PREFLIGHT FAIL: EKF HIGH IMU ACCEL BIAS
|
||||
|
||||
<!-- https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/Arming/PreFlightCheck/checks/ekf2Check.cpp#L267 -->
|
||||
<!-- Useful primer on biases: https://www.vectornav.com/resources/inertial-navigation-primer/specifications--and--error-budgets/specs-imuspecs -->
|
||||
<!-- Mathieu Bresciani is expert -->
|
||||
|
||||
The EKF IMU acceleration bias is the difference between the measured acceleration reported by the IMU sensor and the expected acceleration reported by the EKF2 estimator (which fuses position and/or velocity data from a number of sources, including the IMU, GNSS, flow sensors etc.).
|
||||
This bias may change when the sensor is turned on ("turn-on bias") and over time due to noise and temperature differences ("in-run bias").
|
||||
The number should generally be very small (near zero), indicating that measurements from different sources all agree on the acceleration.
|
||||
|
||||
The warning indicates that the bias is higher than some arbitrary threshold (the vehicle will not be allowed to take off).
|
||||
It is most likely a sign that accelerometer or thermal calibration are required:
|
||||
|
||||
- If you _sometimes_ get the warning: [re-calibrate the accelerometer](../config/accelerometer.md).
|
||||
- If you get _regularly_ get the warning: Perform a [thermal calibration](../advanced_config/sensor_thermal_calibration.md).
|
||||
- If you still get the warning after thermal calibration (or you can't perform thermal calibration):
|
||||
- Verify that the issues do not come from the sensor or autopilot hardware:
|
||||
- The easiest way to do this is to test the same frame/sensors with another autopilot.
|
||||
- Alternatively, [log and compare](../dev_log/logging.md#configuration) all accelerometers across a number of bench test runs with `6: Sensor comparison` enabled in [SDLOG_PROFILE](../advanced_config/parameter_reference.md#SDLOG_PROFILE).
|
||||
- Attempt to change the accelerometer bias learning tuning parameters.
|
||||
|
||||
Increasing the parameters will make the autopilot less likely to detect an anomaly and can modify the stability of the estimator.
|
||||
However it may be required if there are problems with the sensor that cannot be fixed by other means (i.e you can tune the EKF for better performance, but there is no way you can calibrate the accelerometer "better").
|
||||
|
||||
:::warning
|
||||
Tuning these parameters is a last resort.
|
||||
It should only be attempted if you have data showing it will improve the performance of the estimator.
|
||||
:::
|
||||
|
||||
| Parameter | Description |
|
||||
| ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| <a id="EKF2_ABL_LIM"></a>[EKF2_ABL_LIM](../advanced_config/parameter_reference.md#EKF2_ABL_LIM) | The maximum bias value that the EKF is allowed to estimate (above this value the bias will be clipped and EKF will attempt to reset itself, possibly even switching to a more healthy EKF with a working IMU in a multi-EKF system). The autopilot will report a "high accel bias" if the estimated bias exceeds 75% of this parameter during a preflight check and prevent takeoff. The current value of 0.4m/s2 is already quite high and increasing it would make the autopilot less likely to detect an issue. |
|
||||
| <a id="EKF2_ABIAS_INIT"></a>[EKF2_ABIAS_INIT](../advanced_config/parameter_reference.md#EKF2_ABIAS_INIT) | Initial bias uncertainty (if perfectly calibrated, this is related to the "turn-on bias" of the sensor). Some users might want to reduce that value if they know that the sensor is well calibrated and that the turn-on bias is small. |
|
||||
| <a id="EKF2_ACC_B_NOISE"></a>[EKF2_ACC_B_NOISE](../advanced_config/parameter_reference.md#EKF2_ACC_B_NOISE) | The expected "in-run bias" of the accelerometer or "how fast do we expect the bias to change per second". By default, this value is large enough to include the drift due to a temperature change. If the IMU is temperature calibrated, the user might want to reduce this parameter. |
|
||||
| <a id="EKF2_ABL_ACCLIM"></a>[EKF2_ABL_ACCLIM](../advanced_config/parameter_reference.md#EKF2_ABL_ACCLIM) | The maximum acceleration at which the estimator will try to learn an acceleration bias. This is to prevent the estimator from learning a bias due to non-linearity and scale factor errors. (Almost no user should need to change that parameter except if they really know what they are doing). |
|
||||
|
||||
#### PREFLIGHT FAIL: EKF HIGH IMU GYRO BIAS
|
||||
|
||||
- This error is produced when the IMU gyro bias estimated by the EKF is excessive.
|
||||
- Excessive in this case means that the bias estimate exceeds 10deg/s (half the configured limit, which is hardcoded to 20deg/s).
|
||||
|
||||
#### PREFLIGHT FAIL: ACCEL SENSORS INCONSISTENT - CHECK CALIBRATION
|
||||
|
||||
- This error message is produced when the acceleration measurements from different IMU units are inconsistent.
|
||||
- This check only applies to boards with more than one IMU.
|
||||
- The check is controlled by the [COM_ARM_IMU_ACC](../advanced_config/parameter_reference.md#COM_ARM_IMU_ACC) parameter.
|
||||
|
||||
#### PREFLIGHT FAIL: GYRO SENSORS INCONSISTENT - CHECK CALIBRATION
|
||||
|
||||
- This error message is produced when the angular rate measurements from different IMU units are inconsistent.
|
||||
- This check only applies to boards with more than one IMU.
|
||||
- The check is controlled by the [COM_ARM_IMU_GYR](../advanced_config/parameter_reference.md#COM_ARM_IMU_GYR) parameter.
|
||||
|
||||
#### PREFLIGHT FAIL: COMPASS SENSORS INCONSISTENT - CHECK CALIBRATION
|
||||
|
||||
- This error message is produced when the difference in measurements from different compass sensors is too great.
|
||||
- It indicates bad calibration, orientation or magnetic interference.
|
||||
- This check only applies to when more than one compass/magnetometer is connected.
|
||||
- The check is controlled by the [COM_ARM_MAG_ANG](../advanced_config/parameter_reference.md#COM_ARM_MAG_ANG) parameter.
|
||||
|
||||
#### PREFLIGHT FAIL: EKF INTERNAL CHECKS
|
||||
|
||||
- This error message is generated if the innovation magnitudes of either the horizontal GPS velocity, magnetic yaw, vertical GPS velocity or vertical position sensor (Baro by default but could be range finder or GPS if non-standard parameters are being used) are excessive. Innovations are the difference between the value predicted by the inertial navigation calculation and measured by the sensor.
|
||||
- Users should check the innovation levels in the log file to determine the cause. These can be found under the `ekf2_innovations` message.
|
||||
Common problems/solutions include:
|
||||
- IMU drift on warmup. May be resolved by restarting the autopilot. May require an IMU accel and gyro calibration.
|
||||
- Adjacent magnetic interference combined with vehicle movement. Resolve my moving vehicle and waiting or re-powering.
|
||||
- Bad magnetometer calibration combined with vehicle movement. Resolve by recalibrating.
|
||||
- Initial shock or rapid movement on startup that caused a bad inertial nav solution. Resolve by restarting the vehicle and minimising movement for the first 5 seconds.
|
||||
|
||||
## Other Parameters
|
||||
|
||||
The following parameters also affect preflight checks.
|
||||
|
||||
#### COM_ARM_WO_GPS
|
||||
|
||||
The [COM_ARM_WO_GPS](../advanced_config/parameter_reference.md#COM_ARM_WO_GPS) parameter controls whether or not arming is allowed without a global position estimate.
|
||||
|
||||
- `1` (default): Arming _is_ allowed without a position estimate for flight modes that do not require position information (only).
|
||||
- `0`: Arming is allowed only if EKF is providing a global position estimate and EFK GPS quality checks are passing
|
||||
@@ -0,0 +1,52 @@
|
||||
# Terrain Following/Holding
|
||||
|
||||
PX4 supports [Terrain Following](#terrain_following) and [Terrain Hold](#terrain_hold) in [Position](../flight_modes_mc/position.md) and [Altitude modes](../flight_modes_mc/altitude.md), on *multicopters* and *VTOL vehicles in MC mode* that have a [distance sensor](../sensor/rangefinders.md).
|
||||
|
||||
::: info
|
||||
PX4 does not "natively" support terrain following in missions.
|
||||
*QGroundControl* can be used to define missions that *approximately* follow terrain (this just sets waypoint altitudes based on height above terrain, where terrain height at waypoints is obtained from a map database).
|
||||
:::
|
||||
|
||||
<a id="terrain_following"></a>
|
||||
|
||||
## Terrain Following
|
||||
|
||||
*Terrain following* enables a vehicle to automatically maintain a relatively constant height above ground level when traveling at low altitudes.
|
||||
This is useful for avoiding obstacles and for maintaining constant height when flying over varied terrain (e.g. for aerial photography).
|
||||
|
||||
:::tip
|
||||
This feature can be enabled in [Position](../flight_modes_mc/position.md) and [Altitude modes](../flight_modes_mc/altitude.md), on *multicopters* and *VTOL vehicles in MC mode* that have a [distance sensor](../sensor/rangefinders.md).
|
||||
:::
|
||||
|
||||
When *terrain following* is enabled, PX4 uses the output of the EKF estimator to provide the altitude estimate, and the estimated terrain altitude (calculated from distance sensor measurements using another estimator) to provide the altitude setpoint.
|
||||
As the distance to ground changes, the altitude setpoint adjusts to keep the height above ground constant.
|
||||
|
||||
At higher altitudes (when the estimator reports that the distance sensor data is invalid) the vehicle switches to *altitude following*, and will typically fly at a near-constant height above mean sea level (AMSL) using an absolute height sensor for altitude data.
|
||||
|
||||
::: info
|
||||
More precisely, the vehicle will use the available selected sources of altitude data as defined in [Using PX4's Navigation Filter (EKF2) > Height](../advanced_config/tuning_the_ecl_ekf.md#height).
|
||||
:::
|
||||
|
||||
Terrain following is enabled by setting [MPC_ALT_MODE](../advanced_config/parameter_reference.md#MPC_ALT_MODE) to `1`.
|
||||
|
||||
|
||||
<a id="terrain_hold"></a>
|
||||
|
||||
## Terrain Hold
|
||||
|
||||
*Terrain hold* uses a distance sensor to help a vehicle to better maintain a constant height above ground in altitude control modes, when horizontally stationary at low altitude.
|
||||
This allows a vehicle to avoid altitude changes due to barometer drift or excessive barometer interference from rotor wash.
|
||||
|
||||
::: info
|
||||
This feature can be enabled in [Position](../flight_modes_mc/position.md) and [Altitude modes](../flight_modes_mc/altitude.md), on *multicopters* and *VTOL vehicles in MC mode* that have a [distance sensor](../sensor/rangefinders.md).
|
||||
:::
|
||||
|
||||
When moving horizontally (`speed >` [MPC_HOLD_MAX_XY](../advanced_config/parameter_reference.md#MPC_HOLD_MAX_XY)), or above the altitude where the distance sensor is providing valid data, the vehicle will switch into *altitude following*.
|
||||
|
||||
Terrain holding is enabled by setting [MPC_ALT_MODE](../advanced_config/parameter_reference.md#MPC_ALT_MODE) to `2`.
|
||||
|
||||
::: info
|
||||
*Terrain hold* is implemented similarly to [terrain following](#terrain_following).
|
||||
It uses the output of the EKF estimator to provide the altitude estimate, and the estimated terrain altitude (calculated from distance sensor measurements using a separate, single state terrain estimator) to provide the altitude setpoint.
|
||||
If the distance to ground changes due to external forces, the altitude setpoint adjusts to keep the height above ground constant.
|
||||
:::
|
||||
Reference in New Issue
Block a user