We have found and fixed serious errors in the terrain data supplied by the ArduPilot terrain data server at https://terrain.ardupilot.org. As an example the images above show the terrain height for the SRTM3 downloadable DAT files for an area in New Zealand. The image above on the left is the correct terrain heights, with red being higher, blue is lower and black is sea level. The image on the right is what we previously have for a bulk download of terrain data for this location, and you can see that a lot of it is showing as ocean when in fact it is land around 200m high. The bad data at this location caused an ArduPilot aircraft to crash when doing a terrain following mission.
The error has been in the data since it was last generated in 2022, yes this is the first time we are aware of a crash due to this type of error. That is because areas like this are quite rare, but when you hit one it can be very nasty.
We called this error the “ocean tile bug” as it only happens for tiles that are close to the ocean, and almost always on the east coast of a landmass. This error led to a detailed investigation that uncovered a couple of other types of errors that we have also fixed.
Types of Error
The full list of errors is:
- the ocean tile bug, as shown above, that impacted only data downloaded as zip files from terrain.ardupilot.org, it did not impact data automatically downloaded via the GCS terrain protocol
- the double step bug which caused a striated effect in the zip files downloaded from terrain.ardupilot.org. Most errors were small, but big enough to matter for some applications.
- the nodata bug, where the SRTM3 HGT files has missing data at some locations which could be treated as ocean in the middle of a land mass. This impacted both data downloaded from terrain.ardupilot.org and data sourced via GCS automatic download.
We have had long discussions on how to deal with this issue. What we’ve decided to do is:
- publicise the issue, encouraging users to delete their current terrain data and download it again. This blog post is part of that publicity.
- ready for the upcoming 4.7.x release we have added a pre-arm check, so that if the pre-arm terrain data check loads a DAT file from the microSD card that comes from before these fixes then it will not let you arm. If an old DAT file is loaded while flying you will get a warning on the console. In both cases When this happens see the instructions below to fix the issue.
- The error that is displayed is “terrain data expired, possible errors”
How to Fix
If you are running a 4.6.x release or earlier you won’t get the above error message, but that doesn’t mean you are safe. You should:
- Delete all the DAT files in the APM/TERRAIN directory on your microSD card then reboot the autopilot
- Delete the SRTM data from your Ground Station. If using Mission Planner delete the contents of C:\ProgramData\Mission Planner\srtm
- Then either download new data from terrain.ardupilot.org or let the normal automatic terrain download system download new terrain data via your GCS.
If you are running the new 4.7.x release (or you are running the latest master branch) then you should get the above warning if you have old terrain data, but if you are uncertain then the safe thing to do is delete the old DAT files from APM/TERRAIN and download again.
In 4.7.x you can set a TERRAIN_OPTIONS bit to override the check and allow you to use old terrain data. If you are confident you are not impacted by the bugs (most locations in the world are unaffected) then this new TERRAIN_OPTIONS bit allows you to fly without the error messages. We don’t recommend this, but for some vehicles where replacing the terrain data files is difficult this is provided as an option. For example, if you have created your own DAT files from geoTIFF or similar then this would be a way to avoid having to regenerate them. Remember to unset this option bit when you move to newer terrain data.
More Details and Analysis
The details around these bugs get quite subtle. For example, here is a map of the world showing where the “ocean tile bug” impacted locations for SRTM3 data (data with approximately 100m horizontal resolution) downloaded as zip files from terrain.ardupilot.org
You can see some key features in this data:
- most errors are on the east coast of land masses
- we have a systematic error near the boundary of 60 degrees North
Note that a red dot in the above image just means that at least one point (out of around 1 million points) had an error in an area of about 100 km by 100 km (shape varies with latitude). In some cases, like the images at the top of this post, it affected most of the 100km square, in some cases just a few points inside it.
The worst case height error was over 2000m in a location in Alaska. That is a big error!
Now compare to the same map but for SRTM1 data (data with approximately 30m horizontal resolution).
Here we can see that:
- there was no systematic error near 60 degrees North
- only a very few places in the world were affected, and the max height error was around 260 meters.
The above images are just for the “ocean tile” bug that started this investigation. If we dive into the double-step bug then you see things like this:
This is a slice through a terrain block half way up N83, W033. The blue line is correct data, the yellow line has the double-step bug, showing little jagged errors. Mostly these errors are small (a few meters), but they get larger as you get closer to the poles. They are certainly large enough to cause a crash in some cases.
This is a GDAL view of this same double-step bug, first with the bug:
and now without the bug:
See the subtle striations in the first image? That is the bug.
Data Changes
The data on terrain.ardupilot.org that has changed is:
- all SRTM3 hgt files have been re-generated using the SRTM1 hgt files
- all DAT files have been regenerated using the SRTM1 and SRTM3 hgt files, with a new version_minor field set to 1 in each block
- the SRTM1 hgt files have stayed the same
Thank you
Many thanks to the original user for providing a log of the issue, and to all the developers who contributed to the fixes.