I heard that perhaps some measure of collision avoidance was built into the latest Arducopter build... Is this true? I know of the Altitude Hold mode terrain follower but this does not prevent forward/side/rear/top collision... Has anything been done in that arena yet?
Marc
Replies
Hi all,
I am also currently trying to implement some form of obstacle avoidance by using either ultrasonic sensors or IR sensors. Does any one have any luck with those yet?
The code in Arducopter RC2 code looks fine to implement. Is that right?
Obstacle avoidance on Arducopter : https://www.youtube.com/embed/BFMt7YJciDs
With Kinect hack : https://www.youtube.com/embed/eWmVrfjDCyw
Interesting. I've been thinking of doing this by having a separate Arduino acting as a sensor decoder/multiplexor/thinker.
The idea being that the collision avoidance/"where am I?" low-level stuff is handled by a dedicated processor which communicates with the APM using some sort of opto-isolated input/output encoding with a simple deterministic protocol.
Advantage of this is that I can use whatever makes most sense for the sensors (PWM, chaining, individual hookups...) without risking hanging the APM main loop. Also I can add additinal sensors that may be more processor-intense without impact.
Disadvantage is the cost of a second CPU (power consumption, weight) and code complexity.
I'll add a module to the APM code which decodes that protocol and uses some sort of PID-related logic to move away from the obstruction. Will use two lines (maybe three); the first is a simple "interrupt assert" line which will tell the APM to read the sensor data. So if that line stays low (eg if my Sensor processor is busy/halted/on-fire) the APM will work as normal. Otherwise it will read the data from the other line and "do the right thing".
Other things I need are the ability to log the sensor traffic, and some way of controlling/tweaking the sensor processor. I suppose if I use my spare APM
This getting interesting now that you have a prototype to test sonar sensors & routines with. What range is expected?
Will there be time for emergency maneuvers?
I have 3 ports for I2C on my APMs, I use 4 swiss pin sockets on top and bottom of APM, now I use Mag Compass on top port but only on bench, compass is mounted for best performance on plane with 12' cable, away from magnets, metal, & ESC power lines.
I have several sonar sensors from a recycled power management system that turns of lights when no one is in hall /room, I hoped to hack them for this someday, It is made for ceiling mount, Sensors are mounted as a pair at a 30° angle slightly downward. Manual shows range of 30' or a bit more.
A few days back Leon posted a blog post which showed his aircraft with multiple sonar sensors on a nice custom designed board
His website with more pictures etc is here
Looks like he is using SRF02 sensors - I2C devices that would not require extra analog pins. Specs say you can use upto 16 sensors . More info here
regards
Andrew
So i should add, theoretically very possible and I'd be happy to talk someone through the code changes required but it'll likely be a couple of months before I get around to doing it myself (no promises sorry!).
Marc,
No, it's not done in the ACM code. I did some work on getting it working in the old ArduCopterNG code but hit a somewhat fundamental problem that if you have more than 1 sonar they interfere with each other. I looked into using IR Sensors (also supported by the AP_RangeFinder library) but found their range (1.5 meters) is far too short and their beam is too narrow for a full size quad.
Since then, i've learned the solution is to make use of the maxbotix sensor's RX pins. We could connect each sonar's RX pin to a separate spare pin on the APM and then deliver separated pulses of over 20nano seconds spaced 200ms apart and they would probably all work beautifully. The object avoidance code from NG would also need to be ported over to ACM but that's less of an issue.
Description of the RX pin from sonar's datasheet:
RX – This pin is internally pulled high. The EZ0™ will continually
measure range and output if RX data is left unconnected or held high.
If held low the EZ0™ will stop ranging. Bring high for 20uS or more
to command a range reading.