Collision Prevention
Last updated
Last updated
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 in , 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). :::
Collision Prevention is enabled on PX4 by setting the parameter for minimum allowed approach distance ().
The feature requires obstacle information from an external system (sent using the MAVLink message) and/or a connected to the flight controller.
:::note Multiple sensors can be used to get information about, and prevent collisions with, objects around the vehicle. If multiple sources supply data for the same orientation, the system uses the data that reports the smallest distance to an object. :::
The vehicle restricts the maximum velocity in order to slow down as it gets closer to obstacles, and will stop movement when it reaches the minimum allowed separation. In order to move away from (or parallel to) an obstacle, the user must command the vehicle to move toward a setpoint that does not bring the vehicle closer to the obstacle. 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 . If you are using a companion computer to provide obstacle information see .
Configure collision prevention by in QGroundControl:
Set the minimum allowed distance (the closest distance that the vehicle can approach the obstacle). Set negative to disable collision prevention. > Warning This value is the distance to the sensors, not the outside of your vehicle or propellers. Be sure to leave a safe margin!
Set to 1 to allow the vehicle to move in directions where there is no sensor coverage (default is 0/False).
Set to 0 or 3 to enable Collision Prevention in Position Mode (default is 4).
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. If so, the vehicle velocity is restricted.
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.
The sensor delay for distance sensors connected directly to the flight controller can be assumed to be 0. For external vision-based systems the sensor delay may be as high as 0.2s.
:::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. :::
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. From testing, 30 degrees is a good balance, although different vehicles may have different requirements.
:::note 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. :::
Other sensors may be enabled, but this requires modification of driver code to set the sensor orientation and field of view.
Modify the driver to set the orientation. 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).
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.
:::note 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. :::
Set the sensor and velocity setpoint tracking delay. See below.
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 below.
This velocity restriction takes into account both the inner velocity loop tuned by , as well as the via and . The velocity is restricted such that the vehicle will stop in time to maintain the distance specified in . The range of the sensors for each sector is also taken into account, limiting the velocity via the same mechanism.
:::note 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 to 1. :::
Delay, both in the vehicle tracking velocity setpoints and in receiving sensor data from external sources, is conservatively estimated via the parameter. This should be 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 . This helps to fine-tune user input to 'guide' the vehicle around obstacles rather than getting stuck against them.
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 . If you want the vehicle to be able to move again, you will need to disable Collision Prevention by either setting the parameter to a negative value, or switching to a mode other than (e.g. to Altitude mode or Stabilized mode).
:::warning Be careful when enabling , 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. :::
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 parameter.
Vehicle velocity setpoint tracking delay can be measured by flying at full speed in , then commanding a stop. The delay between the actual velocity and the velocity setpoint can then be measured from the logs. The tracking delay is typically between 0.1 and 0.5 seconds, depending on vehicle size and tuning.
Depending on the vehicle, type of environment and pilot skill different amounts of guidance may be desired. Setting the parameter to 0 will disable the guidance, resulting in the vehicle only moving exactly in the directions commanded. Increasing this parameter will let the vehicle choose optimal directions to avoid obstacles, making it easier to fly through tight gaps and to keep the minimum distance exactly while going around objects.
At time of writing PX4 allows you to use the IR distance sensor for collision prevention "out of the box", with minimal additional configuration:
First , and enable collision prevention (as described above, using ).
Set the sensor orientation using .
Attach and configure the distance sensor on a particular port (see ) and enable collision prevention using .
:::tip You can see the required modifications from the . Please contribute back your changes! :::
If using a companion computer or external sensor, it needs to supply a stream of messages, which should reflect when and where obstacle were detected.
The tested companion software is the local_planner from the repo. For more information on hardware and software setup see: .
The hardware and software should be set up as described in the repo. In order to emit OBSTACLE_DISTANCE messages you must use the rqt_reconfigure tool and set the parameter send_obstacles_fcu to true.
Collision Prevention can also be tested using Gazebo. See for setup instructions.