Solo Smart Drone Lands Smartly: PART 2

Our precision landing Solo is flying great! :) This test rig has an IR-LOCK sensor (via I2C), an SF/10A rangefinder (via Serial), and is running a customized precision landing firmware based on APM:Copter (solo-rebase). The video above shows two vision-guided landings. The full 10-landing test sequence is shown below. The typical landing accuracy ranges from 0-10cm, even in moderate/gusty wind.

One of the primary challenges of designing a precision landing UAV system is the controls tuning. Every UAV has different flight characteristics, and finding the right PID (+EKF) parameters can be a painstaking process. So it is very helpful to have a popular, consistent hardware platform (e.g., Solo) to develop on. Solo flies nicely out of the box without significant parameter modifications. The precision landing performance is noticeably better than our IRIS+ platform, and our previous Solo test platform (w/out a laser rangefinder). In the 10-landing test sequence, the typical landing accuracy ranged from ~0-10cm. There was only one ‘failure’ (landing #5 out of 10), in which the copter landed far outside of the specified bounds. This will be analyzed and corrected via the controls code.

This test platform is running a customized precision landing firmware, which uses the vision-based localization data to actively manage the landing accuracy. You can read more about the code, and see previous testing here. USER BEWARE: this code is experimental, and it assumes that you have a reliable rangefinder connected. 

Customized Firmware: ArduCopter-v2.px4


Connecting IR-LOCK to Solo: article

Views: 2000

Comment by Grant Morphett on March 31, 2016 at 4:03pm

Its looking great.  Is the rangefinder installed and configured into the copter in the standard way or is your modified code somehow making use of the rangefinder information to more accurately land and extra configuration steps required?  Or is it just an overall advantage as you get much more accurate altitude information from the rangefinder?

One scenario that concerns me is platform landing.  I've seen some designs where they have the copter landing on a raised platform - think 1.5m off the ground but only 1x1m landing area.  I am wondering what happens when the copter is "blown" slightly off the landing approach and the rangefinder suddenly see's an extra 1.5m of altitude.

Thanks, Grant.

Comment by Thomas Stone on March 31, 2016 at 5:06pm

Thanks, Grant. 

The accurate AGL altitude information from the rangefinder is very important when determining the relative location of the copter. i.e., the copter knows how many cm off-course it is from the visual target. This localization information is used to adjust the climb/descent rate if the landing is off-course.

Our previous copter made more aggressive maneuvers (video link), which is a better visual demonstration. 

Yes, there are quite a few 'land on box' projects. The flight control code can also handle these situations (although, the linked code is admittedly basic). When the copter is high (3+ meters), the accuracy criteria is relaxed. As the copter enters the ~0-2 meter altitude range, the copter must stay within a specified distance from the target, or it will ascend and re-try the landing.

If the rangefinder suddenly gives a 'bad' (+1.5m) reading, this will also cause the localization info to be 'bad' (i.e., outside of the specified distance from the visual target), and the copter will ascend and re-try the landing. Also, the copter can ascend if the visual target is out of view. 

Comment by Laser Developer on April 1, 2016 at 12:06am

Great work Thomas!

Comment by Thomas Stone on April 1, 2016 at 6:32pm

Thanks @LaserDev! Great rangefinders. :)

Comment by Thomas Stone on April 1, 2016 at 6:37pm


Also, this multi-beam rangefinder could help with 'land on box' problems. :)

Comment by Grant Morphett on April 4, 2016 at 3:25am

@Thomas - are you thinking we could add code to detect the "edge" of a platform i.e. one of the corners of the triangle pattern registers 1.5 meters longer so you infer which way the platform probably was?

Thanks, Grant.

Comment by Thomas Stone on April 4, 2016 at 8:06am


Not exactly. I think it would be a more reliable way to determine the AGL altitude above a 'box'. I would still use the IR-LOCK sensor for determining an accurate angle-to-IR-target. We use the AGL altitude and angle-to-target to accurately determine the location of the copter relative to the target.

This is what we demonstrated in the video, but we used a single-beam rangefinder, and the landing area was flat. For 'landing on a box', the multi-beam rangefinder could provide better AGL altitude info.

Comment by John carff on April 7, 2016 at 8:15am

I was wondering if anyone has tried to upload this new firmware to their solo drone( besides Thomas ;) )? I have now attempted with 2 of my solos and both are bricked. the first one I though was just a fluke, but the second one has now done the same thing. I upload the firmware, restart the drone, and it goes into update mode doing the rainbow arms for ever, the first time I waited about 20 minutes and then turned off the drone, hoping to just try again, but after restarting I could never get a connection to the drone and the arm lights stayed a constant green. factory reset never worked either. My second drone is now stuck in rainbow mode and I have left it there for there for 30 minutes now. I have uploaded custom firmware before without any problems, any suggestions?

Comment by Thomas Stone on April 7, 2016 at 8:41am

Hi John, 

I have 'bricked' and un-bricked multiple Solos many times. All of them are currently working. :) ... I don't know any other people who are editing Solo autopilot code (maybe there are a few on the dev forum). 

To be honest, developing customized autopilot code for Solo has been a bit of a hassle. There are three separate hardware/software units that must sync up for everything to work properly: the Solo companion computer, the Pixhawk2, and the controller computer. 

I always use the NuttX Shell terminal (NSH) to see exactly what is going on at startup. So my development procedure is as follows:

(1) Upload code to standard Pixhawk, and observe NSH output during startup. If there is an issue, the problem is obviously caused by the compiled autopilot code (and/or attached peripherals).  

(2) If Step 1 works, then I upload the code to Solo's Pixhawk2, and observe the NSH output during startup.

(*) If Step 2 fails, then there is probably an issue with the '3 system compatibility' (mentioned above). This issue is difficult to diagnose. The best solution is to use the latest versions of all available software.

... I guess I was properly warned

Comment by John carff on April 7, 2016 at 1:22pm

I was able to unbrick my solos, i will let you know if i get this working, i have some stuff in the works using IRLock i think you will like.


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

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service