Archive for April, 2012

After Effects

‘Twas a balmy April
a Greek wedding
and its After Effects

All development work came to a screeching halt this April as my cousin got married. Amidst the hoopla and hype of an inter-national wedding, I got to dabble with Adobe After Effects to make a wedding presentation for the beautiful couple. I had been meaning to jump in for the longest time, but the intimidating UI (and more importantly, lack of time) held me back.

So after a day and a half’s worth of online tutorials and stumbling through the dark, here’s the final result!

After Effects definitely lived up to its hype and my expectations. There are loads of cool stuff in this presentation that I worked on – The intro image has been layered off to provide a 3D perspective (note how crudely I’ve stamp tooled the background), the photos are all staggered in 3D space and there’s a particle field in suspended growth which looks really nice with the motion blur. Manipulating the camera movement was a real pain, and loads of painstaking keyframing and readjusting the photos was required to get it to work (which is why at some places I was forced to give up). Shallow depth of field helps focus the attention well, and a random ‘camera shake’ provides a sense of dynamism to the presentation.

p.s. the title was shameless copied from a tutorial.

In other news, work on the senior project hasn’t really progressed as I finally had to start attending college (shakes fist at the final semester) as there are only a few weeks of studies remaining. I also winded up my intern at Hi Tech as I couldn’t really find any more time to go there. Pity that I couldn’t complete the work on the full scale setup that they now have :( (Shakes fist at the Autoexpo and its consequent delays)

Oh, and I’m heading to the RISS program again! Yay! :D I’ll be working under Prof. Drew Bagnell on the BIRDS project where the objective is to use ML magic to help MAVs navigate through densely cluttered environments like forests using only on board vision. *Very* interesting :)


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