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: https://github.com/gazebosim/gz-common/issues/596
  • Proposed feature for /vsicurl/vsizip: https://github.com/gazebosim/gz-common/pull/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: https://github.com/mavlink/qgroundcontrol/issues/7774
• Only 2D
• Unlear support for terrain in Norway: https://github.com/mavlink/qgroundcontrol/issues/9280
• Unclear support for terrain in Finland: https://github.com/mavlink/qgroundcontrol/issues/7405

MAVProxy

• Only 2D
• Same problems with 60 degrees latitude: https://github.com/ArduPilot/MAVProxy/issues/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:
• https://github.com/ArduPilot/MissionPlanner/issues/2527
• https://github.com/ArduPilot/MissionPlanner/pull/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
  • https://github.com/ArduPilot/ardupilot/issues/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

[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.