Like I probably mentioned earlier, for my Senior project I’ve decided to work on visual servoing of a 5+1 DoF arm (It’s a SCORBOT ER-4u. Found one gathering dust in the CAM lab at college) The objective was to use only a monocular camera mounted on top of the gripper to servo the arm, but due to time constraints I shall be adding an overhead camera to obtain poses more accurately. This is a long overdue post, so brace yourself :P

One of the first things I decided on was to utilize the OpenRave framework – I had read a lot about it, and was even recommended to use it by Pras. The most nifty feature of OpenRave is its ikfast module, which is a ‘Robot Kinematics Compiler’ that analytically solves robot inverse kinematics equations and
generates optimized C++ files for later use that are highly reliable and fast. The performance of this very promising module seems phenomenal – ~5 ms evaluation time is what the official docs say.

So, then, the next step was implementing the ER-4U bot within OpenRave’s framework. I couldn’t really find CAD models that were useful (EDIT: I did find one on the SCORBOT Yahoo groups page, but it didn’t seem clean enough) and also since I wanted to model the robot myself I created a CAD model on SolidWorks. Now, OpenRave can recognize COLLADA files, and I was happy to see the SolidWorks plugin that did export to COLLADA, but the plugin version (1.4) was older than that which OpenRave supports (1.5) Although I could get the model to render in OpenRave by fiddling with the header, the issue was that OpenRave could not understand what the links and the joints were, so I couldn’t say, rotate the links about their joints.

A plain COLLADA 1.4 import into OpenRave. Note that there is no relationship defined between the links - If I start the physics engine, everything starts flying off.

Turns out that to get around issues like this, OpenRave allows you to define robots (that are essentially kinematic chains, or KinBodys ) where each sub part of the assembly is defined as a link. So, taking a cue from this blog I set about splitting the SCORBOT CAD module into separate WRLs and importing their geometries in my xml file. The WRLs then simply act as the textures used for collision detection and trajectory planning, while the underlying math model is derived from the link info that is added to the XML file.

On my first attempt at getting this working, I managed to get the joints in place, and the parts imported into OpenRave as separate entities, but with a very glaring error – the references between links that I used were in arbitrary orientations on Solidworks. Now, when OpenRave imports the WRLs, it just adds them to the scene in their native coordinates – thus giving the very staggered view as can be seen in the screenshot. Looking at other sample robots it implies that I’ll have to reorient all my sub-assemblies to the same local coordinates (like all pointing in the positive X direction) and to take measurements between the links with the entire arm, say, horizontal, or vertical.

As can be seen, because the relative distances I set in the XML file were according to a specific viewpoint in my overall assembly, and because OpenRave renders the sub assemblies in their local coordinates, all my parts are located with the wrong offsets. This will be remedied by taking measurements from an assembly wherein all the links are stretched out in one direction.

For the SCORBOT ER-4u, Intellitek has done away with the traditional serial interface with a proprietary
USB controller. This severely restricts use of third party applications to access the robot, as unlike with a serial port, commands cannot be simply sent via a terminal. Fortunately, some developers have been able to reverse assemble the DLL file and trace basic method calls (This file). Compiling against this dynamic library enables access to high level functions of the robot arm as well as access to servo PWMs. However, this will restrict implementation to the Windows environment. I’ll be looking at trying to run it under WINE on linux.

As far as interfacing with OpenRave is concerned, OpenRave provides a CPP interface and hence it is a
trivial task to connect the methods of the USBC DLL and OpenRave. However, I haven’t implemented that yet.

UPDATE: Things have been progressing – head over to the this OpenRave users list thread that I started. Rosen Diankov is awesome.

UPDATE 2: I’ve finally got it to start finding the IK solutions! Here’s a fun video of it in action :)