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

  • I just 'un-bricked' a Solo, and honestly couldn't explain exactly what I did. I performed at least one factory reset, and I also uploaded a default firmware to the Solo computer.... among other things. 

    John is correct that the solid green lights might indicate that the IR-LOCK Sensor is not detected on the I2C bus. For some reason, this causes an error during driver initialization on Pixhawk2, instead of simply skipping it. 

    This (below) shows a startup with the sensor connected (via NuttX Shell (NSH)).

     

    3702264354?profile=original

  • @Savannah

    Which firmware (Pixhawk2) do you have uploaded currently? Also, do you have an IR-LOCK Sensor connected on the I2C bus#1 (w/ magnetometer)?

  • @Savannah

    This is Thomas from IR-LOCK. 

    Here is our preferred setup/hardware/code for precision landing with Solo: link. It is fairly easy for us to setup a Solo/IR-LOCK (now). But when we got started with Solo, debugging was a pain. 

    Also, we will eventually transition to the standard ArduCopter repository (i.e., ArduCopter3.4).

    Wibotic Charging Project
    Wibotic Automated Solo Charging Project June 2016 IR-LOCK, LLC IMPORTANT NOTES: Do NOT install firmware on IR-LOCK sensor. Customized firmwa…
  • First try this, there is another small button in the gimbal bay. Turn off the drone, hold down the button in the gimbal bay while you turn the drone back on... after a series of about 3 tone groups. let go and see if the drone will boot up and connect to the remote. latley this has worked for me. if that doesnt work i can go through the other process. Are you trying to setup the IRLock. If so i found that the reason it bricks is because it doesn't detect the irlock.

  • Yes, there could be a error in the code when it tries to search on bus 2. For some reason, the solo-rebase no longer includes any explicit references to bus 2 in its APM init file. I don't have time to work on it right now, but I am pretty sure something needs to change here. 

    https://github.com/ThomasSFL/solo-reb/blob/0e1c7707a05d3b141cbb2815...

    ThomasSFL/solo-reb
    Contribute to ThomasSFL/solo-reb development by creating an account on GitHub.
  • i will check things out on Monday. Thanks for the help. first thing I will try is using i2C bus 1. Say I didn't have anything hook up, no pixy and no rangefinder, could that cause a problem because it is "looking" for them. The first drone I tried on had the rangefinder on serial2 and the pixy on i2C bus 2. the second drone I tried it on was a fresh drone that has never been modified, I simply uploaded the code and same effect. Thanks for the help.

  • Also, this is really 'in the weeds', but I should note that this test had the IR-LOCK sensor connected via I2C bus 1 (i.e., shared with the magnetometer). The bus 2 sensor startup has not been tested with this rebased version of the code, and maybe it is causing a failure at startup for you. 

    Bus 1 Connection: http://diydrones.com/profiles/blogs/solo-smart-drone-lands-smartly

    I have added these notes in a release on Github. 

    https://github.com/ThomasSFL/solo-reb/releases/tag/v1.0.0-PL01

  • 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

This reply was deleted.