terrain following in ardupilot/master

[Andrew Tridgell]

Hi All,

The terrain following code is now in master. Both plane and copter will
communicate with the GCS to fill the terrain database, but only plane
will use the terrain data to follow terrain so far. Rover already has
great terrain following, so it didn't need any changes :-)

There are a few more pieces that need to be filled in on ground
stations:

- ground stations need to respond to TERRAIN_REQUEST messages. A
TERRAIN_REQUEST is a request for a block of 4x4 terrain heights sent
from the vehicle to the GCS. The GCS needs to lookup its terrain
database and send the data back to the vehicle in a TERRAIN_DATA
response.

- ground stations should generate TERRAIN_CHECK messages to ensure the
vehicle has terrain data needed for a mission. The vehicle will send
a TERRAIN_REPORT in response. If the grid_spacing in the
TERRAIN_REPORT is zero then the vehicle doesn't yet have data for
that location. The vehicle will automatically start to pull data from
the GCS for that location with TERRAIN_REQUEST messages

- ground stations should add the ability to generate terrain following
mission items, by setting the frame type of the mission item to
MAV_FRAME_GLOBAL_TERRAIN_ALT

- ground stations should show terrain subsystem status, using the
MAV_SYS_STATUS_TERRAIN health bits in SYS_STATUS

I've done a new release of MAVProxy with all these elements done, so we
can test terrain following now in SITL for plane. To test with mavproxy
use:

set terrainalt 1

that will tell mavproxy to create mission items as
MAV_FRAME_GLOBAL_TERRAIN_ALT.

You should also set the parameter TERRAIN_FOLLOW:

param set TERRAIN_FOLLOW 1

that tells APM:Plane to use terrain altitude for RTL, CRUISE and
FBWB. Use of terrain altitude for mission items and guided mode is
controlled by the frame type in the mission item.

Note that terrain following is not available on APM1/APM2. Attempting to
upload a terrain mission on APM1/APM2 will fail.

Right now terrain following doesn't do any lookahead. This means it can
fly into the ground if the slope is greater than the climb rate the
plane can achieve. We can fix that by adding spiral climbs, but that
hasn't been done yet.

Cheers, Tridge

[Marco Robustini]

Wow, thanks mate for this great improvement!

Marco

[Andrew Tridgell]

I did my first successful flight tests today of terrain following in a
real aircraft (up to now it has all been SITL testing). It worked very
nicely, although it wasn't all that challenging as the area around my
flying field is quite flat.

I'm also considering making TERRAIN_ENABLE default to 1. Right now it
defaults to zero.

Setting it to 1 means the vehicle starts to ask the GCS for terrain data
and stores it on the SD card. It doesn't mean it actually does any
terrain following, just that it builds a terrain database and is able to
start doing missions with terrain height frames if you ask it to. It
would also start reporting terrain height information in the tlog.

To make RTL, CRUISE, FBWB etc start doing terrain following you also
need to set TERRAIN_FOLLOW=1. To make AUTO use terrain following you
need to create your waypoints with a TERRAIN_ALT frame type (frame type
10).

Cheers, Tridge

[Tom Coyle]

Hi Tridge,

Nice work!!!

I may have to get back into autonomous planes again:-)

Regards,

Tom C ArduRover2 Developer

[Arthur Benemann]

Really nice Tridge!

I coded a SRTM library in Java, but have  not made any use of it up to now.

I'll add this to my queue in DroidPlanner. 

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Arthur Benemann

Engineer

3D Robotics

[Andreas Kräuchi]

Wow thx a lot it works really nice!!!!

Is it possible to force MissionPlaner to send all terrain data for an area of for example 20 by 20km?

On the SD card is quite some space available this should be possible or does the code have

problem looking though all the data to get the info needed?

Andy

[Andrew Tridgell]

Hi Andreas,

> Is it possible to force MissionPlaner to send all terrain data for an area
> of for example 20 by 20km?

You can just create (and upload) a mission or some rally points that
covers that area. Whenever the mission changes or new rally points are
added the autopilot will automatically ask for all terrain data for each
point.

With the default grid size just add a mission waypoint every 2km and you
should cover the whole area. You can do that with the auto-grid
functions in MissionPlanner.

Cheers, Tridge

[Andreas Kräuchi]

Ok thats a good way around :) Thx will try that and test it in SITL for plane.

Andy

[Andreas Kräuchi]

It works, nice!

Last thing :)

I tried to load for example the "N46E004.DAT" that gets stored on the SD-Card with matlab however I just

got some strange values and they didn't make sense.

Can you tell me how the terrain data is stored or how I can read them back (like to analyse all the points already

stored on the card).

Andy

Am Freitag, 19. September 2014 08:00:29 UTC+2 schrieb Andrew Tridgell:

[Andrew Tridgell]

Hi Andreas,

> Can you tell me how the terrain data is stored or how I can read them back
> (like to analyse all the points already
> stored on the card).

It is an ardupilot specific format. The intention is that it not be
parsed by code outside of ardupilot.

If you really want to learn to parse it then the code is here:

https://github.com/diydrones/ardupilot/tree/master/libraries/AP_Terrain

but be warned that it is not a standard format.

Cheers, Tridge

[Andreas Kräuchi]

Yes I already looked into the code of AP_Terrain however I'm probably a bit too silly to 

understand how it gets stored.

My second intention was to write a matlab script that puts all the terrain data for a specific

region into the *:DAT file which then can be stored on the SD card that way I know for 100%

that I got the terrain data I really need. Since for my project this is going to be quite essential.

Andy

[Andrew Tridgell]

> My second intention was to write a matlab script that puts all the
> terrain data for a specific region into the *:DAT file which then can
> be stored on the SD card that way I know for 100% that I got the
> terrain data I really need. Since for my project this is going to be
> quite essential.

It would be a lot easier to modify the C++ code in AP_Terrain and make
it into a standalone program.

Cheers, Tridge