This is where I work, and yesterday if you haven’t already seen it on the news, we had our official opening of the new lab. It is now the biggest robotics research facility in the UK and potentially Europe! Here is an extract from a BBC report, via robot-house.co.uk. The TACTIP project mentioned is my research project…

Today saw the official opening of the Bristol Robotics Lab, the largest of its kind in the UK. Home to a huge variety of projects, from swarm robotics to biologically power robots, haptic sensors to robots with whiskers and pretty much everything in between is situated at the University of the West of England.

The project is a joint partnership between the University of the West of England and the University of Bristol, it is home to 70 academics and business with a variety of specialities, making for a diverse and creative environment where the forefront of robotics is being made.

“As well as electrical engineers and mechanical engineers, which you’d expect, we’ve got microbiologists, neuroscientists, surgeons, even psychologists,”

– Prof Chris Melhuish

Projects such as the biologically inspired rat robot, Scratchbot, was developed by researchers from the BRL. Designed to utilise its whiskers to detect its environment in search and rescue missions where other sensors may fail such as in the dark or smoky rooms.

Another innovative project is one designed to simulate the biological sensory input of the human finger, known as TACTIP. While much research has been done in to simulating the way humans move in the form of robotic arms, torsos and legs, they often still have trouble grasping delicate objects due to little or no feedback. This project hopes to enable these actuators to be used to a greater extent and opening up new directions.

Other research projects can be read about in more detail on the BRL website’s Research Projects page.

While the laboratory is the largest in the country, those behind it say more investment is needed to allow Britain to compete in the robotics market globally, which is dominated by Japan.

More information can be found at the Bristol Robotics Lab website and be sure to check out the video on the BBC link below.

BRL Website

Via: robot-house

So why all this Ogre3D, Kinect, OpenCV and Mac OS X? this is why, I have been preparing work for Chris Dickinson. You can see it Friday 18th at Bristol’s watershed venue.

Using eclipse or visual studio I am used to using post build scripts to move or edit any files after building my code. Xcode does not make this quite as easy as just an option in project settings. It can be done though. In a recent post I talked about rpath and install_name_tool to correct any libs packaged in to the mac application bundle. Until now I would use a separate script outside of Xcode to make these changes once I had built my app. XCode offers a run script build phase, but this doesn’t run post build, so changing files that don’t exist yet with inevitably fail. There is a way round this to automate all processes in one go.

Firstly make a new target of type shell script target.

To this, target add a new run script build phase that will call your custom shell script which in my case alters the libs with change_name_tool.

You now have two separate targets to run individually, but you want this to run all in one go. So you need yet another target, this time it is of type Aggregate. This will run multiple targets one after the other.

Like with other XCode targets and phases, drag the targets you want to build in to this new aggregate target in sequence.

Now when you build you need to select this last aggregate target as the build target. It will build your application first and then call the script target after build.

To install opencv through macports its the usual sudo port install opencv. If you already have an old version of opencv you will get the following error;

--->  Computing dependencies for opencv
--->  Building opencv
Error: opencv 2.3.1a cannot be built while opencv 2.2.0 is installed and active.
Error: Please deactivate opencv 2.2.0 first.
Error: Target org.macports.build returned: incompatible opencv version active
Log for opencv is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_opencv/opencv/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

Using activate you get;

sudo port activate opencv
--->  Computing dependencies for opencv
--->  Cleaning opencv

So deactivate with;

sudo port deactivate opencv
--->  Deactivating opencv @2.2.0_0
--->  Cleaning opencv

Then try sudo port install opencv again… it works!

sudo port install opencv
--->  Computing dependencies for opencv
--->  Building opencv
--->  Staging opencv into destroot
--->  Installing opencv @2.3.1a_3
--->  Activating opencv @2.3.1a_3
--->  Cleaning opencv

I think I may have cracked it…

The problem is, when compiling against 3rd party libraries in Xcode, the rpath search path for libraries that the executable uses to find libraries first, is inherited in from the library itself. So if the library is in /usrl/lib thats where the executable will look. Thats fine if the machine running your code has the library installed, but in the fashion of how Mac OS X makes application bundles with all dependencies residing inside, this doesn’t quite work. In fact xcode provides a copy build phase for libs/plugins. So you copy your libs across and yet your already compiled code does not know to look there.

The solution is to use install_name_change on both the dependencies and the main executable. Lets deal with your dependencies first. I will assume they are now all in the same plugin folder post build code.app/Contents/Plugins/…

Using otool -D lib.dylib returns the path that is presented by that library to the compiler. To change it you can use install_name_change with the argument -id.

install_name_tool -id “@executable_path/../Plugins/lib.dylib” lib.dylib

This alters the relative path of lib.dylib to the plugins folder of your bundle. Next you need to change each path in the main executable. You can find out the dependencies and their expected path of the executable using otool -L. For each dependency that needs changing use install_name_tool again with the argument -change.

install_name_tool -change “/usr/lib/lib.dylib” “@executable_path/../Plugins/lib.dylib” applicationname

This passes in the current expected path(found out using otool), then the new path, and finally the file you wish to make the operation on. Once you get a few libs worked out its worth chucking it in to a shell script to save you time. It seems odd to me that XCode does not make this easier for you considering how it encourages self encased bundles so much. There may be a more elegant way to do it, but I have not found it let.

I have been banging my head against the table trying to port some code from ubuntu to mac os x using both the ogre and openNI libraries. Although I used XCode quite a lot, its never to create gui type applications, and when it has been its been using GTK graphics libraries. So it seems that Ogre requires access to the Cocoa API to run on OS X, much to my original thought that I could get away with not using object-c. In my pursuit I discovered a few useful tricks about XCode that are worth remembering.

Firstly the project setting tool in XCode is perfectly functional but sometimes a bit hard to navigate and lacking in the ability to source control the configuration. There is a more elegant and effective alternative though. Reading this great post it explains how to use xcconfig files, as a text based settings file that you can add comments to, and of course source control. This simplest way to start is to create a new xcconfig file, and literally cmd+c cmd+v from the settings window in to the file. It then translates the settings window parameters in to the variable names. Using this as a base you can configure and specifics yourself. Then when you have your config file ready, open the settings for your target, and in the bottom right there is a small drop down to assign a config file to that target’s build.

It can be as simple as this

//
//  Shared.xcconfig
//  OgreCocoa
//
//  Created by AstroBoy on 22/04/2012.
//  Copyright 2012 __MyCompanyName__. All rights reserved.
//
 
ARCHS = $(ARCHS_STANDARD_32_64_BIT)
SDKROOT = macosx10.6
ONLY_ACTIVE_ARCH = YES
 
PREBINDING = NO
 
HEADER_SEARCH_PATHS = /opt/local/include/ /usr/include/ni /usr/include/nite /OgreSDK/Dependencies/include
LIBRARY_SEARCH_PATHS = /usr/lib /opt/local/lib/ /OgreSDK/Dependencies/lib/Release
 
GCC_OPTIMIZATION_LEVEL = 0
GCC_C_LANGUAGE_STANDARD = gnu99
GCC_WARN_ABOUT_RETURN_TYPE = YES
GCC_WARN_UNUSED_VARIABLE = YES

The second thing I noticed is that there is a naming conflict between openframeworks and ogre3d. Openframeworks provided a good easy way to install the openNI libraries with an ofaddon, but it was cheating a little bit. So I have just used to installed openNI drivers from openNI.

Finally whilst trying to ignore objective-c and use normal c/c++ I tried to link to the Ogre library files without using the framework provided by the ogre sdk, I came up against rpath(unix) issues, or LD_DYLIB_INSTALL_NAME(Xcode). rpath is a parameter applied to a library at compilation then determines where the library can be found during execution. So for example, this works well with the XCode bundle system where you can place your libraries in the ../Plugins folder. This means the system LD_LIBRARY_PATH does not need to be set to the location of the libraries, because when you compile the main executable against the library it will know where to look during execution. Of course, this works when you set it during compilation of the library, and realise you needed to do so. If you are unsure of where an executable is going to look for its dependencies you can use ldd(unix) or otool(mac) on the file to display the search paths (see a previous post). Anyway, if for any reason you want to set this in XCode, there is a setting called D_DYLIB_INSTALL_NAME, which should be set to something like @executable_path/../Plugins/libx.dylib, if you are going to place libx.dylib in the plugins folder of the bundled. Also make sure you place this library in a copy build phase within XCode.

Next time I should finally have a working example of openNI working with Ogre3D through XCode as a distributable application.

Want to find out the dependencies of an executable? on the command line use ldd for linux, or otool for mac. This will give you a list of all the libraries that the executable needs and whether it can find them. Its very useful when things dont link up!

Apparently I am too lazy to walk from one desk to another, so I wanted a way to graphically ssh from my macbook to a ubuntu unit. Having done this linux to linux before it pretty much works out of the box after you install openssh-server through the package manager. Next just type ‘username@192.168.0.11 -X’ where the username is an account on the machine and IP is the IP of the host machine. The -X argument pipes the graphics from any application you load through to your client machine.

Mac os x doesn’t use the same graphics tools as linux, but you have an application that does, X11.app. so open up a terminal in os x and ssh -x to the host, enter your password. You should be at the user account home. Try a simple gui program such as xeyes or gedit. It should open up the X11 app which will in turn load your app from the host machine.

At the first try this did not work from the os x terminal, complaining about gtk errors. I opened up X11 standalone, and used its built in terminal. This worked fine, so I closed down X11, and tried with the os x terminal again and it worked. You may just need to open X11 once before trying this. Anyway, evidence….

I might be using Ogre3D as a rendering tool for a kinect project. Ive used it on windows and linux a couple of years ago but not mac os x 10.6.8. Here is how to build from source with XCode.

1. Download 1.7.4 source for linux/os x and dependancies http://www.ogre3d.org/download/source
2. Follow ogre_src_v1-7-4/BuildingOgre.txt. The pre-built dependancies were enough for me.
3. Open Ogre xcode project created by cmake in the new build directory
4. I noticed in one of the cmake file I looked at “# CMake 2.8.2 has a bug that creates unusable Xcode projects when using ARCHS_STANDARD_32_BIT” … so make sure make only for 64 bit.
5. If not all the targets build in one go, then build them individually starting with ogre main.
6. The samples are built as libraries kept in lib, and the demo application is in bin.

see….!

I constantly tell people to use Doxygen (a great time saving auto code documenting tool). It works great in most IDEs but not Xcode because Xcode does not recognise the syntax layout used by Doxygen. I just discovered a solution! If you go here someone has made a great Ruby script to auto generate the comment templates in response to a short cut key. It wasn’t quite perfect for me though, because it missed out the ‘*’ and indentation spacing so I made a few modifications. My version is here.