Object Avoidance

So, not sure where to post this, as it could apply to all branches, so here goes.

Object avoidance…

I have been looking at some of the work that has been done lately, and it seems most of it has the sensors directly connected to the flight controller. Has there been any work done using multiple sensors connected to a companion computer? is there provisions in the ardupilot code to accept object data from a companion?

1 Like

The object avoidance code has a MAVLink backend: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Proximity/AP_Proximity_MAV.cpp

You send DISTANCE_SENSOR messages to the board running ArduPilot and it will use that information to do the avoidance.

Also, work is starting now to get more external information into ArduPilot.


Not long after I posted the question I found Randy’s post and link to the MAVLink data and the DISTANCE_SENSOR messages. Thanks!

What other work on external information, and where to read about this?


There’s nothing to read or show yet (as far as I know). Paul (our EKF master) is working to external position estimation into ArduPilot (so you can, for example, have a camera connected to a companion computer providing a position estimate). Also, Randy has continued to work on object avoidance - his next steps are to get more obstacle information in a companion computer (a map of obstacles for example, instead of relying on just what the sensors are providing in the moment).

Hi John and Francisco,
I’m developing a basic object detection algorithm with a Companion Computer (RPi2) connected to a quad running Copter 3.3.3 (VRBrain FC). I have a proximity sensor (Lidar Lite v1) connected to RPi and would like to send MAV message “DISTANCE_SENSOR” to arducopter (using dronecopter api running python), may you help me in implementing it?

thanks a lot :slight_smile:

Hey Rusty,

My team have just released the following project: [Announcement] Obstacle Avoidance Framework

It may be helpful for your case to experiment with different approaches before trying on a drone. As we can see we are still restrict about the number of sensors available, but that is something should be easy to add to fulfill your needs. We have a tutorial about that here and soon we will release some video demonstrations of the project working on both: simulated environment and on a real drone.

Feedbacks are welcome!


I am working on integrating the OGN-Tracker with the drones, so I wonder if I send messages to the autopilot and other aircrafts on a close track would the auto-pilot already react by avoiding them ?


Actualy ardupilot will stop before to hit obstacle but is not able to avoid it.

Stop is fine for copter but would the plane do ?

This is already something: in a situation when say a copter is flying and then a glider gets on a conflicting path, the copter stopping would most likely avoid the collision. Would the copter resume its mission afterwards, when the thread is gone ?

I guess in general you need quite an intelligent behavior to properly handle such situations, but it would be good to push this topis as collision between drones and small aircrafts do happen already and the drone can already be equipped with receiver(s) to sense such traffic. if the autopilot would be able to react properly, the drones would not be perceived as a thread anymore.

The ADSB-Avoid functionality might be worth looking into. It’s behaviour is quite different to object avoid.

Is this functionality already there ? How is the interface done between the ADS-B receiver and the auto-pilot ?

I think @MagicRuB is the author by the way.

I can see this article: http://ardupilot.org/copter/docs/common-ads-b-receiver.html
It says “The avoidance features are still under development and should be used with caution. They may not yet be useful for real-life manned vehicle avoidance.” - does this hold for today ?

I understand the traffic receiver should send messages ADSB_VEHICLE, correct ?
The message COLLISION is made by the auto-pilot, correct ?
I read after: http://mavlink.org/messages/common

that page in the wiki hasn’t been updated for a while. Matternet are using arducopter with flarm, by the way.

I know about the Matternet, I helped them a bit to setup the OGN receiver, but they can’t reveal details about their software.

I am researching ArduPilot because this is what I am able to do myself and sources, protocols, etc. are open.

So the question is: when I install an OGN-Tracker with an ArduCopter and it would send the ADSB_VEHICLE message to the autopilot, would autopilot respond ?

The COLLISION message is not clear to me: it is the autopilot who makes it or the receiver must produce it ?

Autopilot. The code doesn’t actually care whether you have a receiver, or are getting messages forwarded from a gcs linked to flightradar, for instance.

OK, so I assume the autopilot runs the algorithm which watches for objects on a potentially conflicting path.
Do you have an idea how much traffic can it take ?
The question is whether to give it all the traffic being received or preselect the data avoiding object obviously out of conflict range ?
There can be quite an amount of traffic especially on ADB-S.

I can see the ADSB_VEHICLE has the field “tslc” where you indirectly give the time to which the given position corresponds ? I assume this is the delay between the time “now” and the time the position was measured by the other object ?

I really need to defer to Tom (@magicrub), but setting the appropriate parameters tells the flight code which detections to consider. Not sure what the data type is, and hence maximum number (will be in the code though, obviously).



Hi there! Yes, it will avoid an ADSB_VEHICLE object that is detected from the on-board ADSB receiver or from a GCS/companionComp feeding it those packets. Note, for routing purposes it’s helpful to send a heartbeat on all the MAVLink paths that you’d like MAVLink packets to get routed on.

It says “[blah blah its test code blah blah use at your own risk blah blah]” - does this hold for today ?

Several of the devs and other customer have tested it plenty but I’d hate for someone to fly into another aircraft and blame us. Think of it as a liability.

Do you have an idea how much traffic can it take ? The question is whether to give it all the traffic being received or preselect the data avoiding object obviously out of conflict range?

Here’s a quick tour of some of the [ADS-B params] (Complete Parameter List — Plane documentation) specifically made to address this problem:
ADSB_LIST_MAX - limit the memory to this count of the closest ones
ADSB_LIST_RADIUS - also ignore aircraft outside this radius
SRx_ADSB - broadcast the entire stored vehicle list at this rate.