3D Navigation Status Report

Aerial Vehicles
1

Hello!

In preparation for the upcoming ROS aerial WG meeting in a few days, I wanted to create thread to share recent updates regarding 3D navigation for aerial.

Navigation in aerial covers a wide variety of vehicle types and environments, from small indoor quads running SLAM to larger outdoor fixed-wing platforms with reliable GPS. Many facets of aerial navigation have been widely researched and is even available in open source. Simple object avoidance is now available on consumer-grade multirotor photography platforms.

Most multirotor autopilots can support onboard waypoint planning for outdoor surveying in 2D, and some even support 3D surveying for infrastructure analysis.

For fixed-wing vehicles, navigation brings some additional challenges:

  • Fixed-wing vehicles cannot stop mid-flight, so errors in algorithms can have high consequence
  • Fixed-wing vehicles have fewer degrees of freedom, with limited turn radius and climb/descent angles
  • Fixed-wing vehicles fly for longer distances, where the curvature of the earth can ruin flat-earth assumptions in local cartesian frames
  • Fixed-wing vehicles still need to obey regulations with regard to stringent altitude limits above ground

As a result, currently available functionality puts a high load on the operator in the planning stage to account for these challenges, autopilots have a high burden to handle terrain avoidance without computational power able to guarantee a plan is feasible or safe, and thus fixed-wing vehicles are typically artificially limited in capability to ensure safety.

Despite these challenges, recent work from @Jaeyoung-Lim from the Autonomy Systems lab at ETH Zurich aims to prove 3D fixed-wing autonomy in mountainous terrain under an airspace boundary. The code has been released open-source under ROS1 with a permissible license.

As part of the aerial working group, a few of us including @srmainwaring , @botmayank have recently been collaborating with @Jaeyoung-Lim with the goal of accomplishing the following

  1. Reproduce the terrain navigation work in ROS 1 and contribute fixes as-needed
  2. Port everything to ROS 2
  3. Abstract away ties to PX1 into an autopilot-agnostic message layer
  4. Fly it on another fixed-wing using ArduPilot and ROS 2 to prove the abstraction
  5. Release binaries for terrain-navigation in ROS 2 humble

So far, we’ve contributed many improvements to reproduce the work. We have not yet gotten a full dockerized environment running to reproduce it yet, which is handy for developers using Ubuntu 22.04, but @botmayank has it running on Ubuntu 20. @srmainwaring is actively working towards the port to ROS 2. Dependencies like grid_map_geo are now available in ROS 2.

Because legal fixed-wing autonomous navigation is not a solved problem in the open-source environment, there has been great interest on this project, and there’s plenty of work to go around for those curious to help out.

Current challenges include:

  • Autopilots all require specific interfaces to use them for navigation in ROS 2 which makes writing autopilot-independent algorithms difficult
  • Common autopilots such as PX4 and ArduPilot do not handle multiple vertical datum standards well; instead, they expect the user to validate all components are using the same datum. When these are wrong, the user observes significant offsets and disagreement
  • ROS 2 support for GPS and local datums for accuracy is still in design
4 Likes
2

Some more detail on the port to ROS 2 Humble of @Jaeyoung-Lim’s terrain-navigation software:

The open PRs for ROS 2 support are:

The first deals with the main packages, the second the rviz2 plugin. Both compile and run (as in the planner launches and the terrain and markers are displayed in rviz), but there is further work and testing required to make the rviz planner plugin work correctly. The most up to date changes are available in this branch: GitHub - srmainwaring/terrain-navigation at wips/wip-ap-dds-launch, which has been customised to launch an ArduPilot SITL session with DDS enabled.

The upstream dependencies on mav_comm and grid_map_geo have been ported and merged into ros2 branches:

The aim is to get the ROS 2 version working using mavros, with a view to uncoupling from mavros at a second stage, where we would be able to use the PX4 and ArduPilot DDS layers directly via a set of agreed ROS 2 standard messages.

2 Likes
3

Thanks @RFRIEDM and @srmainwaring for the current status! This is very helpfull for us to get up to speed.

My additional question would be (which we can also discuss later today at the meeting), is about the overlap and differences between indoor and outdoor navigation? Logically now most of the work is to solve issues for outdoor navigation as the mismatch is the greatest between different vehicles, but would any of these observation also translate to indoor navigation for aerial vehicles as well?

My guess, is that the type of waypoint based navigation wouldn’t really apply anymore for indoors, and maybe it is so different that it should be considered a completely new topic.

4

I believe not. The terrain navigation package is not doing waypoint following but path following. Therefore there should be no difference between indoor and outdoor navigation in terms of reference representation. (Terrain navigation uses Dubins paths as a primary path representation).

The problem we are facing in outdoor navigation is that the coordinate frames are defined through a geo projection. The coordinates cannot be assumed to be a cartesian coordinate system. The approximations are simply not good enough for the scale we are navigating in. However, the problem with geocoordinates is that it is quite diverse and local → different countries use different conventions to increase the accuracy of the georeference, which makes it tricky to come up with something that works in every country, without handling the nitty-gritty of geoprojections.

There are also applications when georeferencing indoor navigation scenarios can be useful. For example, maybe you want to map a subterranean environment, but know the accurate geometry of the place. Then georeferencing indoor navigation results can be helpful. However, this I think would involve a completely separate discussion.

1 Like