GPS-denied Position-hold w/ 3DR Solo

15 Minutes of Vision-based position-hold with 3DR Solo: This is the first iteration of a vision-based position hold controller. This initial implementation is simply a roll/pitch angle PD controller. However, it works surprisingly well after limited tuning.

The video shows a full flight with limited pilot input (during take-off and landing only). During the ~15min flight, the copter autonomously loiters above the beacon placed on the ground. Wind gusts push the copter around, but no pilot corrections were required. Thoughts on controls improvements are included below.

The current system is fully-functional in any lighting condition (night/day) up to altitudes of 15 meters. The system iuses object-recognition, which eliminates position drift over time, enabling GPS-denied autonomous flight for extended periods (i.e., much longer than the battery will last).

FLIGHT LOG FILE:

32.BIN

HARDWARE:

3DR Solo (*disconnected GPS)

IR-LOCK Sensor (*custom-calibrated)

MarkOne Beacon

SF Rangefinder

SOFTWARE:

Modified ArduCopter-Solo Code (post-rebase)

CONTROLS IMPROVEMENTS:

As aforementioned, the current iteration of the controller is simplistic, and is sensitive to wind gusts. The object recognition and rangefinder readings are used as input to the roll/pitch angle PD controller. The controls performance could be improved via more sophisticated sensor fusion and filtering. It should also be noted that this demo includes a custom-calibrated sensor/lens, which we use for particular commercial projects. This calibration should be improve further in future iterations. 

YAW/HEADING ISSUES:

After disconnecting the GPS module and modifying the flight code, the heading state estimated by the flight code drifts in a strangely consistent manner. During the 15 minute flight, the copter slowly makes a 360 degree yaw rotation. This needs to be investigated further (see log file linked above). Perhaps, the issue can be solved with some simple parameter modifications.

Stay tuned for more details and updates by signing up for the IR-LOCK Newsletter: http://eepurl.com/bil0RH

Views: 1985


Moderator
Comment by Roberto Navoni on May 3, 2016 at 12:42pm

@Thomas as i already told to Randy , Philip and other member of the team the real limit is that optical flow is alternative to GPS and you cannot switch from one mdoe Optical flow to GPS and vice versa so could be nice join force to improve this part of ardupilot code. 

best

Roberto 

Comment by Max Patissier on May 3, 2016 at 6:30pm

hola Thomas, we have a very nice project with this kind of function : we need to inspect fire detector inside plants roofs in very high altitude (like 10 meters). I was thinking about using your beacon and put it right below the sensor and ask the drone to get up staying everytime below the beacon, the time to spray a smoke and turn on (or not) the alarm. Am I correct ?

Comment by benbojangles on May 3, 2016 at 7:05pm

was going to say 'why not 'optical flow' but Mr Navoni beat me. Still, I'm sure IR tracking has good uses for perhaps forward loiter tracking, vehicle following?

Comment by Thomas Stone on May 3, 2016 at 7:46pm

@Roberto

Thank you for your efforts to push this development forward, but I am probably not the best guy to add to the optical flow development. The IR-LOCK system is an object recognition and localization system, not a velocity estimation system. I am much more familiar with the former, rather than the latter.

Actually, we would love to add the optical flow sensor to our projects, whenever possible. The extra velocity estimations will be very nice. And we already have the Rangefinder installed (which is also required for optical flow).

@benbojangles

I honestly don't have anything against optical flow, but it doesn't meet the requirements of our current projects. In particular, we need (a) ~zero position drift over extended periods of time and (b) functionality in all lighting conditions.

IR-LOCK is an object recognition and localization system. Optical flow is a velocity estimation system. One approach is not always better than the other. It depends on the application. 

Comment by Thomas Stone on May 3, 2016 at 7:55pm

@Max

That is interesting. I guess it would be possible to invert the system (and code). I am assuming that the ceiling is flat; otherwise, you would need to think about how to estimate the drone's distance from the ceiling.

I should note that this GPS-denied flight code is significantly different than the default Precision Landing/Loiter code. And it is very experimental. 

Comment by Max Patissier on May 4, 2016 at 5:03am

The idea is to use a cheap laser meter to estimate the height and make a mission with one WP.

About inverting the code, we should use take off+loiter instead of land, no ?


Developer
Comment by Randy on May 4, 2016 at 5:13am

Looking good!  the yaw is a bit weird... maybe the RC input is not exactly at the mid point?


Developer
Comment by Randy on May 4, 2016 at 5:18am

Actually I had a quick look at the logs and it's certainly not an RC input issue.  The EKF's yaw estimate is drifting.  Paul Riseborough (if he's got time) might be able to provide some advice.  Alternatively we could try a similar test with master (i.e. disconnect the GPS) and see if it drifts as well.

Comment by Thomas Stone on May 4, 2016 at 8:08am

@Randy

Thanks! Do you know if it safe to run master on Solo? I could port the GPS-denied mods over and give it a try sometime.

Comment by Thomas Stone on May 4, 2016 at 8:14am

@Max

If you are operating without GPS, the code will require significant modifications.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service