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:
HARDWARE:
3DR Solo (*disconnected GPS)
IR-LOCK Sensor (*custom-calibrated)
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
Comments
@Ian
Sorry for the late reply. I have been quite busy lately.
We (IR-LOCK) have investigated position hold solutions for ~30 meters. I think we could handle 30 meter position hold with minimal modifications to the sensor/beacon hardware.
However, 50-80 meters is pushing the limits when using this position hold strategy. Here are the primary issues:
The sensor data is used to calculate an approximate angle-to-target measurement. The angle-to-target, altitude, attitude measurements are used to compute the relative position of the copter. We can modify the lens and beacon to increase the detection range. However, at the larger range, the error in the angle-to-target measurements increases. This error can be mitigated by carefully calibrating the sensor/lens combination. However, I am not sure if the error can be sufficiently mitigated at 50-80 meters. Also, at this altitude, it is more likely that the rangefinder will detect 'obstacles' on the ground, which produce an error in the altitude-to-beacon reading.
I hope this is helpful. (thomas@irlock.com)
@Ian - are you looking for collision avoidance, position hold or absolute location?
There are a few options. But, it needs an absolute position fix based on something. So, it either has be able to see the ground. Or could use Lidar. Or there's a few people working on an RF technology, which is basically like a private GPS system. It requires the user to place a few Rf beacons around the area.
I am interested in the GPS denied enviroments, although we need to be above 10 M more like 50-80M. Is there any solutions to that people know of
@Max
If you are operating without GPS, the code will require significant modifications.
@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.
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.
Looking good! the yaw is a bit weird... maybe the RC input is not exactly at the mid point?
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 ?
@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.
-
1
-
2
of 2 Next