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

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.

--->  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

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.

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.

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….

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….!