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?
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?
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.
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 ?
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.
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
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.