Developer

Lidar landing with APM:Plane

Over the last couple of days I have been testing the Lidar based auto-landing code that will be in the upcoming 3.1.1 release of APM:Plane. I'm delighted to say that it has gone very well!

Testing has been done on two planes - one is a Meridian sports plane with a OS46 Nitro motor. That is a tricycle undercarriage, so has very easy ground steering. The tests today were with the larger VQ Porter 2.7m tail-dragger with a DLE-35 petrol motor. That has a lot of equipment on board for the CanberraUAV OBC entry, so it weighs 14kg at takeoff making it a much more difficult plane to land well.

The Lidar is a SF/02 from LightWare, a really nice laser rangefinder that works nicely with Pixhawk. It has a 40m range, which is great for landing, allowing the plane plenty of time to lock onto the glide slope in the landing approach.

APM:Plane has supported these Lidars and other rangefinders for a while, but until now has not been able to use them for landing. Instead they were just being logged to the microSD card, but not actively used. After some very useful discussions with Paul Riseborough we now have the Lidar properly integrated into the landing code.

The test flights today were an auto-takeoff (with automatic ground steering), a quick auto-circuit then an automatic landing. The first landing went long as I'd forgotten to drop THR_MIN down to zero (I normally have it at 20% to ensure the engine stays at a reasonable level during auto flight). After fixing that we got a series of good auto flights.

The flight was flown with a 4 second flare time, which is probably a bit long as it allowed the plane to lose too much speed on the final part of the flare. That is why it bounces a bit as it starts losing height. I'll try with a bit shorter flare time tomorrow.

Here is the video of one of the Meridian flights yesterday. Sorry for missing part of the flight, the video was shot with a cell phone by a friend at the field.

Here is another video of the Porter flying today, but taken from the north of the runway

I'd like to thank Charles Wannop from Flying Finish Productions for the video of the Porter today with help from Darrell Burkey.

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Developer

    @Gray,

    Right now we don't account for terrain changes on landing approach. Small changes like drainage ditches won't be a problem as it does do some smoothing on the barometric->terrain correction value, but larger depressions will indeed make a big difference.

    If the depression is big enough to show up in the SRTM terrain database then we could account for it using SRTM corrections (we don't do that yet though). If it's too small in size for that then we'd either need the pilot to setup an adjustment in the mission, or we'd need two rangefinders, one at 45 degrees in front and one straight down.

    You are right that this is a real effect. The strip I've been using for testing has about a 4m dip on the Northern approach. The first landing came up short as it went down into this dip, then flared too early as the ground rose up. I just shifted the landing point a few meters along the runway to fix that (which meant the dip happened at a higher altitude, so it could handle it fine).

    Cheers, Tridge

  • Andrew,

    How are you accounting for ditches or other depressions on approach?  The sonar is measuring the height above ground and say there is a drainage ditch or similar at end of the runway - suddenly the height above ground as measured by the sonar will jump.  Are you doing a smoothing algorithm or using the sonar to backup the barometer readings?

    How could we account for the extreme of this - for instance landing on an aircraft carrier - would we need to enter the height of the landing runway above the ground?

    Gray Pritchett

  • Developer

    @Jack, plenty of things do go wrong, I just don't tend to write posts about them! For some photos of plane carnage see our photo site

    @ausdroid, the code flown in these videos is in ardupilot git master now. I'll probably do a new release in a few weeks time. The SF/02 is connected to the 3.3V analog port on the Pixhawk, and is getting its power from that port (it's the 5 pin DF13 port).

    @chris, just two GPS modules and the EKF. For the takeoff and final part of landing it just uses a summed gyro to hold constant heading

  • Excellent development Andrew, what do you use to line up the porter on the runway, GPS? How accurate is that??
  • Hi Joe and Gisela

    What about you? 66kgs is a big machine.. Is it still a tailwheel?

  • Sorry, I see your point. Didn't clarify that very well did I? Getting a aircraft both off the ground and back again down is the hardest part. Not least with a tail dragger that wants to ground loop. But hate giving a draggy nose wheel a free ride everywhere. So code just for tailwheel aircraft is even better. This is very impressive.

  • Dumb question, I'm sure...but how does auto-landing relate to catapult launch?

  • Great work Andrew. Looking forward to using this as it is quicker/safer than a catapult lunch. in fact some OHAS forbid the use of stored energy in catapults. This is the way forward. When will we be able to test it?

  • Andrew,

    When will the release of 3.1.1 be available.

    Also, how are you powering the lightwave?

    AUS

  • Does anything not go very well?

This reply was deleted.