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.

3689686288?profile=original

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.

3689686475?profile=original

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

Github: http://bit.ly/1q3fIvS

Connecting IR-LOCK to Solo: Hackster.io article

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Perhaps, the Pixhawk code doesn't 'agree' with your companion computer and/or controller code. Have you checked if the firmware runs on a standard Pixhawk (i.e., just confirm that it starts up without freezing up)? Also, have you updated your Solo companion computer and controller computer?

    I can't really say anything conclusively. Developing on Solo is still somewhat mysterious.

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

  • 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

    3702220723?profile=original

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

  • @Grant

    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.

  • Developer

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

  • @Grant

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

    http://www.lightware.co.za/shop/en/products/43-sf33tb-50-m.html

    3702217616?profile=original

  • Thanks @LaserDev! Great rangefinders. :)

  • Great work Thomas!

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

This reply was deleted.