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
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.
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.
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
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…
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.
Not sure if this is still being worked but hopefully somebody has some advice. I was able to get Gazebo Garden to build on M1 Mac (native). it runs the shapes environment with no issues. My problem is at the stage of building arduPilot_gazebo plugin. To do this, I followed the build instructions on the ardupilot_gazebo GitHub in the ros2 branch.
I first opened a new terminal window and ran the gazebo environment setup command:
~/workspace/install/setup.zsh
I then did the following:
git clone https://github.com/ArduPilot/ardupilot_gazebo
cd ardupilot_gazebo
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
CMAKE seems to work just fine except it reports Qt issues in two locations. The first here…
CMake Warning at /Users/cryptik/Development/other/gazebo-ws/install/lib/cmake/gz-gui7/gz-gui7-config.cmake:101 (find_package):
By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5", but
CMake did not find one.
Could not find a package configuration file provided by "Qt5" with any of
the following names:
Qt5Config.cmake
qt5-config.cmake
Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
to a directory containing one of the above files. If "Qt5" provides a
separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
/Users/cryptik/Development/other/gazebo-ws/install/lib/cmake/gz-sim7/gz-sim7-config.cmake:98 (find_package)
/Users/cryptik/Development/other/gazebo-ws/install/share/cmake/gz-cmake3/cmake3/GzFindPackage.cmake:243 (find_package)
CMakeLists.txt:22 (gz_find_package)
CMake Warning at /Users/cryptik/Development/other/gazebo-ws/install/lib/cmake/gz-sim7/gz-sim7-config.cmake:99 (find_package):
By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5", but
CMake did not find one.
Could not find a package configuration file provided by "Qt5" with any of
the following names:
Qt5Config.cmake
qt5-config.cmake
Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
to a directory containing one of the above files. If "Qt5" provides a
separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
/Users/cryptik/Development/other/gazebo-ws/install/share/cmake/gz-cmake3/cmake3/GzFindPackage.cmake:243 (find_package)
CMakeLists.txt:22 (gz_find_package)
and the second here…
-- RapidJSON found. Headers: /opt/homebrew/Cellar/rapidjson/1.1.0/include
-- Configuring done (3.6s)
CMake Error at /Users/cryptik/Development/other/gazebo-ws/install/lib/cmake/gz-gui7/gz-gui7-targets.cmake:61 (set_target_properties):
The link interface of target "gz-gui7::gz-gui7" contains:
Qt5::Core
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Call Stack (most recent call first):
/Users/cryptik/Development/other/gazebo-ws/install/lib/cmake/gz-gui7/gz-gui7-config.cmake:131 (include)
/Users/cryptik/Development/other/gazebo-ws/install/lib/cmake/gz-sim7/gz-sim7-config.cmake:98 (find_package)
/Users/cryptik/Development/other/gazebo-ws/install/share/cmake/gz-cmake3/cmake3/GzFindPackage.cmake:243 (find_package)
CMakeLists.txt:22 (gz_find_package)
-- Generating done (0.0s)
CMake Generate step failed. Build files cannot be regenerated correctly.
Gazebo Garden seems to run with no problems. I have an ardupilot and gazebo conda environment setup with the related dependencies installed. I can run the ArduPilot SITL with mavproxy with no issues inside its conda environment. I have a separate conda environment setup for gazebo and I do the ardupilot_gazebo build in that environment.
I also have qt@5 and qwt-qt5 installed with brew. I do not have any environment vars set for Qt, so I am not sure if that might be the issue. Any advice in getting past this issue would be most appreciated. I am running MacOS 13.4 (Ventura) on M1.
Ok, my bad. This was fixed by telling CMAKE where the qt5 stuff is. Apparently, the FindQt5 module is provided by Qt5 itself, so CMAKE needs to be told where to find it. Adding this flag to the cmake step fixed it.
You may also need to unlink qt as there can sometimes be conflicts with libs installed to /opt/homebrew/lib.
I have an in progress PR here pr-ship-landing-v2-rebase to bring the ship landing demo up to date and fix a world frame orientation issue.
You may also be interested in these patches for running gz-sim on macOS which fix the qt control, improve the gamma profile, and prevent a duplicated render call every frame in the GUI (makes a big difference with the wave sim).
Congratulations for this work !
I’m would like to run and play with your amazing demo on my Mac M1 too. Coud you explain me:
Which packages should I install via brew ?
Which git branches should I clone / patch / build ?
Will be the support of gazebo better on OSX (BareMetal) than in my Parallels virtual ubuntu 20.04 and its OpenGL emulation ?
I’ve been playing with the sim_ship parameter for a few days now, especially in Copter. I used to work on copter V4.4 but today when I updated to V4.5 I found out that the sim_ship vehicle creates another copter instead of the boat it used to create. Even if it seems to work the same way (the copter circle according to the parameters we set in sim_ship_*** and the copter initiates on the deck as before) I wonder if this would be related to the advances on making a ship landing code for copter.
that’s the plane mooving with no ship in v4.5
