M1 Mac Feasibility

Next Generation ROS
1

I have had an M1 Mac Mini since December and I have been looking for a replacement for my old Dell Laptop to run ROS. I was wondering if there is a way to get ROS running on my m1 mac mini. If it is not currently feasible, what options would I have a few months from now when more software is made compatible for the m1 architecture? If m1 is not an option in the foreseeable future, what are your experiences with the MSI line of gaming laptops and ROS compatibility? I am looking for something with strong graphics performance.

2

There is already Raspberry Pi 64bit support. So ROS generally supports the arm64 architecture. Do you see issues when compiling for the M1 specifically?

Out of curiosity: Is running macOS on robots common? The range of hardware is quite limited and I guess only the Mac minis would fit into a robot anyway. Also running anything that needs CUDA would be impossible.

1 Like
3

We have been able to build ROS2 on M1, but there where some issues. My colleague had to use macports to install the dependencies and had to make some changes in the source code. But now it works. We will soon have another mac m1 so we can try it out and try to write all steps down. I have an intel mac and have been able to build everything but there are some problem when doing a colcon build. On my macbook pro i9 it can take 3 minutes to build a package with messages, on the M1 mac it takes 7 seconds. I haven’t figured out why.

A comment to @christian, our team do not develop our code on the final target robot so both mac and windows are relevant for ros2. And in our case, we also develop automation system where most ros2 nodes are running on a server in docker containers. But we also want to connect our macs to try out algorithms.

3 Likes
4

I have been working in ROS2 on an Intel Mac and generally it has been much easier than ROS1 but the build times are excessive, especially for messages. It seems the build and install steps take a long time. Px4_msgs takes 10+ min on my 18 core iMac Pro, although that package has more than 100 messages.

One tip for Mac users is to use a merged install space.

I have no experience with arm based macs, but the efficiency of the M1 is hard to beat. Too bad Apple will ever make an embedded version.

1 Like
5

Erik Boasson @eboasson develops ROS 2 Galactic’s default ROS middleware Eclipse Cyclone DDS on macOS M1. Its sister project Eclipse Zenoh is also developed on macOS M1.

1 Like
6

Sorry, I should have been more clear in my OP. I am looking for a ROS development machine, as opposed to one which will be deployed on the robot.

This is good news, but maybe a bit above my level at the moment!

7

Can confirm. Installing dependencies wasn’t too bad IIRC. There are a few more patches needed for ROS 2 itself on ARM/M1 & macOS Big Sur, but overall it seems to work pretty well.

P.S. if you run into issues and need to patch code, please open PRs!

1 Like
8

That was a great idea. Now when i rebuild galactic with
colcon build --merge-install
My package with messages took 11 seconds compared to 3 minutes after sourcing galactic. It must be something problematic with a large number of paths in the cmake paths? Maybe this should be described in the documentation if this is a problem for others as well.

9

I think I ran into this too on my local machines. I got it debugged down to some issue with very long DYLD_LIBRARY_PATH values. I think macOS is doing some processing on each path internally and the overhead is considerable. So when we call things like python or make or whatever we need during message generation, this overhead is incurred each time.

One option would be to avoid using DYLD_LIBRARY_PATH everywhere, but even if we did that for the core, we couldn’t ensure all ROS packages do that, and so removing it generally is probably not an option…

Honestly, it seems like a performance issue introduced by Apple. I think it may be related to SIP too. Counterintuitively, we ran into issues where disabling SIP on our build farm machines actually made the build time go up on newer versions of macOS (you would think enabled SIP would be more costly). This is one of the reasons we have avoided upgrading the version of macOS we build and test against.

In retrospect it is obvious, but at the time I had never considered using merged install, usually because isolated install is going to catch more build system issues of a certain kind. We use merged install by default on Windows for a different issue, which is that we overflow the maximum environment variable value length on Windows for the PATH…

1 Like
10

@eboasson does all ROS 2 and Eclipse Cyclone DDS ROS middleware development on macOS Big Sur MacBook Pro M1. Says ROS 2 builds are lightning fast compared to his almost new MacBook Pro Intel. Other Eclipse Cyclone DDS + iceoryx contributors use macOS Intel, Linux, Win10.

1 Like
11

I’ve managed to build ROS 2 rolling on a M2 MacBook. This required a few changes to CMakeList.txt files and some other workarounds. I would like to submit this and hopefully help get M1 Macs as supported target for ROS 2.

Any hints on how to get started contributing?

Best regards,

Peter

1 Like
12

Just succeeded building ROS2 with rviz2 on Mac M1 with only a few changes:

  1. 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. This includes changes to include the directories for orocos_kdl and Qt5, as well as packages like Widgets and Test from Qt5.
  2. For the mimick_vendor package, the VCS version was changed to ‘258ccb0a2c38a02d4e1f82357a3f7e40e9306a00’.
  3. 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)…

BR Peter

13

Since XQuartz doesn’t support GLX on Mac(M Chips), this may be a sulotion:
Use tools like xvfb, x11vnc, noVNC, and xfce4 to support GUI applications such as RViz and Gazebo.

See This docker Docker