I was planning a mission in an area which either has no SRTM elevation data or bad (i.e. all elevations are 0m) data. When attempting to use the 'verify height' option while creating waypoints, everything is referenced to the missing/bad SRTM data. Looking at the elevation graph, there is good Google Earth (GE) data. Can I switch to using Google Earth elevations for 'verify height' and terrain following somehow? Perhaps this is something obvious I've overlooked.
Yes, thats right, give it a go, its a pretty cool feature to see your plane fly up and down over the hills autonomously!!
It would be cool if it worked in Alt Hold mode as well :)
Have a read through this page http://plane.ardupilot.com/wiki/common-planning-a-mission-with-wayp..., it explains really well where the data's coming from and how its loaded onto the SD card.
I've been thinking about this lately because I built my plane for efficiency, so it only climbs at a maximum of 7 degrees, but with a lookahead of 2000m, its really unlikely I would never clear a hill (in Australia anyway).
Tridge wrote the code (I'm pretty sure), I'd say he got the idea from NASA, their UAV's have preloaded the global SRTM. They're a bit more sophisticated though because they'll turn around if they know they're not going to clear the hill, I don't think ardupilot does that.
Yes, thats very interesting, that there's a difference. It appears that the google earth file has been either filtered or the grid they use, that this profiles been sampled from is at a lower resolution than the SRTM data.
The most SRTM data is off around the whole world is 16m (probably near the poles or himilayas), generally its only a few metres.
If you have the ublox 8 or 7 its good to about 5m vertically, if you can sit it on the ground on one of these locations and record for an hour or two in a position that won't have multipathing problems, you should be able to work out quite definitively which one is correct, my money would be on SRTM. I've flown draping the terrain at 30m altitude and the SRTM worked really well.
Ardupilot and google use the exact same source, 3 second SRTM data, so if there are differences, something has gone wrong, which you want to be careful of if you're using terrain following for avoiding crashing into hills etc. If you're flying over a water body though there will be a difference because SRTM data is void in those places.
Figured this one out.
Missing data for much of Alaska (and similar latitudes in other places) for the SRTM version in the available repositories.
Get the files yerself! For example, a mission to be planned at N64.5 W165.5 requires downloading the SRTM file N64W166.hgt.zip (identified by lower left corner of specific area), and unzipping it in the Mission Planner\srtm directory. NOW height-related functions (terrain and relative+verify) work.
You should have 30m resolution SRTM too, which is quite accurate to a few metres.
Yes, it looks like the MP code supports both 1 second and 3 second formats. I tested it with 1 second (the only resolution which mission planner grabs automatically for areas where data is available) and everything worked fine. I don't necessarily need the high resolution, however it more than satisfies my criteria for coarse "hill following" and just generally enables the use of terrain functions of mission planning.
Google earth uses SRTM data, which is what ardupilot uses, its the same data source.
I thought something like that to be the case. However, when looking at the elevation profile of a planned flight, the SRTM profile is flat (nothing there), and the GE profile shows a reasonable, if sparse, profile. I'm not really concerned with the origin of the data itself, just that Mission Planner isn't finding the data it's looking for. The real problem is that using the "Verify Height" feature is useless without the SRTM dataset.
The Elevation Profile window even gives a warning about GE data being at 100m intervals, including "You use this at your own risk." I'd like to use it, but I haven't figured out how to, short of coding it to do so manually.