Installing player/stage on OS X 10.5 Leopard

This tutorial will go through the steps for installing player/stage on OS X. We’ll work through any issues encountered along the way, and verify the stage installation. The tutorial won’t go into verifying the player installation against any hardware.

UPDATE (6/20/10): These instructions don’t work for the latest MacPorts install of player (3.0.0) + OSX 10.6 (Snow Leopard). For example, if you try to run player you get the following:

$ player
Registering driver
Player v.3.0.0
USAGE:  player [options] []

Where [options] can be:
  -h             : print this message.
  -d      : debug message level (0 = none, 1 = default, 9 = all).
  -p
      : port where Player will listen. Default: 6665
  -q             : quiet mode: minimizes the console output on startup.
  -l    : log player output to the specified file
     : load the the indicated config file

The following 81 drivers were compiled into Player:

    Segmentation fault

Or if you try to run player with the stage plugin you get this:

$ player cfg/voronoi.cfg
Registering driver
Player v.3.0.0

* Part of the Player/Stage/Gazebo Project [http://playerstage.sourceforge.net].
* Copyright (C) 2000 - 2009 Brian Gerkey, Richard Vaughan, Andrew Howard,
* Nate Koenig, and contributors. Released under the GNU General Public License.
* Player comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
* are welcome to redistribute it under certain conditions; see COPYING
* for details.

loading plugin stageplugin
error   : Failed to load plugin stageplugin.
error   : libtool reports error: file not found
error   : plugin search path: /Users/jaustin/work/player-bots/voronoibot:cfg:/opt/local/lib/
error   : failed to load plugin: stageplugin
error   : failed to parse config file cfg/voronoi.cfg driver blocks

There are a couple of related issues posted for the playerstage-player MacPorts port (22642, 23179, 26048, 26329), and my suspicion is that it has to do with compiling with x86_64 architecture in OS X 10.6. It seems like one can try to build the macports using different options to get around the architecture issue, or try building player from source. I’ll post an update if I figure it out.

Step one: Install MacPorts (aka DarwinPorts)

This installation requires
After you’ve installed from the disk image, update ports to the latest version
$ sudo port selfupdate

Step two: Install player/stage

If you don’t have cmake, get it now, else the install will fail:
$ cmake
-bash: cmake: command not found
$ sudo port install cmake
Then install stage (playerstage-stage has a dependency on playerstage-player, so player will be installed as well):
$ sudo port install playerstage-stage
Note: On Snow Leopard, this install took forever for me. I did have some internet issues in the middle of the install, but it still took most of the day to build. So I would recommend being patient here.
By default, the installer will use /opt/local as the install prefix, giving you the following setup:
/opt/local/bin (executables, including the 'stage' program)
/opt/local/lib (libraries, including libstage)
/opt/local/share/player (contains data resources, such as images)
/opt/local/share/stage (contains data resources, such as images)
Since /opt/local/bin should already be on your path, you shouldn’t have to do any extra setup to access the executable.

Step three: Verify installation (OS X 10.5)

At this point, you want to try running stage against an example world. However it seems that the DarwinPorts installation doesn’t install any worlds under /opt/local/share/stage. So you can go to the player/stage SourceForge site and download the latest stage source archive.
Extract the archive and copy the worlds directory to /opt/local/share/stage.
Now, cd into the stage directory and run the test:
$ cd /opt/local/share/stage
$ stage worlds/simple.world
dyld: Library not loaded: libstage.3.2.2.dylib
Referenced from: /opt/local/bin/stage
Reason: image not found
Trace/BPT trap
Looks like the stage libraries are not on our path, so let’s add them (note that you should also add this to your ~/.profile):
$ export DYLD_LIBRARY_PATH=/opt/local/lib
And try again:
$ stage worlds/simple.world
stage simple.world dyld: Symbol not found: __cg_jpeg_resync_to_restart
Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /opt/local/lib/libjpeg.7.dylib
Trace/BPT trap
We still have issues. It looks like the version of libjpeg.dylib on our library path is a different version from what ImageIO is expecting. Maybe there was a transitive dependency in the DarwinPorts install that’s screwed us over, who knows. Anyway, if we point to OS X’s version of libjpeg, maybe we’ll eliminate this issue.
$ cd /opt/local/lib
$ sudo rm libjpeg.dylib
$ sudo ln -s /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Resources/libJPEG.dylib libjpeg.dylib
$
$ cd /opt/local/share/stage
$ stage worlds/simple.world
dyld: Symbol not found: __cg_TIFFClientOpen
Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
Expected in: /opt/local/lib/libTIFF.dylib
Looks like a similar issue, so we’ll try the same trick again (and yet again for libpng):
$ sudo rm libtiff.dylib
$ sudo ln -s /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Resources/libTIFF.dylib libtiff.dylib
$ sudo rm libpng.dylib
$ sudo ln -s /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Resources/libPng.dylib libpng.dylib
$
$ cd /opt/local/share/stage

$ stage worlds/simple.world
Stage 3.2.2
[Loading worlds/simple.world][Include pioneer.inc][Include map.inc][Include sick.inc]
Success!
Try holding the ctrl key and moving your mouse cursor around to change the view. You can also press “p” to unpause the simulation.
Now let’s test to see that plugins are working:
$ stage worlds/fasr.world
Stage 3.2.2
[Loading worlds/fasr.world][Include pioneer.inc][Include map.inc][Include sick.inc]warn:
multi-thread support is experimental and may not work properly, if at all. (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_science_playerstage-stage/work/Stage-3.2.2-Source/libstage/world.cc Load) [threads 2]
A window should pop up. Press “p” and watch the robots move around.
This verifies that the stage plugins are working.

Verify Installation (OS X 10.6)

With 10.6, I had a much easier time installing for some reason (perhaps because I used MacPorts instead of DarwinPorts?). The only issue I found was that the STAGEPATH variable was not set, so I set that and was good to go.
$ stage worlds/simple.world
Stage 3.2.2
 [Loading worlds/simple.world][Include pioneer.inc][Include map.inc][Include sick.inc]Libtool error: file not found. Can't open your plugin controller. Quitting
err: Failed to open "wander". Check that it can be found by searching the directories in your STAGEPATH environment variable, or the current directory if STAGEPATH is not set.]
 (/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_science_playerstage-stage/work/Stage-3.2.2-Source/libstage/model_load.cc LoadControllerModule)
libtool error #2
$ export STAGEPATH=/opt/local/lib
$ stage worlds/simple.world
Stage 3.2.2
 [Loading worlds/simple.world][Include pioneer.inc][Include map.inc][Include sick.inc]

Unfortunately, while the stage plugin seems to work, the player port is broken on OS X 10.6 (see the top of this post).