Since many of the comments here mention rviz and rqt being the main blockers for macOS, I want to mention Foxglove Studio. It is a new tool we are building to interface and visualize ROS robots, and we have binary builds available for Linux, windows, and macOS (universal binary / works with M1).
This would allow you to continue developing ROS inside a docker container, but keep your visualization tools separate from your code.
We are pretty close to feature parity with rviz and rqt, but if there are any missing features you need please let us know and we are happy to take a look.
I echo the need to focus on the GUI tools, that would benefit from the graphics acceleration when running natively on macOS (my pain-point). The other ros processes can always be run in containers during development.
If we set these goals:
Fix ros2 source build/install on macOS, upping support to Big Sur, M1 CPU
Fix Gazebo build for Big Sur/M1 (actually I don’t know if it builds or not, haven’t tried)
Binary distribution of GUI tools such as rqt, rviz, gazebo with Homebrew
then what is the appropriate tool to track this effort? A meta issue? in which repo? A github’s project? I would appreciate some direction how to organize this.
I currently have a build locally on Big Sur + M1/arm64, with rviz building and running. Lot’s of hacks/workarounds. I would like to start consolidating these workarounds so we can track the fixes in ros2 and upstream projects.
Hey all, we’ve recently picked up our work of making ros-galactic easy to install on Apple M1 chips We’re building out packages as part of the RoboStack effort, and you can find all available packages in this table: ROS2 Galactic - RoboStack
For osx-64 it looks pretty good! For osx-arm64 (the M1 chip) we are currently running into some issues because we are cross-compiling in Azure (the host system is a osx-64 machine that compiles to osx-arm64).
Maybe some of you know why the ddsconf executable is not part of the ros-galactic-cyclonedds package? Would there be a downside in shipping it as part of that package? It could simplify the cross-compilation story here because then we don’t need to have a pre-compilation step for cyclonedds (cyclonedds needs this executable at build time).
Anyways, we’d love to chat with you all if you want to use galactic on the M1 chip. Feel free to come over to gitter.im/RoboStack/Lobby or drop an issue in github.com/robostack/ros-galactic.
@wolfv awesome news! Eclipse Foundation’s Cyclone DDS lead committer @eboasson develops on macOS M1. You can see it in the results for ros2 galactic patch release 1 macOS M1:
That’s great. I currently also use a M1 and it’s really a nice machine – especially the fact that it doesn’t get hot at all and is completely silent is nice!
I could also compile everything locally, but in general it’s nice to build these things on a “public” infrastructure. And cross-compilation has worked incredibly well for the entire conda-forge stack on Apple M1, which includes things like BLAS, numpy, scipy, cartographer, ompl, … and many other “hard-to-build” libraries.
In fact, I believe that making cross-compilation easy is an awesome thing.
This thread was really helpful so far as I am one of the Apple Silicon users working in Robotics.
Just might be out of context here but Apple Silicons are great machines for robotics devs and at the same time they are just being neglected widely in package releases.
@Katherine_Scott I was wondering if there are any maintainers for ROS2 macOS at the moment? Or how is it possible to be a maintainer?
The easiest thing to do to start being a maintainer is to look at the existing issues, and starting solving them and opening pull requests to the various repositories. If I were going to do this, I’d do the following:
Take the current Rolling code, and make it compile/work on a current version of macOS.
Open pull requests to the various repositories that you needed to make this work. At that point, you’ll have ROS 2 fully compiling on macOS with no additional patches.
I found robostack being a very viable way of having working release on macos. Most of the upstream repositories are very open to support multiple platforms, but sometimes the technical modification is quite heavy. This is especially true when GUI is involved. Robostack is well maintained and @Tobias_Fischer is doing an incredible job in keeping it running and integrating patches when the upstream modification are too difficult to integrate.
I’ve managed to build ROS 2 rolling on a M2 MacBook a little while ago. This required a few changes to CMakeList.txt files and some other workarounds. Recently some things have happened upstream (or dependencies).
I’ll try to make it work again and then I would like to submit this and hopefully help get M1 Macs as supported target for ROS 2 in the future.
Just succeeded building ROS2 with rviz2 on Mac M1 with only a few changes:
In the CMakeLists.txt files of various packages (interactive_markers, tf2_eigen_kdl, mimick_vendor, rviz2, rviz_common, rviz_default_plugins, rviz_ogre_vendor, rviz_rendering, rviz_visual_testing_framework), additions were made to include necessary dependencies and directories for orocos_kdl and Qt5.
For the mimick_vendor package, the VCS version was changed to ‘258ccb0a2c38a02d4e1f82357a3f7e40e9306a00’.
For the rviz_ogre_vendor package, the OGRE library was configured to not build certain RenderSystem modules and precompiled headers were disabled. Also, the architectures were set to support both arm64 and x86_64.
I’m going to make a set of patches and a script that will build on Mac M1 (with the current Qt5 from homebrew)…
We’re building out packages as part of the RoboStack effort, and you can find all available packages in this table: 
