How to use Gazebo Garden for SITL Simulation of ArduPilot on Apple Silicon

TL;DR - Serving as a live test dummy to set up and share usage of SITL with Garden Gazebo on Apple Silicon M1 MacBook Pro.

Apple Silicon provides exceptional performance that in all likelihood will grow in popularity. Currently there is nascent support for a non-software engineer/developer can make use of this platform to perform simulator work with the likes of ArduPilot and Gazebo. With the upcoming release of Gazebo, Garden, Apple silicon (arm) will be supported natively. This can be used with ArduPilot SITL to perform simulated flight testing and development of different vehicle platforms.

This takes inspiration from @rhys 's excellent work Ship Landing Ignition Simulation,


Attempt so far,

Noting that there are significant reference changes as the Simulator is changed back to being named Gazebo from Ignition, https://gazebosim.org/docs/garden/migration_from_ignition.

  1. Install homebrew https://brew.sh

  2. Attempt to follow Garden binary install guide (not source) https://gazebosim.org/docs/garden/install_osx

  3. Attempt to follow start up guide
    https://gazebosim.org/docs/garden
    Note, command references out of date. User should now open one terminal and start Gazebo server with ‘gz sim -s’ command, and a second terminal to start client GUI with ‘gz sim -g shapes.sdf’.

We are now at this point: run ‘gz sim -s’ , following output is displayed.

In second terminal, run ‘gz sim -g’

Seems like it is likely something very simple to resolve if I knew better how. A similar result is observed when ‘shapes.sdf’ is appended to previous commands.

1 Like

Hi @NDev, it would be great to have the installation and set up of SITL / Gazebo properly documented for macOS M1.

I can confirm the tools run on macOS M1 but I usually build from source in order to have a debug environment - and appreciate it’s not so straightforward for people wanting to just run the simulation rather than develop plugins.

The gz sim -s error message suggests that some of GZ environment variables may not be set up or configured correctly. I was not expecting to see @rpath prefixes on the binaries as we usually build with -DCMAKE_MACOSX_RPATH=FALSE which makes the binaries non-relocatable, but means you don’t need to disable SIP (and in any case binaries are always installed to either /opt/homebrew or /usr/local by brew on macOS).

I’ll try a binary install to see if I can replicate.

In the meanwhile if you are looking to get running from a source build the documentation should be good. Compilation of the full Gazebo stack on a M1 is ten minutes or so. The colcon build command to use from the workspace directory is:

colcon build --symlink-install --merge-install --cmake-args -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_TESTING=ON -DCMAKE_CXX_STANDARD=17 -DCMAKE_MACOSX_RPATH=FALSE -DCMAKE_INSTALL_NAME_DIR=$(pwd)/install/lib 

That will give you an optimised build with debug symbols which you can step through in VSCode. Handy to have.

1 Like

Hi @rhys , following the source install instructions, I get all the way to the colcon part. So close. I run into this error.

Would there be a quick resolution?

@NDev Did you find a solution to this? I’m stuck in the same problem and Id prefer not to disable system integrity for it