Ship Landing Ignition Simulation

@tridge I think it’s all good to go now.

Add truck quadplane landing example by srmainwaring · Pull Request #62 · ArduPilot/SITL_Models · GitHub should contain everything you need including launch scripts, model port configuration, world generation etc.

There’s one upstream PR to merge before the landing example goes in after a rebase, other than that I think it’s done.

The truck is speed limited to 5 m/s in AUTO as requested, and the default quadplane is the Alti Transition. The friction on the trailer deck may be a little low so the plane will slip if manoeuvring aggressively. The mass may also be a little low, but that should not affect things too much in the first instance.

Setting the follow camera

@tridge - there was an ignition PR to provide a service to adjust the follow camera offsets:

For example:

ign service -s /gui/follow/offset --reqtype ignition.msgs.Vector3d --reptype ignition.msgs.Boolean --timeout 2000 --req "x: 15, y: 5, z: 5"

Updated updated example to offset camera to look back and down to the right. With larger offsets the behaviour is ok.

1 Like

Changing Simulation Speed

The plugin currently does not implement speedups requested from SITL (i.e. the frame_rate in the servo packet sent by the controller is ignored). However the simulation speed can be controlled from the Ignition GUI.

  • Click in the scene and enter ESC to select the World
  • The World component should display in the Component Inspector
  • Click on Physics
  • Set the Real Time Factor to speed up / slow down the simulation (in practice you may get between a 1.5x to 5x speed up depending on what’s being simulated and the network connection to JSON-SITL when using lock-step)
1 Like

Quick truck-landing demo. Thanks to Rhys for all your help!


Demo looks great! Next step is to get the ocean model working on Ignition and provide a ship for you to land on.

1 Like

Camera Sensors

Possibly for a different topic… I’ve been working on extracting camera sensor data published by Ignition for forwarding onto other clients. Here’s a sample of what is possible.

The first image is a Gazebo simulation of a copter outfitted with a number of different simulated camera sensors - regular camera, depth camera, rgbd camera, and thermal camera.

The second image shows a version of the ign_rviz project modified to run on macOS (any tool capable of display ROS image types would do - choices are currently a bit limited on macOS). It is subscribing to ROS2 topics with message type sensor_msgs/Images. In the background there is a ROS2 python node running a bridge between Ignition and ROS2 message types. The Ignition messages are protocol buffers with Python bindings and are accessed via pybind11 bindings to a couple of the Ignition libraries (ign_msgs and ign_transport). The same technique should permit forwarding to ArduPilot via pymavlink given appropriate image converters (there would be no need to depend on ROS in this case).

Next steps are to incorporate the work done for visual avoidance in AirSim and determine the best way to structure the parts to make it easier to distribute and use

1 Like

So, you’ve written your own ignition-ros bridge and didn’t use

Hi @soldierofhell, I’m aware of the ign_ros bridge work (I used the image bridge code to check the pixel format mappings). Don’t worry - I’m not trying to build an alternative ros bridge! Rather, I’m looking to provide some tools that make it easier to get at the information available in Ignition. Providing an image mapping to ROS was a fairly quick piece of Python programming which let me check that I was getting the data out of Ignition correctly using standard tools. The end objective in this case is to get the data back into ArduPilot, skipping ROS entirely.

Here’s another example: Ignition publishes a model state message that contains all the joint and link information for a model. There is currently no mapping using the ign_ros bridge of this message into ROS equivalent messages for the joint states (position and velocities). I wanted to analyse the joint velocities and PID states of the joint controllers used for the propellers on a model but had no easy way of doing that. You can’t plot the data in Ignition because there is no way to filter on the different elements of the message. On the other hand once you have the messages in Python you can filter and split the entire model message into a number of simpler message streams that can be picked up by various standard plotting tools. The python bindings for the transport layer are here, I haven’t published the repo containing the mapping code, but I’ve attached the scripts I’m using so you can see that they’re quite easy to work with. You could do it all in C++, but that feels like hard work to me. (2.2 KB) (2.3 KB)

If there was wider interest in using this I’d be happy look into developing it into something more robust for wider use.

1 Like

Those python bindings look really good. I was aware of ScenarIO from gym-ignition project, but your work is more like direct python api like rospy/rclpy in ROS.

1 Like

yep, I think the key for ArduPilot is to not depends on ROS. That really simplifies workflow to not depend on ROS when it isn’t necessary !

Thanks, I looked through the ScenarIO work and managed to get it running on macOS. Their objective seems to be to use ignition gazebo directly as a library in much the same way as you’d use Bullet. As I think you commented elsewhere, there is currently no access to sensor data which makes the ScenarIO project less useful for the type of thing we’re doing here. The Ignition team are fairly advanced in their support of bindings for the ignition-gazebo libraries but they didn’t have the message and transport layer in their current roadmap - hence the separate library. The idea was to expose the transport layer and messages much like ROS does, so if it looks a bit like ROS then it’s on the right track :slight_smile:

Still very much a work in progress (i.e. no water shaders yet, no tiling of the ocean), but the wave visual is now running in Ignition. Just need to add boats and buoyancy…

Now with boats and other flotsam…

Lots of caveats - definitely not ready for release yet.

  • More to do to get the visuals right, that may take some core Ignition changes if I can’t manage work-arounds.
  • The physics performance needs work as I suspect I busted something during the port.
  • There are many hardcoded parameters that would usually be set via various XML or message parameters.

However - it’s working and supports the same mixture of objects constructed from primitives or meshes as before, so a good basis for iterating improvements. If anyone’s interested in getting involved the issue tracking the migration is here:

1 Like

Ship Model

I’ve put together an example ship model to help with investigations on scaling the simulation up to larger environments. The model is not currently integrated with ArduPilot (it’s free floating), but gives some idea of what a target simulation might look like. The ship is approx 90m long (based on a model of a Havyard 842 tug which has a large deck area that can accommodate a quad plane). The challenge is to scale the simulation so that the local ocean field remains interesting (so reasonable resolution at the few metres scale), while the global environment is large enough for aircraft experiments (at the multiple kilometres scale). To do this properly so that it runs RT will involve using some of the advanced features of the underlying render engine that powers Ignition.


looks great! will be interesting to try this

A mixed boat / quad-plane example for proving out some additions to ardupilot_gazebo to support the Ignition thruster plugins. Unfortunately I didn’t have access to my repo with the Havyard 842, so the boat is a super size WAM-V. The example doesn’t include tridge’s Lua landing script.

High-speed scrub of the session - apologies for the keyhole surgery on an old MacBook.

Code and models in this branch: GitHub - srmainwaring/asv_wave_sim at feature/ship-landing-demo

Brief instructions here: Add ship landing example · Issue #20 · srmainwaring/asv_wave_sim · GitHub


very nice, thanks @rhys !

Hello Everyone!

@rhys @tridge

I would really like to get involved in this project, Ignition Gazebo? I have worked with gazebo before but never saw something like this.

I would like to get involved and help where needed.

What is the best way to get started with all of these things you are trying out? Is there a documentation i should start with??

Thank you!


Hi @ddomit, it would be great to have your help to improve support for Ignition Gazebo.

Updating the documentation is might be a good place to start! The Gazebo documentation in the ArduPilot wiki refers to the pre-Ignition version (Gazebo9 and Gazebo11) rather than the Ignition version that is used for ship landing. There is some documentation in the various GitHub repos that host the component parts, but there isn’t an overall manual that ties it all together.

The starting point for running the ship-landing simulation is to get a working Ignition Gazebo / ArduPilot / ardupilot_gazebo environment set up with some simple models. When that is working you can set up the sea surface simulation and run the environment for multiple vehicles.

Useful documents / repos:

Depending on your experience and interests there is a range of things to work on:

  • Improve the documentation
  • Add models for different vehicle types
  • Improve the aerodynamics physics (propeller models, lift-drag models for aircraft)
  • Improve the hydrodynamics models (thruster models, hydrodynamics behaviour)
  • Improve the environmental models (waves performance and visual fidelity, wind models, sea currents models)
  • Integrate different sensors with SITL: cameras, laser scanners, sonar
  • ROS / ROS2 / mavlink integration - simulating off board planning etc.
  • Python scripting of Ignition / ArduPilot simulation environments

Plenty to do!


Update on recent changes to the ocean and ship landing simulation:

  • The Gazebo team have been migrating the simulator name from Ignition back to Gazebo. This impacts the entire library: project names, includes, namespaces, plugin names. It was not possible to integrate this a backwards compatible fashion - so I’ve elected to update the wave simulation project to use the new names and link against the main branches of the Gazebo libraries (Gazebo Garden).
  • The ship landing example is available on the following branch: demo/ship-landing-v2. The extended ocean requires custom shaders and is currently only supported on macOS. For linux you should switch the sea surface model from ocean_waves to waves. The visual region is smaller, but the physics will continue to work outside the visual region using periodic boundary conditions.
  • There is a presentation here: Gazebo Ocean Simulation - Google Slides that provides an overview of the simulation library and some applications. Most of the simulated robots are controlled by ArduPilot, either directly or via mavros.
1 Like

Hey such an awesome work!! I am really fascinated by the results / process documented :clap: