mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-10-18 00:03:33 +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:
co-authored by
Ramon Roche
parent
8e6d2ebe4a
commit
88d623bedb
@@ -0,0 +1,350 @@
|
||||
# 충돌 방지
|
||||
|
||||
_Collision Prevention_ may be used to automatically slow and stop a vehicle before it can crash into an obstacle.
|
||||
It can be enabled for multicopter vehicles when using acceleration-based [Position mode](../flight_modes_mc/position.md) (or VTOL vehicles in MC mode).
|
||||
|
||||
It can be enabled for multicopter vehicles in [Position mode](../flight_modes_mc/position.md), and can use sensor data from an offboard companion computer, offboard rangefinders over MAVLink, a rangefinder attached to the flight controller, or any combination of the above.
|
||||
|
||||
Collision prevention may restrict vehicle maximum speed if the sensor range isn't large enough!
|
||||
It also prevents motion in directions where no sensor data is available (i.e. if you have no rear-sensor data, you will not be able to fly backwards).
|
||||
|
||||
:::tip
|
||||
If high flight speeds are critical, consider disabling collision prevention when not needed.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
Ensure that you have sensors/sensor data in all directions that you want to fly (when collision prevention is enabled).
|
||||
:::
|
||||
|
||||
## 개요
|
||||
|
||||
The vehicle restricts the current velocity in order to slow down as it gets closer to obstacles and adapts the acceleration setpoint in order to disallow collision trajectories.
|
||||
장애물에서 멀어지거나 평행하게 이동하려면 사용자는 기체를 장애물에 더 가깝게 만들지 않는 설정 값으로 이동하도록 명령하여야 합니다.
|
||||
The algorithm will make minor adjustments to the setpoint direction if it is determined that a “better” setpoint exists within a fixed margin on either side of the requested setpoint.
|
||||
|
||||
Users are notified through _QGroundControl_ while _Collision Prevention_ is actively controlling velocity setpoints.
|
||||
|
||||
PX4 software setup is covered in the next section.
|
||||
If you are using a distance sensor attached to your flight controller for collision prevention, it will need to be attached and configured as described in [PX4 Distance Sensor](#rangefinder).
|
||||
If you are using a companion computer to provide obstacle information see [companion setup](#companion
|
||||
|
||||
## Supported Rangefinders {#rangefinder}
|
||||
|
||||
### Lanbao PSK-CM8JL65-CC5 [Discontinued]
|
||||
|
||||
At time of writing PX4 allows you to use the [Lanbao PSK-CM8JL65-CC5](../sensor/cm8jl65_ir_distance_sensor.md) IR distance sensor for collision prevention “out of the box”, with minimal additional configuration:
|
||||
|
||||
- First [attach and configure the sensor](../sensor/cm8jl65_ir_distance_sensor.md), and enable collision prevention (as described above, using [CP_DIST](#CP_DIST)).
|
||||
- Set the sensor orientation using [SENS_CM8JL65_R_0](../advanced_config/parameter_reference.md#SENS_CM8JL65_R_0).
|
||||
|
||||
### LightWare LiDAR SF45 Rotating Lidar
|
||||
|
||||
PX4 v1.14 (and later) supports the [LightWare LiDAR SF45](../sensor/sf45_rotating_lidar.md) rotating lidar which provides 320 degree sensing.
|
||||
|
||||
### Other Rangefinders
|
||||
|
||||
다른 센서를 활성화 할 수 있지만, 이를 위해서는 센서 방향과 시야를 설정하기 위하여 드라이버 코드를 수정하여야 합니다.
|
||||
|
||||
- Attach and configure the distance sensor on a particular port (see [sensor-specific docs](../sensor/rangefinders.md)) and enable collision prevention using [CP_DIST](#CP_DIST).
|
||||
- 방향을 설정하려면 드라이버를 수정하십시오.
|
||||
This should be done by mimicking the `SENS_CM8JL65_R_0` parameter (though you might also hard-code the orientation in the sensor _module.yaml_ file to something like `sf0x start -d ${SERIAL_DEV} -R 25` - where 25 is equivalent to `ROTATION_DOWNWARD_FACING`).
|
||||
- Modify the driver to set the _field of view_ in the distance sensor UORB topic (`distance_sensor_s.h_fov`).
|
||||
|
||||
## PX4 (Software) Setup
|
||||
|
||||
Configure collision prevention by [setting the following parameters](../advanced_config/parameters.md) in _QGroundControl_:
|
||||
|
||||
| 매개변수 | 설명 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| <a id="CP_DIST"></a>[CP_DIST](../advanced_config/parameter_reference.md#CP_DIST) | Set the minimum allowed distance (the closest distance that the vehicle can approach the obstacle). Set negative to disable _collision prevention_. <br>> **Warning** This value is the distance to the sensors, not the outside of your vehicle or propellers. Be sure to leave a safe margin! |
|
||||
| <a id="CP_DELAY"></a>[CP_DELAY](../advanced_config/parameter_reference.md#CP_DELAY) | Set the sensor and velocity setpoint tracking delay. See [Delay Tuning](#delay_tuning) below. |
|
||||
| <a id="CP_GUIDE_ANG"></a>[CP_GUIDE_ANG](../advanced_config/parameter_reference.md#CP_GUIDE_ANG) | Set the angle (to both sides of the commanded direction) within which the vehicle may deviate if it finds fewer obstacles in that direction. See [Guidance Tuning](#angle_change_tuning) below. |
|
||||
| <a id="CP_GO_NO_DATA"></a>[CP_GO_NO_DATA](../advanced_config/parameter_reference.md#CP_GO_NO_DATA) | Set to 1 to allow the vehicle to move in directions where there is no sensor coverage (default is 0/`False`). |
|
||||
| <a id="MPC_POS_MODE"></a>[MPC_POS_MODE](../advanced_config/parameter_reference.md#MPC_POS_MODE) | Set to `Direct velocity` or `Smoothed velocity` to enable Collision Prevention in Position Mode (default is `Acceleration based`). |
|
||||
|
||||
## 알고리즘 설명
|
||||
|
||||
The data from all sensors are fused into an internal representation of 36 sectors around the vehicle, each containing either the sensor data and information about when it was last observed, or an indication that no data for the sector was available.
|
||||
When the vehicle is commanded to move in a particular direction, all sectors in the hemisphere of that direction are checked to see if the movement will bring the vehicle closer to any obstacles.
|
||||
그러한 경우에는, 차량 속도가 제한됩니다.
|
||||
|
||||
This velocity restriction takes into account both the inner velocity loop tuned by [MPC_XY_P](../advanced_config/parameter_reference.md#MPC_XY_P), as well as the [jerk-optimal velocity controller](../config_mc/mc_jerk_limited_type_trajectory.md) via [MPC_JERK_MAX](../advanced_config/parameter_reference.md#MPC_JERK_MAX) and [MPC_ACC_HOR](../advanced_config/parameter_reference.md#MPC_ACC_HOR).
|
||||
The velocity is restricted such that the vehicle will stop in time to maintain the distance specified in [CP_DIST](#CP_DIST).
|
||||
The range of the sensors for each sector is also taken into account, limiting the velocity via the same mechanism.
|
||||
|
||||
:::info
|
||||
If there is no sensor data in a particular direction, velocity in that direction is restricted to 0 (preventing the vehicle from crashing into unseen objects).
|
||||
If you wish to move freely into directions without sensor coverage, this can be enabled by setting [CP_GO_NO_DATA](#CP_GO_NO_DATA) to 1.
|
||||
:::
|
||||
|
||||
Delay, both in the vehicle tracking velocity setpoints and in receiving sensor data from external sources, is conservatively estimated via the [CP_DELAY](#CP_DELAY) parameter.
|
||||
This should be [tuned](#delay_tuning) to the specific vehicle.
|
||||
|
||||
If the sectors adjacent to the commanded sectors are 'better' by a significant margin, the direction of the requested input can be modified by up to the angle specified in [CP_GUIDE_ANG](#CP_GUIDE_ANG).
|
||||
This helps to fine-tune user input to 'guide' the vehicle around obstacles rather than getting stuck against them.
|
||||
|
||||
### Range Data Loss
|
||||
|
||||
If the autopilot does not receive range data from any sensor for longer than 0.5s, it will output a warning _No range data received, no movement allowed_.
|
||||
This will force the velocity setpoints in xy to zero.
|
||||
After 5 seconds of not receiving any data, the vehicle will switch into [HOLD mode](../flight_modes_mc/hold.md).
|
||||
If you want the vehicle to be able to move again, you will need to disable Collision Prevention by either setting the parameter [CP_DIST](#CP_DIST) to a negative value, or switching to a mode other than [Position mode](../flight_modes_mc/position.md) (e.g. to _Altitude mode_ or _Stabilized mode_).
|
||||
|
||||
If you have multiple sensors connected and you lose connection to one of them, you will still be able to fly inside the field of view (FOV) of the reporting sensors.
|
||||
The data of the faulty sensor will expire and the region covered by this sensor will be treated as uncovered, meaning you will not be able to move there.
|
||||
|
||||
:::warning
|
||||
Be careful when enabling [CP_GO_NO_DATA=1](#CP_GO_NO_DATA), which allows the vehicle to fly outside the area with sensor coverage.
|
||||
If you lose connection to one of multiple sensors, the area covered by the faulty sensor is also treated as uncovered and you will be able to move there without constraint.
|
||||
:::
|
||||
|
||||
### CP_DELAY Delay Tuning {#delay_tuning}
|
||||
|
||||
There are two main sources of delay which should be accounted for: _sensor delay_, and vehicle _velocity setpoint tracking delay_.
|
||||
Both sources of delay are tuned using the [CP_DELAY](#CP_DELAY) parameter.
|
||||
|
||||
The _sensor delay_ for distance sensors connected directly to the flight controller can be assumed to be 0.
|
||||
외부 비전 기반 시스템의 경우 센서 지연이 최대 0.2 초 일 수 있습니다.
|
||||
|
||||
Vehicle _velocity setpoint tracking delay_ can be measured by flying at full speed in [Position mode](../flight_modes_mc/position.md), then commanding a stop.
|
||||
실제 속도와 속도 설정점 사이의 지연은 로그에서 측정할 수 있습니다.
|
||||
추적 지연은 일반적으로 기체 크기와 튜닝에 따라 0.1 초에서 0.5 초 사이입니다.
|
||||
|
||||
:::tip
|
||||
If vehicle speed oscillates as it approaches the obstacle (i.e. it slows down, speeds up, slows down) the delay is set too high.
|
||||
:::
|
||||
|
||||
### CP_GUIDE_ANG Guidance Tuning {#angle_change_tuning}
|
||||
|
||||
차량, 환경 유형 및 조종사의 기술에 따라 각기 다른 가이던스가 필요할 수 있습니다.
|
||||
Setting the [CP_GUIDE_ANG](#CP_GUIDE_ANG) parameter to 0 will disable the guidance, resulting in the vehicle only moving exactly in the directions commanded.
|
||||
이 매개 변수를 높이면 기체가 장애물을 피할 수 있는 최적의 방향을 선택할 수 있으므로 좁은 틈새를 더 쉽게 통과하고 물체를 돌아 다니는 동안 최소 거리를 정확하게 유지할 수 있습니다.
|
||||
|
||||
If this parameter is too small the vehicle may feel "stuck" when close to obstacles, because only movement away from obstacles at minimum distance are allowed.
|
||||
If the parameter is too large the vehicle may feel like it slides away from obstacles in directions not commanded by the operator.
|
||||
테스트에서 30도는 적절한 값이지만, 기체마다 값이 달라질 수 있습니다.
|
||||
|
||||
:::info
|
||||
The guidance feature will never direct the vehicle in a direction without sensor data.
|
||||
If the vehicle feels stuck with only a single distance sensor pointing forwards, this is probably because the guidance cannot safely adapt the direction due to lack of information.
|
||||
:::
|
||||
|
||||
## 알고리즘 설명
|
||||
|
||||
The data from all sensors are fused into an internal representation of 72 sectors around the vehicle, each containing either the sensor data and information about when it was last observed, or an indication that no data for the sector was available.
|
||||
When the vehicle is commanded to move in a particular direction, all sectors in the hemisphere of that direction are checked to see if the movement will bring the vehicle closer than allowed to any obstacles. 그러한 경우에는, 차량 속도가 제한됩니다.
|
||||
|
||||
The Algorithm then can be split into two parts, the constraining of the acceleration setpoint coming from the operator, and the compensation of the current velocity of the vehicle.
|
||||
|
||||
:::info
|
||||
If there is no sensor data in a particular direction, movement in that direction is restricted to 0 (preventing the vehicle from crashing into unseen objects).
|
||||
If you wish to move freely into directions without sensor coverage, this can be enabled by setting [CP_GO_NO_DATA](#CP_GO_NO_DATA) to 1.
|
||||
:::
|
||||
|
||||
### 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.
|
||||
|
||||

|
||||
|
||||
<!-- the code for this figure is at the end of this file -->
|
||||
|
||||
### Velocity compensation
|
||||
|
||||
This velocity restriction takes into account the [jerk-optimal velocity controller](../config_mc/mc_jerk_limited_type_trajectory.md) via [MPC_JERK_MAX](../advanced_config/parameter_reference.md#MPC_JERK_MAX) and [MPC_ACC_HOR](../advanced_config/parameter_reference.md#MPC_ACC_HOR). Whereby <!--this is only partially valid anymore... check -->
|
||||
The current velocity is compared with the maximum allowed velocity so that we are still able to break based on the maximal allowed jerk, acceleration and delay. from this we are able to use the proportional gain of the acceleration controller([MPC_XY_VEL_P_ACC](../advanced_config/parameter_reference.md#MPC_XY_VEL_P_ACC)) to transform it into an acceleration.
|
||||
|
||||
### Delay
|
||||
|
||||
The delay associated with collision prevention, both in the vehicle tracking velocity setpoints and in receiving sensor data from external sources, is conservatively estimated via the [CP_DELAY](#CP_DELAY) parameter.
|
||||
This should be [tuned](#delay_tuning) to the specific vehicle.
|
||||
|
||||
## Companion Setup {#companion}
|
||||
|
||||
:::warning
|
||||
The companion implementation/setup is currently untested (the original companion project was unmaintained and has been archived).
|
||||
:::
|
||||
|
||||
If using a companion computer or external sensor, it needs to supply a stream of [OBSTACLE_DISTANCE](https://mavlink.io/en/messages/common.html#OBSTACLE_DISTANCE) messages, which should reflect when and where obstacle were detected.
|
||||
|
||||
The minimum rate at which messages _must_ be sent depends on vehicle speed - at higher rates the vehicle will have a longer time to respond to detected obstacles.
|
||||
Initial testing of the system used a vehicle moving at 4 m/s with `OBSTACLE_DISTANCE` messages being emitted at 10Hz (the maximum rate supported by the vision system).
|
||||
The system may work well at significantly higher speeds and lower frequency distance updates.
|
||||
|
||||
## Gazebo Simulation
|
||||
|
||||
_Collision Prevention_ can be tested using [Gazebo](../sim_gazebo_gz/index.md) with the [x500_lidar_2d](../sim_gazebo_gz/vehicles.md#x500-quadrotor-with-2d-lidar) model.
|
||||
To do this, start a simulation with the x500 lidar model by running the following command:
|
||||
|
||||
```sh
|
||||
make px4_sitl gz_x500_lidar_2d
|
||||
```
|
||||
|
||||
Next, adjust the relevant parameters to the appropriate values and add arbitrary obstacles to your simulation world to test the collision prevention functionality.
|
||||
|
||||
The diagram below shows a simulation of collision prevention as viewed in Gazebo.
|
||||
|
||||

|
||||
|
||||
## Development Information/Tools
|
||||
|
||||
### Plotting Obstacle Distance and Minimum Distance in Real-Time with PlotJuggler
|
||||
|
||||
[PlotJuggler](../log/plotjuggler_log_analysis.md) can be used to monitor and visualize obstacle distances in a real-time plot, including the minimum distance to the closest obstacle.
|
||||
|
||||
<lite-youtube videoid="amLheoHgwc4" title="Plotting Obstacle Distance and Minimum Distance in Real-Time with PlotJuggler"/>
|
||||
|
||||
To use this feature you need to add a reactive Lua script to PlotJuggler, and also configure PX4 to export [`obstacle_distance_fused`](../msg_docs/ObstacleDistance.md) UORB topic data.
|
||||
The Lua script works by extracting the `obstacle_distance_fused` data at each time step, converting the distance values into Cartesian coordinates, and pushing them to PlotJuggler.
|
||||
|
||||
단계는 다음과 같습니다:
|
||||
|
||||
1. Follow the instructions in [Plotting uORB Topic Data in Real Time using PlotJuggler](../debug/plotting_realtime_uorb_data.md)
|
||||
|
||||
2. Configure PX4 to publish obstacle distance data (so that it is available to PlotJuggler):
|
||||
|
||||
Add the [`obstacle_distance_fused`](../msg_docs/ObstacleDistance.md) UORB topic to your [`dds_topics.yaml`](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml) so that it is published by PX4:
|
||||
|
||||
```sh
|
||||
- topic: /fmu/out/obstacle_distance_fused
|
||||
type: px4_msgs::msg::ObstacleDistance
|
||||
```
|
||||
|
||||
For more information see [DDS Topics YAML](../middleware/uxrce_dds.md#dds-topics-yaml) in _uXRCE-DDS (PX4-ROS 2/DDS Bridge)_.
|
||||
|
||||
3. Open PlotJuggler and navigate to the **Tools > Reactive Script Editor** section.
|
||||
In the **Script Editor** tab, add following scripts in the appropriate sections:
|
||||
|
||||
- **Global code, executed once:**
|
||||
|
||||
```lua
|
||||
obs_dist_fused_xy = ScatterXY.new("obstacle_distance_fused_xy")
|
||||
obs_dist_min = Timeseries.new("obstacle_distance_minimum")
|
||||
```
|
||||
|
||||
- **function(tracker_time)**
|
||||
|
||||
```lua
|
||||
obs_dist_fused_xy:clear()
|
||||
|
||||
i = 0
|
||||
angle_offset = TimeseriesView.find("/fmu/out/obstacle_distance_fused/angle_offset")
|
||||
increment = TimeseriesView.find("/fmu/out/obstacle_distance_fused/increment")
|
||||
min_dist = 65535
|
||||
|
||||
-- Cache increment and angle_offset values at tracker_time to avoid repeated calls
|
||||
local angle_offset_value = angle_offset:atTime(tracker_time)
|
||||
local increment_value = increment:atTime(tracker_time)
|
||||
|
||||
if increment_value == nil or increment_value <= 0 then
|
||||
print("Invalid increment value: " .. tostring(increment_value))
|
||||
return
|
||||
end
|
||||
|
||||
local max_steps = math.floor(360 / increment_value)
|
||||
|
||||
while i < max_steps do
|
||||
local str = string.format("/fmu/out/obstacle_distance_fused/distances[%d]", i)
|
||||
local distance = TimeseriesView.find(str)
|
||||
if distance == nil then
|
||||
print("No distance data for: " .. str)
|
||||
break
|
||||
end
|
||||
|
||||
local dist = distance:atTime(tracker_time)
|
||||
if dist ~= nil and dist < 65535 then
|
||||
-- Calculate angle and Cartesian coordinates
|
||||
local angle = angle_offset_value + i * increment_value
|
||||
local y = dist * math.cos(math.rad(angle))
|
||||
local x = dist * math.sin(math.rad(angle))
|
||||
|
||||
obs_dist_fused_xy:push_back(x, y)
|
||||
|
||||
-- Update minimum distance
|
||||
if dist < min_dist then
|
||||
min_dist = dist
|
||||
end
|
||||
end
|
||||
|
||||
i = i + 1
|
||||
end
|
||||
|
||||
-- Push minimum distance once after the loop
|
||||
if min_dist < 65535 then
|
||||
obs_dist_min:push_back(tracker_time, min_dist)
|
||||
else
|
||||
print("No valid minimum distance found")
|
||||
end
|
||||
```
|
||||
|
||||
4. Enter a name for the script on the top right, and press **Save**.
|
||||
Once saved, the script should appear in the _Active Scripts_ section.
|
||||
|
||||
5. Start streaming the data using the approach described in [Plotting uORB Topic Data in Real Time using PlotJuggler](../debug/plotting_realtime_uorb_data.md).
|
||||
You should see the `obstacle_distance_fused_xy` and `obstacle_distance_minimum` timeseries on the left.
|
||||
|
||||
Note that you have to press **Save** again to re-enable the scripts after loading a new log file or otherwise clearing data.
|
||||
|
||||
### Sensor Data Overview
|
||||
|
||||
Collision Prevention has an internal obstacle distance map that divides the plane around the drone into 72 Sectors.
|
||||
Internally this information is stored in the [`obstacle_distance`](../msg_docs/ObstacleDistance.md) UORB topic.
|
||||
New sensor data is compared to the existing map, and used to update any sections that has changed.
|
||||
|
||||
The angles in the `obstacle_distance` topic are defined as follows:
|
||||
|
||||

|
||||
|
||||
The data from rangefinders, rotary lidars, or companion computers, is processed differently, as described below.
|
||||
|
||||
#### Rotary Lidars
|
||||
|
||||
Rotary Lidars add their data directly to the [`obstacle_distance`](../msg_docs/ObstacleDistance.md) uORB topic.
|
||||
|
||||
#### Rangefinders
|
||||
|
||||
Rangefinders publish their data to the [`distance_sensor`](../msg_docs/DistanceSensor.md) uORB topic.
|
||||
|
||||
This data is then mapped onto the `obstacle_distance` topic.
|
||||
All sectors which have any overlap with the orientation (`orientation` and `q`) of the rangefinder, and the horizontal field of view (`h_fov`) are assigned that measurement value.
|
||||
For example, a distance sensor measuring from 9.99° to 10.01° the measurements will get added to the bin's corresponding to 5° and 10° covering the arc from 2.5° and 12.5°
|
||||
|
||||
:::info
|
||||
the quaternion `q` is only used if the `orientation` is set to `ROTATION_CUSTOM`.
|
||||
:::
|
||||
|
||||
#### 보조 컴퓨터
|
||||
|
||||
Companion computers update the `obstacle_distance` topic using ROS2 or the [OBSTACLE_DISTANCE](https://mavlink.io/en/messages/common.html#OBSTACLE_DISTANCE) MAVLink message.
|
||||
|
||||
<!-- to edit the image, open it in inkscape -->
|
||||
|
||||
<!-- Code to generate the scalefactor plot
|
||||
import numpy as np
|
||||
import matplotlib.pyplot as plt
|
||||
obstacle_dist = -5
|
||||
cp_dist = 0
|
||||
scale_dist = 10
|
||||
x_values_1 = np.linspace(obstacle_dist, cp_dist, 100) # Segment 1: obstacle to cp_dist
|
||||
x_values_2 = np.linspace(cp_dist, scale_dist, 100) # Segment 2: cp_dist to scale_dist
|
||||
x_values_3 = np.linspace(scale_dist, 15, 100) # Segment 3: scale_dist onwards
|
||||
def acceleration_setpoint_1(x):
|
||||
return -1 + (x - obstacle_dist) / (cp_dist - obstacle_dist)
|
||||
def acceleration_setpoint_2(x):
|
||||
return ((x - cp_dist) / (scale_dist - cp_dist))**2
|
||||
def acceleration_setpoint_3(x):
|
||||
return 1
|
||||
y_values_1 = [acceleration_setpoint_1(x) for x in x_values_1]
|
||||
y_values_2 = [acceleration_setpoint_2(x) for x in x_values_2]
|
||||
y_values_3 = [acceleration_setpoint_3(x) for x in x_values_3]
|
||||
plt.figure(figsize=(15, 5))
|
||||
plt.plot(x_values_1, y_values_1, color='red', label="Below Zero", linewidth=4)
|
||||
plt.plot(x_values_2, y_values_2, color='orange', label="Above Zero", linewidth=4)
|
||||
plt.plot(x_values_3, y_values_3, color='green', label="Above Scale Distance", linewidth=4)
|
||||
plt.xlabel("Distance")
|
||||
plt.yticks([-1, 0, 1], ['-1', '0', '1']) # Set ticks at -1, 0, and 1
|
||||
plt.ylabel("Scalefactor") # Change y-axis label to "Scale"
|
||||
plt.title("Manual Acceleration Setpoint Scaling")
|
||||
plt.xticks([obstacle_dist, cp_dist, scale_dist], ['Obstacle', 'CP_DIST', 'scale_distance = MPC_VEL_MANUAL / MPC_XY_P'])
|
||||
plt.grid(True)
|
||||
plt.show() -->
|
||||
@@ -0,0 +1,23 @@
|
||||
# 컴퓨터 비전 (Optical Flow, MoCap, VIO, Avoidance)
|
||||
|
||||
[Computer vision](https://en.wikipedia.org/wiki/Computer_vision) techniques enable computers to use visual data to make sense of their environment.
|
||||
|
||||
PX4 uses computer vision systems (primarily running on [Companion Computers](../companion_computer/index.md)) in order to support the following features:
|
||||
|
||||
- Pose/Velocity Estimation:
|
||||
- [Optical Flow](../sensor/optical_flow.md) provides 2D velocity estimation (using a downward facing camera and a downward facing distance sensor).
|
||||
- [Motion Capture](../computer_vision/motion_capture.md) provides 3D pose estimation using a vision system that is _external_ to the vehicle.
|
||||
주로 실내 내비게이션에 사용됩니다.
|
||||
- [Visual Inertial Odometry (VIO)](../computer_vision/visual_inertial_odometry.md) provides 3D pose and velocity estimation using an onboard vision system and IMU.
|
||||
It is used for navigation when global position information is absent or unreliable.
|
||||
- Avoidance/Path Planning:
|
||||
- [Collision Prevention](../computer_vision/collision_prevention.md) is used to stop MC vehicles before they can crash into an obstacle (primarily when flying in manual modes).
|
||||
|
||||
:::tip
|
||||
The [PX4 Vision Autonomy Development Kit](../complete_vehicles_mc/px4_vision_kit.md) (Holybro) is a robust and inexpensive kit for developers working with computer vision on PX4.
|
||||
:::
|
||||
|
||||
## 외부 참고 자료
|
||||
|
||||
- [XTDrone](https://github.com/robin-shaun/XTDrone/blob/master/README.en.md) - ROS + PX4 v1.9 simulation environment for computer vision.
|
||||
The [XTDrone Manual](https://www.yuque.com/xtdrone/manual_en) has everything you need to get started!
|
||||
@@ -0,0 +1,19 @@
|
||||
# Motion Capture (MoCap)
|
||||
|
||||
Motion Capture (MoCap) is a [computer vision](https://en.wikipedia.org/wiki/Computer_vision) technique for estimating the 3D _pose_ (position and orientation) of a vehicle using a positioning mechanism that is _external_ to the vehicle.
|
||||
It is commonly used to navigate a vehicle in situations where GPS is absent (e.g. indoors), and provides position relative to a _local_ coordinate system.
|
||||
|
||||
_MoCap_ systems most commonly detect motion using infrared cameras, but other types of cameras, Lidar, or Ultra Wideband (UWB) may also be used.
|
||||
|
||||
:::info
|
||||
_MoCap_ is conceptually similar to [Visual Inertial Odometry (VIO)](../computer_vision/visual_inertial_odometry.md).
|
||||
가장 큰 차이점은 VIO는 기체내에서 비전 시스템이 동작하며, 속도 정보를 취득하기 위하여 기체의 관성 측정 장치(IMU)를 사용합니다.
|
||||
:::
|
||||
|
||||
## 모션 캡쳐 참고 자료
|
||||
|
||||
자세한 모션 캡쳐 기술은 다음을 참고하십시오:
|
||||
|
||||
- [Using Vision or Motion Capture Systems for Position Estimation](../ros/external_position_estimation.md). <!-- bring across info into user guide? -->
|
||||
- [Flying with Motion Capture (VICON, NOKOV, Optitrack)](../tutorials/motion-capture.md). <!-- bring across info into user guide? -->
|
||||
- [Using PX4's Navigation Filter (EKF2) > External Vision System](../advanced_config/tuning_the_ecl_ekf.md#external-vision-system)
|
||||
@@ -0,0 +1 @@
|
||||
<Redirect to="../computer_vision/path_planning_interface" />
|
||||
@@ -0,0 +1,21 @@
|
||||
# Path Planning Interface
|
||||
|
||||
<Badge type="warning" text="Removed" />
|
||||
|
||||
:::warning
|
||||
The **Path Planning Interface**, along with the features **Obstacle avoidance in Missions** and **Safe Landing** are no longer supported or maintained, and _should not_ be used in any PX4 version.
|
||||
|
||||
This code was abandoned due to architectural constraints of the implementation making it hard to maintain, extend, and adopt.
|
||||
Support has been withdrawn make it clear that this interface is untested.
|
||||
:::
|
||||
|
||||
:::tip
|
||||
PX4 is now adopting more generic and scalable approaches for integrating these kinds of features.
|
||||
For example the [PX4 ROS 2 Interface Library](../ros2/px4_ros2_interface_lib.md) allows complete replacement of PX4 flight modes with enhanced versions written using ROS 2.
|
||||
:::
|
||||
|
||||
This interface allows PX4 to stream a proposed path to a companion computer, and receive back a stream of setpoints that more safely achieves the emitted path, or a mirror of the same stream if the path planning software does not support planning for the current PX4 mode.
|
||||
This enables features such obstacle avoidance in missions and safer landing to be provided by a planner on a companion computer.
|
||||
|
||||
This actual code is still present in code at time of writing (PX4 v1.15).
|
||||
Information about the API and associated features can be found in the [PX4 v1.14 docs](https://docs.px4.io/v1.14/en/computer_vision/path_planning_interface.html).
|
||||
@@ -0,0 +1 @@
|
||||
<Redirect to="../computer_vision/path_planning_interface" />
|
||||
@@ -0,0 +1,176 @@
|
||||
# Visual Inertial Odometry (VIO)
|
||||
|
||||
_Visual Inertial Odometry_ (VIO) is a [computer vision](../computer_vision/index.md) technique used for estimating the 3D _pose_ (local position and orientation) and _velocity_ of a moving vehicle relative to a _local_ starting position.
|
||||
GPS가 없거나 신뢰할 수없는 상황 (예 : 실내 또는 다리 아래에서 비행시)에서 기체 내비게이션용으로 사용됩니다.
|
||||
|
||||
VIO uses [Visual Odometry](https://en.wikipedia.org/wiki/Visual_odometry) to estimate vehicle _pose_ from camera images, combined with inertial measurements from the vehicle IMU (to correct for errors associated with rapid vehicle movement resulting in poor image capture).
|
||||
|
||||
This topic gives guidance on configuring PX4 and a companion computer for a VIO setup.
|
||||
|
||||
:::info
|
||||
The suggested setup uses ROS for routing VIO information to PX4.
|
||||
However, PX4 itself does not care about the source of messages, provided they are provided via the appropriate [MAVLink Interface](../ros/external_position_estimation.md#px4-mavlink-integration).
|
||||
:::
|
||||
|
||||
## Suggested Setup
|
||||
|
||||
A hardware and software setup for VIO is suggested in the sections below as an illustration of how to interface a VIO system with PX4. It makes use of an off-the-shelf tracking camera and a companion computer running ROS.
|
||||
ROS is used to read odometry information from the camera and supply it to PX4.
|
||||
|
||||
An example of a suitable tracking camera is the [Intel® RealSense™ Tracking Camera T265](../peripherals/camera_t265_vio.md).
|
||||
|
||||
### 카메라 장착
|
||||
|
||||
카메라를 보조 컴퓨터에 연결하고 프레임에 장착합니다.
|
||||
|
||||
- 가능하면 렌즈가 아래쪽을 향하도록 카메라를 장착하십시오 (기본값).
|
||||
- Cameras are typically very sensitive to vibration; a soft mounting is recommended (e.g. using vibration isolation foam).
|
||||
|
||||
### Companion Setup
|
||||
|
||||
To setup ROS and PX4:
|
||||
|
||||
- On the companion computer, install and configure [MAVROS](../ros/mavros_installation.md).
|
||||
|
||||
- Implement and run a ROS node to read data from the camera and publish the VIO odometry using MAVROS.
|
||||
- See the [VIO ROS node](#vio_ros_node) section below for details of the requirements for this node.
|
||||
|
||||
- Follow the instructions [below](#ekf2_tuning) for tuning the PX4 EKF2 estimator.
|
||||
|
||||
- 비행 컨트롤러 연결을 확인하십시오.
|
||||
|
||||
:::tip
|
||||
You can use the _QGroundControl_ [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_inspector.html) to verify that you're getting `ODOMETRY` or `VISION_POSITION_ESTIMATE` messages (or check for `HEARTBEAT` messages that have the component id 197 (`MAV_COMP_ID_VISUAL_INERTIAL_ODOMETRY`)).
|
||||
|
||||
:::
|
||||
|
||||
- [Verify that VIO is set up correctly](#verify_estimate) before your first flight!
|
||||
|
||||
<a id="vio_ros_node"></a>
|
||||
|
||||
### ROS VIO node
|
||||
|
||||
In this suggested setup, a ROS node is required to
|
||||
|
||||
1. interface with the chosen camera or sensor hardware,
|
||||
2. produce odometry messages containing the position estimate, which will be sent to PX4 using MAVROS, and
|
||||
3. publish messages to indicate the VIO system status.
|
||||
|
||||
The implementation of the ROS node will be specific to the camera used and will need to be developed to use the interface and drivers appropriate for the camera.
|
||||
|
||||
The odometry messages should be of the type [`nav_msgs/Odometry`](http://docs.ros.org/en/noetic/api/nav_msgs/html/msg/Odometry.html) and published to the topic `/mavros/odometry/out`.
|
||||
|
||||
System status messages of the type [`mavros_msgs/CompanionProcessStatus`](https://github.com/mavlink/mavros/blob/master/mavros_msgs/msg/CompanionProcessStatus.msg) should be published to the topic `/mavros/companion_process/status`. These should identify the component as `MAV_COMP_ID_VISUAL_INERTIAL_ODOMETRY` (197) and indicate the `state` of the system. Recommended status values are:
|
||||
|
||||
- `MAV_STATE_ACTIVE` when the VIO system is functioning as expected,
|
||||
- `MAV_STATE_CRITICAL` when the VIO system is functioning, but with low confidence, and
|
||||
- `MAV_STATE_FLIGHT_TERMINATION` when the system has failed or the estimate confidence is unacceptably low.
|
||||
|
||||
<a id="ekf2_tuning"></a>
|
||||
|
||||
### PX4 튜닝
|
||||
|
||||
EKF2에서 외부 위치 정보를 사용하려면 다음 매개 변수를 설정하여야 합니다.
|
||||
|
||||
| 매개변수 | 외부 위치 추정 설정 |
|
||||
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [EKF2_EV_CTRL](../advanced_config/parameter_reference.md#EKF2_EV_CTRL) | Set _horizontal position fusion_, _vertical vision fusion_, _velocity fusion_, and _yaw fusion_ according to your desired fusion model. |
|
||||
| [EKF2_HGT_REF](../advanced_config/parameter_reference.md#EKF2_HGT_REF) | Set to _Vision_ to use the vision as the reference sensor for altitude estimation. |
|
||||
| [EKF2_EV_DELAY](../advanced_config/parameter_reference.md#EKF2_EV_DELAY) | 측정 타임스탬프와 "실제" 캡처 시간 간의 차이로 설정합니다. For more information see [below](#tuning-EKF2_EV_DELAY). |
|
||||
| [EKF2_EV_POS_X](../advanced_config/parameter_reference.md#EKF2_EV_POS_X), [EKF2_EV_POS_Y](../advanced_config/parameter_reference.md#EKF2_EV_POS_Y), [EKF2_EV_POS_Z](../advanced_config/parameter_reference.md#EKF2_EV_POS_Z) | Set the position of the vision sensor with respect to the vehicle's body frame. |
|
||||
|
||||
These can be set in _QGroundControl_ > **Vehicle Setup > Parameters > EKF2** (remember to reboot the flight controller in order for parameter changes to take effect).
|
||||
|
||||
For more detailed/additional information, see: [Using PX4's Navigation Filter (EKF2) > External Vision System](../advanced_config/tuning_the_ecl_ekf.md#external-vision-system).
|
||||
|
||||
<a id="tuning-EKF2_EV_DELAY"></a>
|
||||
|
||||
#### EKF2_EV_DELAY 튜닝
|
||||
|
||||
[EKF2_EV_DELAY](../advanced_config/parameter_reference.md#EKF2_EV_DELAY) is the _Vision Position Estimator delay relative to IMU measurements_.
|
||||
즉, 비전 시스템 타임스탬프와 IMU 클록 (EKF2의 "기본 클록")에 의해 기록된 "실제" 캡처 시간 간의 차이입니다.
|
||||
|
||||
Technically this can be set to 0 if there is correct timestamping (not just arrival time) and timesync (e.g. NTP) between MoCap and (for example) ROS computers.
|
||||
In reality, this may need some empirical tuning because delays in the communication chain are very setup-specific.
|
||||
It is rare that a system is set up with an entirely synchronised chain!
|
||||
|
||||
IMU 속도와 EV 속도 사이의 오프셋을 확인하여 로그에서 대략적인 지연 추정치를 얻을 수 있습니다.
|
||||
|
||||

|
||||
|
||||
:::info
|
||||
A plot of external data vs. onboard estimate (as above) can be generated using [FlightPlot](../log/flight_log_analysis.md#flightplot) or similar flight analysis tools.
|
||||
:::
|
||||
|
||||
이 값은 동적 기동 중에 가장 낮은 EKF 혁신을 산출하는 값을 찾기 위하여, 매개변수를 변경하여 추가 튜닝할 수 있습니다.
|
||||
|
||||
<a id="verify_estimate"></a>
|
||||
|
||||
## VIO 예상치 확인
|
||||
|
||||
:::info
|
||||
The [MAV_ODOM_LP](../advanced_config/parameter_reference.md#MAV_ODOM_LP) parameter mentioned below was removed in PX4 v1.14.
|
||||
This section needs to be updated. <!-- https://github.com/PX4/PX4-Autopilot/pull/20501#issuecomment-1993788815 -->
|
||||
:::
|
||||
|
||||
Perform the following checks to verify that VIO is working properly _before_ your first flight:
|
||||
|
||||
- Set the PX4 parameter `MAV_ODOM_LP` to `1`.
|
||||
PX4 will then stream back the received external pose as MAVLink [ODOMETRY](https://mavlink.io/en/messages/common.html#ODOMETRY) messages.
|
||||
You can check these MAVLink messages with the _QGroundControl_ [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_inspector.html)
|
||||
- Yaw the vehicle until the quaternion of the `ODOMETRY` message is very close to a unit quaternion (w=1, x=y=z=0).
|
||||
- At this point, the body frame is aligned with the reference frame of the external pose system.
|
||||
- 기체를 구르거나 피칭하지 않고 단위 쿼터니언에 가까운 쿼터니언을 얻을 수 없다면, 여전히 프레임에 피치 또는 롤 오프셋이 있을 수 있습니다.
|
||||
이 경우에는 더 이상 진행하지 말고, 좌표 프레임을 다시 확인하십시오.
|
||||
- Once aligned, you can pick the vehicle up from the ground and you should see the position's z coordinate decrease.
|
||||
Moving the vehicle in the forward direction should increase the position's x coordinate.
|
||||
Moving the vehicle to the right should increase the y coordinate.
|
||||
- Check that linear velocities in the message are expressed in the _FRD_ body frame reference frame.
|
||||
- Set the PX4 parameter `MAV_ODOM_LP` back to 0.
|
||||
PX4 will stop streaming the `ODOMETRY` message back.
|
||||
|
||||
이러한 단계가 유지되면, 첫 번째 비행을 시도할 수 있습니다.
|
||||
|
||||
1. Put the vehicle on the ground and start streaming `ODOMETRY` feedback (as above).
|
||||
스로틀 스틱을 내리고 모터를 작동시키십시오.
|
||||
|
||||
이때 왼쪽 스틱을 가장 낮은 위치에 놓고, 위치 제어로 전환합니다.
|
||||
초록불이 켜져야 합니다.
|
||||
녹색 표시등은 위치 피드백을 사용할 수 있고, 위치 제어가 활성화되었음을 알려줍니다.
|
||||
|
||||
2. 기체가 고도를 유지하도록 스로틀 스틱을 중간(데드 존)에 놓습니다.
|
||||
스틱을 올리면 기준 고도가 증가하고 값을 낮추면 감소합니다.
|
||||
Similarly, the other stick will change the position over the ground.
|
||||
|
||||
3. Increase the value of the throttle stick and the vehicle will take off. Move it back to the middle immediately afterwards.
|
||||
|
||||
4. 기체가 제자리를 유지하는 지 확인하십시오.
|
||||
|
||||
## 문제 해결
|
||||
|
||||
First, make sure MAVROS is able to connect successfully to the flight controller.
|
||||
|
||||
제대로 연결되는 경우 일반적인 문제 해결 방법은 다음과 같습니다.
|
||||
|
||||
- **Problem:** I get drift / flyaways when the drone flies, but not when I carry it around with the props off.
|
||||
|
||||
- If using the [T265](../peripherals/camera_t265_vio.md) try soft-mounting it (this camera is very sensitive to high-frequency vibrations).
|
||||
|
||||
- **Problem:** I get toilet-bowling when VIO is enabled.
|
||||
|
||||
- 카메라의 방향이 시작 파일의 변환과 일치하는 지 확인합니다.
|
||||
Use the _QGroundControl_ [MAVLink Inspector](https://docs.qgroundcontrol.com/master/en/qgc-user-guide/analyze_view/mavlink_inspector.html) to verify that the velocities in the `ODOMETRY` message coming from MAVROS are aligned to the FRD coordinate system.
|
||||
|
||||
- **Problem:** I want to use vision position to do loop closing, and also want to run GPS.
|
||||
- 이문제는 EKF를 혼란스럽게 할 것이기 때문에 정말 어렵습니다.
|
||||
테스트에서 비전 속도를 사용하는 것이 더 안정적입니다 (이 설정을 신뢰할 수있는 방법을 찾으면 알려주십시오).
|
||||
|
||||
## 개발자 정보
|
||||
|
||||
Developers who are interested in extending this implementation (or writing a different one, which might not depend on ROS) should see [Using Vision or Motion Capture Systems for Position Estimation](../ros/external_position_estimation.md).
|
||||
|
||||
이 항목에서는 LPE Estimator (사용되지 않음)와 함께 사용할 VIO를 구성하는 방법도 설명합니다.
|
||||
|
||||
## 추가 정보
|
||||
|
||||
- [Using PX4's Navigation Filter (EKF2) > External Vision System](../advanced_config/tuning_the_ecl_ekf.md#external-vision-system)
|
||||
Reference in New Issue
Block a user