Add a page on how to setup SITL on Mac OSX #3307
Conversation
|
@andyp1per are you still the one to review this? |
|
@andyp1per bump! |
|
|
||
| :: | ||
|
|
||
| export DISPLAY=:0.0 |
There was a problem hiding this comment.
Don't you need the macOS X environment installed for this to work?
There was a problem hiding this comment.
I've not needed to set the DISPLAY when running SITL (no need for an X server that I'm aware of?)
|
@Hwurzburg - I haven't got a Mac, so unable to review. |
|
|
||
| :: | ||
|
|
||
| brew install [email protected] |
There was a problem hiding this comment.
I found that in order to get ArduPilot to compile using waf on an M1Pro Mac running OSX 12.1 Monterey I had to install Python 3.10 from python.org. But this version of python will not run SITL. To both compile using waf and run SITL the only version (2022 April 3) I have found to work is Anaconda python from anaconda.com.
There was a problem hiding this comment.
Wondering if we need two sub-guides for macOS - one for Intel based machines and one for M1 versions. The default install locations for brew are different for each architecture and I suspect we'll keep seeing more differences as more functionality is documented. For example the instructions for adding other simulators like Ignition will be specialised for each architecture.
There was a problem hiding this comment.
I can compile ArduPilot just fine with Python 3.9 on an M1-based MacBook Pro so I don't think you'll need Python 3.10. I'm using Python 3.9 from Homebrew.
Edit: I usually don't install mavproxy because it brings lots of dependencies with it that I don't need, so the differences outlined above may be due to mavproxy dependencies. Also, note that a few months have passed since January so it may be the case that some dependencies of mavproxy have published pre-built M1 or universal2 wheels on PyPI since then.
| brew install [email protected] | ||
| export PATH="$(brew --prefix)/opt/python/libexec/bin":$PATH | ||
|
|
||
| pip install wheel |
There was a problem hiding this comment.
This command may require sudo. Best practice to install for the local user is to use the --user option to install for the user only.
There was a problem hiding this comment.
Not sure how much we want to dive into this in the instructions, but in my experience the best is to isolate ArduPilot-related Python dependencies in a virtualenv; what I do is as follows:
python3 -m venv .venv
.venv/bin/pip install -U pip wheel future pymavlink mavproxyand then I run everything from the virtualenv. This way I don't mess up the Homebrew-installed Python with random dependencies that are needed for ArduPilot only.
There was a problem hiding this comment.
I'm pretty sure it would help to put this in the instructions. Setting up a workable M1 Mac dev environment should be easy and without clear instructions it's definitely not. When you say "run everything from the virtualenv" - you mean mavproxy.py or waf or both?
What I find now is that waf needs a different python environment to mavproxy, but sim_vehicle calls both waf and mavproxy so I can't get sim_vehicle->waf to use a different python from sim_vehicle->maxproxy.
For now in order to get sim_vehicle to work, I just run it 'headless', which seems like what @srmainwaring and others are doing but I shouldn't have to do that.
There was a problem hiding this comment.
I have to admit I don't use mavproxy in the virtualenv because I'm using my own tools to talk to the simulator. mavproxy is problematic because it insists on bringing the entire wxPython distribution with it and I don't need that. wxPython currently provides pre-compiled wheels for Intel Macs only on PyPI, and only for Python 3.9, so until wxPython publishes newer wheels one would have to compile wxPython from source.
So, ultimately my goal was to get the build process running and to be able to run most of the non-GUI scripts from the Tools folder (e.g., the one that builds the bootloaders). For that, a virtualenv is fine, the only catch is that some of the scripts invoke other Python scripts or waf in a way that it does not respect the current Python interpreter setting (like this one ) and just fall back to whatever Python is at the front of the system PATH. Activating the virtualenv from the shell with source .venv/bin/activate does the trick in 99% of the cases, for instance it ensures that waf picks up the correct (virtualenv-based) Python instead of the system Python.
Edit: I tried the wxPython snapshot builds from here; it seems like they have universal2 wheels for Python 3.9 there so there would be no need to compile wxPython from source, but it did not work for me so I just gave up on GUI stuff.
| export PATH="$(brew --prefix)/opt/python/libexec/bin":$PATH | ||
|
|
||
| pip install wheel | ||
| pip install future pymavlink mavproxy |
There was a problem hiding this comment.
Using Python 3.10 from Python.org for Mac M1 ARM version, this will fail with the following errors:
wx/svg/_nanosvg.c:20946:19: error: implicit declaration of function '_PyGen_Send' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
ret = _PyGen_Send((PyGenObject*)yf, value == Py_None ? NULL : value);
^
wx/svg/_nanosvg.c:20946:17: warning: incompatible integer to pointer conversion assigning to 'PyObject ' (aka 'struct _object ') from 'int' [-Wint-conversion]
ret = _PyGen_Send((PyGenObject)yf, value == Py_None ? NULL : value);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wx/svg/_nanosvg.c:20951:19: error: implicit declaration of function '_PyGen_Send' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
ret = _PyGen_Send((PyGenObject)yf, value == Py_None ? NULL : value);
^
wx/svg/_nanosvg.c:20951:17: warning: incompatible integer to pointer conversion assigning to 'PyObject ' (aka 'struct _object ') from 'int' [-Wint-conversion]
ret = _PyGen_Send((PyGenObject)yf, value == Py_None ? NULL : value);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wx/svg/_nanosvg.c:21035:19: error: implicit declaration of function '_PyGen_Send' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
ret = _PyGen_Send((PyGenObject)yf, NULL);
^
wx/svg/_nanosvg.c:21035:17: warning: incompatible integer to pointer conversion assigning to 'PyObject *' (aka 'struct _object ') from 'int' [-Wint-conversion]
ret = _PyGen_Send((PyGenObject)yf, NULL);
There was a problem hiding this comment.
I'm not totally sure what these lines do, but it seems that there is some code in _nanosvg.c that needs to be fixed.
|
|
||
| export PATH="$(brew --prefix)/opt/python/libexec/bin":$PATH | ||
|
|
||
|
|
There was a problem hiding this comment.
It's also useful to add
################################################################################
# ARDUPILOT
#
export PATH=$PATH:$HOME/Code/ardupilot/ardupilot/Tools/autotest
export ARDUPILOT_ROOT=$HOME/Code/ardupilot/ardupilotto the shell initialisation scripts while you're at it. I put customisations including the PATH modification for Python in ~/.zprofile.
There was a problem hiding this comment.
This may cause problems if you run more than one clone in different directories. I often do that.
|
|
||
| .. warning:: | ||
|
|
||
| Due to ideosyncracies with Python and using screens there are limitations when Python needs to use the screen to display a graphical UI. Python 3.9 solves part of the problem by no longer requiring a separate pythonw binary. However the requirement to run on the main display still stands. When observing the error "This program needs access to the screen. Please run with a Framework build of python, and only when you are logged in on the main display of your Mac.", disconnect external displays during startup. When SITL is started the windows can be moved around as normal. |
There was a problem hiding this comment.
sp.
- ideosyncracies
+ idiosyncrasiesThere was a problem hiding this comment.
I haven't been able to get this to work at all on my M1 Mac. So I just run SiTL with no UI. It works fine and I connect to the running model with with QGroundControl which shows the map and all the messages.
Maybe the wiki should say the UI is optional?
There was a problem hiding this comment.
@timtuxworth unfortunately I don't have a M1 to test at present - still Intel based machines for me. When I get round to upgrading my macbook I'll take another look at the UI modules in MAVProxy which seem to be causing the problems. As you suggest it might be worth emphasising the difference between a bare bones SITL install (with alternative GCS) and full MAVProxy support for macOS which should have all the UI elements functioning correctly.
There was a problem hiding this comment.
Indeed; it seems like most of the difficulties that arise in installing SITL stuff on an M1 Mac are due to the GUI stuff. I run the SITL without a GUI and I haven't encountered any significant issues.
There was a problem hiding this comment.
@spark404 nice one, thanks for expanding on the docs for macOS. My main thoughts (also commented in the review details) are that we may need to have custom install instructions for the newer M1 based machines, as Apple have changed the permitted locations for where user libraries can be placed. This combined with the sanitising of DYLD_LIBRARY_PATH means that software developed on linux that should nominally run fine on macOS can be tricky to set up unless care is taken to ensure everything winds up in the right place - you can't fix it with library path remapping now unless you disable SIP (which I prefer not to).
I managed to get SITL running on my Mac. The instructions might be useful for other folks try to do the same.