META - Ecosystem terrain standardization

[Ryanf55]

Design Goals

• Use the same terrain data across all devices in the ecosystem
  • Autopilot (PX4, ArduPilot, Etc)
  • Companion Computer (grid_map_geo) or other computers running ROS 2
  • Ground Station (QGC, MAVProxy, Mission Planner)
  • Simulator (Gazebo, SITL)
  • Developer visualization tool (RVIZ, Foxglove)
  • Autonomy navigation/planning frameworks (NAV2)
• Support loading terrain from an online terrain server
  • ArduPilot SRTM
  • AirMap
• Reduce network usage by maintaining a local cache of terrain data
  • Only download tiles once from online terrain server to devices in field
  • Cache terrain on the companion computer and/or autopilot to reduce GCS-Vehicle network congestion
• Reduce the time, complexity, and difficulty to set up terrain data for terrain navigation
  • Example: given no terrain data is installed on any devices, and the system is started without GPS signal, when the GPS is enabled, then the autopilot, companion computer and GCS retrieve terrain and the simulator displays the terrain and the local origin of the simulation is to the home location.
• Enable using drones at large latitudes beyond SRTM's 60 degree limit
• Support simulation of similar scale flight as this

Current Issues

Visualization/Sim

Gazebo

• Gazebo can't consume data from online terrain servers - the Gazebo Classic tutorial involves a lengthy process to manually generate terrain meshes
• Gazebo can't visualize SRTM terrain tiles without decimation due to performance issues
  • Issue for not supporting /vsicurl/vsizip: Support GDAL /vsicurl and /vsizip prefixes to DEM paths gazebosim/gz-common#596
  • Proposed feature for /vsicurl/vsizip: DEM: Add support for GDAL vsicurl, vsizip support and avoid segfaults with huge VRT datasets gazebosim/gz-common#597
• Gazebo assumes the user wants to load the entire dataset supplied, which breaks down with large VRT's (it currently segfaults)

QGC

• QGC uses Airmap terrain which is tied to Auterion's hosting and vulnerable to outages
  • Ticket which includes my GDAL proposal: Terrain Following Fix and Improvements mavlink/qgroundcontrol#7774
• Only 2D
• Unlear support for terrain in Norway: Height data from the Norwegian mapping authority. mavlink/qgroundcontrol#9280
• Unclear support for terrain in Finland: No terrain data (for Finland?) mavlink/qgroundcontrol#7405

MAVProxy

• Only 2D
• Same problems with 60 degrees latitude: MAVProxy sending invalid terrain data above 60N ArduPilot/MAVProxy#709
• Current docs are quite good and explain the features: https://ardupilot.org/mavproxy/docs/modules/terrain.html#terrain-reporting
  • Docs don't show how to use a different terrain server - maybe it's not possible

Mission Planner

• Unclear support for terrain in Norway:
• Elevation data from the Norwegian Mapping Authority. ArduPilot/MissionPlanner#2527
• srtm: removed 60N limit on SRTM downloads ArduPilot/MissionPlanner#3338

Companion Computer

• If the companion computer doesn't have SIM card, it can't fetch terrain data from online, even if the GCS has terrain data

Autopilot

• Autopilot's GPS sensors may use different datums
  • ArduPilot's Location (in 4.5) does not specify altitude datums
  • Instead, you should use get_undulation() as recommended here by Tridge
  • ArduPilot used to not protect users against missing terrain tiles
    • Copter: Terrain data missing for finland, terrain failsafe not triggered ArduPilot/ardupilot#12923

What's working well

Terrain transmission between autopilot and GCS

• Based on MAVLink terrain protocol

Navigation/Planning (NAV2)

• NAV2 currently is heavily tied to Costmap2D in the GlobalPlanner
• NAV2 can't support 3D planning
• NAV2 assumes grid-based algorithms, no allowance for geometric
• We want to efficiently represent airspace and coastlines without a grid

Current Terrain Data Transmission Approaches

These are the standards or techniques to share terrain data between devices over networks, both IP and serial, wired and wireless:

• MAVLink terrain protocol
• GDAL virtual network drivers
• Airmap protocol - TODO find link
• https://cesium.com/platform/cesium-ion/content/cesium-world-terrain/

Current Terrain Sources

• ArduPilot TerrainGen - source code
• Auterion used by QGC

[tridge]

some other issues:

• ublox use a course grained table for alt models, its significantly wrong in many places
• i am not certain that terrain.ardupilot.org is AMSL everywhere, though the ublox issue complicates testing
• we shift terrain db up/down based on home vs terrain height, see TERRAIN_OFS_MAX

[Ryanf55]

From ArduPilot dev call today:

Mission Planner support geotifs.
Mavproxy can pull different terrain from a domain in geoscient australia. It's untested in a while.

• Terrain.ardupilot.org has SRTM1 and SRMT3

The SRTM database may be ellipsoid or AMSL data. NASA might not have converted this (yet).
THe other complication is that ublox implemented a coarse grain table for the world similar to AP's magnetic field.
Even with RTK lock, ublox might return meters different accuracy. AP could also run the calculations correctly.

AP shifts the terrain for baro.

Users want to store their own terrain data. Mission planner can add in its own terrain.

[Ryanf55]

I've been working with some ArduPilot partners flying in steep terrain who have issues with terrain inaccuracies and inefficient or unsafe flight paths.
So far, I created a Jupyter notebook for comparing rangefinder data to arbitrary terrain sources given an ArduPilot bin log.
ArduPilot/ardupilot#30089

The results for the Canadian yukon (steep forest terrain north of 60 latitude) show that the the COP30 data is significantly better than SRTM1, so I created an issue to add that dataset to the ardupilot terrain server.
ArduPilot/ardupilot#30089

Adding a GDAL backend QGC is also back in progress so that QGC users can easily change their terrain source.