TERRAIN Protocol Integration

[zekesarosi]

The Terrain Server plugin implements the companion-computer side of the MAVLink Terrain Protocol, allowing a ROS 2 system to supply real-world elevation data to a flight controller over MAVLink. When an autopilot like ArduPilot needs to know the ground height beneath it — for terrain-following flight, safe altitude planning, or landing — it sends a TERRAIN_REQUEST message asking for elevation data over a grid of coordinates. This plugin catches those requests and responds with the corresponding altitude values, sourced from NASA's Shuttle Radar Topography Mission (SRTM) dataset.

If a tile isn't available locally, the plugin can automatically download it. When auto-download is enabled, background worker threads fetch the missing .hgt.zip from ArduPilot's terrain server (or a custom host), extract it, and slot it into the cache — all without blocking the main request-serving loop. A continent lookup table avoids wasting time on ocean tiles that don't exist.

[vooon]

The problem i see it conflicts with existing plugin, also there requirement to pull curl into main process.
Maybe better to use another approach, where plugin translates messages, but tile server is a separate node?
That way it can be written e.g. in python, so much simpler network code.

[zekesarosi]

yes thanks for the feedback, will change up the framework

[vooon]

I'd done more precise review together with Copilot and also suggest how to improve architecture:

Bugs / blockers:

• Thread safety on pending_requests_: send_next_tile() reads the
  vector under lock, releases, does work, then re-locks using the saved
  index. Between the two locks handle_terrain_request can push_back
  (reallocating the vector), making the index stale. This is a TOCTOU race.
• Missing curl timeouts: If a download hangs, the destructor's join()
  blocks indefinitely. Need CURLOPT_TIMEOUT / CURLOPT_CONNECTTIMEOUT.
• package.xml: <depend>libcurl4-openssl-dev</depend> installs dev
  headers at runtime. Should be
  <build_depend>libcurl4-openssl-dev</build_depend> +
  <exec_depend>libcurl4</exec_depend>.

Integration items:

• Per-tile RCLCPP_INFO on every load/completion will be noisy in
  production — consider RCLCPP_DEBUG for those, keep INFO for summary
  events.
• Missing pluginlist entries in apm_pluginlists.yaml /
  px4_pluginlists.yaml (blocklist by default so it doesn't activate
  unexpectedly).
• Missing parameter documentation in config yamls.

Architecture suggestion:

The plugin is doing a lot — SRTM parsing, LRU caching, bilinear
interpolation, multi-threaded curl downloads, geodesic math, MAVLink
handling, and ROS publishing — all in one ~1000-line class. I'd suggest
splitting it into three layers:

1. SRTM tile library (mavros_extras/src/lib/srtm_tile.cpp + header)
   — .hgt loading, endian swap, interpolation, LRU cache, continent
   lookup. Pure C++, no ROS/MAVLink/curl dependency. This is the part that
   really needs unit tests and is easy to test in isolation with a small
   synthetic .hgt fixture.

2. Terrain server node (separate executable or composable node, could
   even be Python) — owns the download workers, cache directory, curl
   logic. Uses the SRTM library for lookups. Exposes a ROS service for
   elevation queries. All threading/download complexity is contained here,
   and the curl dependency stays on this target only rather than pulling
   into the entire mavros_extras_plugins library.

3. Plugin wiring — adjust the existing terrain plugin to also handle
   TERRAIN_REQUEST / TERRAIN_CHECK by calling the server node's ROS
   service and sending TERRAIN_DATA back. Stays thin and consistent with
   other mavros plugins. No file I/O, no threads, just message plumbing.

This keeps the SRTM code testable, makes the server independently reusable
(e.g. for terrain-aware mission planning), avoids adding curl as a
dependency for all mavros_extras users, and resolves the ~/report topic
overlap with the existing terrain plugin naturally.

[zekesarosi]

did you review after I refactored to your original suggestions?
I will update again but this current implementation should be much cleaner with the separate python node that handles all the messy network calls and then the unified terrain plugin that bridges with the mavlink connection

[vooon]

@zekesarosi not yet. Not expected that fast...
Right now just some organisational:

• Need to add python setup.py/cfg and setup like in main mavros (for py-lib)
• Place generator into root /tools/
• Make an entry-point so it could be ros2 run ... terrain_tile_server
• Please fix code style (see the CI failures, basically you can use Ruff with config from mavros)
• Please make some unit tests inside extras/tests/.

[vooon]

New docs extractor gets the descrption from the comment above node->create_*(),
So please move it here.

[vooon]

Where are that compress/b64 came from? It doesn't looks like we really needs that, but makes check harder.

[vooon]

I'm a bit unsure about almost raw mavlink message repr, e.g. int32 lat/lon when in most of other places we use GeoPoint/float64.

[zekesarosi]

thank you again for the feedback. Let me know again about this revision.

[vooon]

About base64 - i mean, do we really need to store that as a compressed blob?

[vooon]

Just thought - maybe good to have some script to preload tiles?
I.e. give some rectangle (two coordinates pair) and script will download absent data.
Or maybe like a cache management commands, like preload / update (check and load changed data) / validate (i.e. ready for offline work).

Also regarding loading of the data, good to support http(s) proxy.
Is there a checksum files available on the source? If so - possible to get those files via https and tiles via http, so proxy like a Squid can cache the data in your local site.
If not, well, there nginx, but setup a little bit harder.