ROS2 on MacOSX Catalina

Back in 2014 or so, I had ROS1 running on my Mac. It took me a couple days to install and build dependencies. It was quite unstable. This weekend I got a new Macbook Pro (to replace my 2016 Macbook Pro, you know, the one with that great keyboard). I decided to also try setting up ROS2 on it, mainly for native RVIZ. It turned out to be somewhat straight-forward.

As a note, I really didn’t want to do too much mangling of my very nice and very new Macbook Pro - so I actually haven’t disabled System Integrity Protection. So far everything is working (with some caveats on workflow noted below).

First off, newer Macbooks are running Catalina (OSX 10.15) - which is not a supported release. ROS2 (even the newest Foxy release) still targets OSX 10.14 Mojave. This means we absolutely have to build from source for Catalina. I started by following the from-source installation instructions. I’d suggest going through the dependency installations listed there and then applying the patches in the next several sections of this post BEFORE actually running the colcon commands to build anything.

Installing XCode

The ROS2 instructions work for installing the XCode command line utilities, but it seems that I also needed to install XCode from the App store AND start the XCode GUI in order to finish the installation.

Some Paths

I had to add the following to my ~/.zshrc to get the various visual tools to compile:

export Qt5_DIR=/usr/local/opt/qt5/lib/cmake
export PATH=/usr/local/opt/qt5/bin:$PATH

The end of /usr/include

One of the bigger changes in MacOSX Catalina is the removal of /usr/include. Apparently the files have mostly moved to /Library/Developer. As far as I could tell, this really only affects the OGRE build - which needs access to various system header files. The fix is to set CMAKE_OSX_SYSROOT:

colcon build --symlink-install --cmake-args CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

I still had some build issues due to missing CoreFoundation, which were fixed by this hack:

sudo cp /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework/Versions/A/Headers/* /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/CoreFoundation

RVIZ Crashes

I was super excited to see a laser scan show up on my Macbook! I then decided to disable the laser scan and check out some other data - but RVIZ immediately crashed. I spent a while debugging (even after looking through the issues on GitHub) before realizing the fix I had come up with was already merged into the ros2 branch, but not the foxy branch I was building. You’ll want to run from the ros2 branch or at least include PR #572 to really be able to use RVIZ at all in MacOSX.

RQT Issues

Next I tried to run rqt_console - it wouldn’t run, giving me some crazy trace about not finding RMW implements - but I had already tested the Python demo nodes, so I knew that things were working there.

I eventually determined that I could run rqt and then load the desired plugin. I haven’t gone back and debugged this more yet.

Autocomplete Issues

When I first installed things, I got the following warning when sourcing my workspace:

fergs@MacBook-Pro foxy % source install/setup.zsh
zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]?

I accepted the insecure directories a number of times, but eventually got frustrated that autocomplete seemed to not be working. Finally, I started looking into it:

fergs@MacBook-Pro foxy % compaudit
There are insecure directories:
/usr/local/share/zsh/site-functions
/usr/local/share/zsh

Apparently the fix is quite simple. From stack overflow:

sudo chmod -R 755 /usr/local/share/zsh

Debugging with SIP Enabled

One challenge I did come across was that you can’t just run lldb with ROS2 due to System Integrity Protection enabled. This is because the default lldb executable is located in one of those key system folders and so it strips off all the DYLD_LIBRARY_PATH stuff. The workaround is actually pretty simple - use a different lldb, for instance:

/Applications/Xcode.app/Contents/Developer/usr/bin/lldb ~/foxy/install/rviz2/bin/rviz2

Remaining Issues

There are still a few issues to resolve: