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.
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)
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).
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 https://github.com/srmainwaring/python-ignition, 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.
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
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:
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.
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.
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.
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.