Tag Archive: inverse kinematics


aar-arm

Well, as the title suggests, work on the Senior project has been progressing at a lazy pace, but a few developments have spurred me back in action. First, my project has been selected for the final 20 projects to compete at the Jed-I challenge. Second, the official project submission deadline is approaching. Fast.

So, developments. I’ve started work on a more structured manner – Have set up a git repo and a proper debuggable python environment within Eclipse. The last post showed the SCORBOT ER-4U robot building the ikfast TranslationDirection5D library database for itself. This ik solver is used since the robot has only 5 degrees of freedom, which severely curtails the available 6D space for effective manipulation. Hence this ik solver works from a given destination point and direction to approach it.

After playing around a bit with the python files I observed that very few grasps managed to return valid ik solutions. Even deleting the generated ikfast files and rebuilding the database didn’t help. What puzzled me the most was that even a very small displacement failed to return a solution.

On setting openrave to verbose mode it turned out that the wrist joint was colliding with the gripper:

Self collision: (ER-4U:wrist1)x(ER-4U:gripperLeft) contacts=0
[odecollision.h:687] selfcol ER-4U, Links wrist1 gripperLeft are colliding

So, here since the jaws are colliding whenever I use the cube’s coordinates as my target point, on an arbitrary valid target point, the arm moves correctly and along the specified direction.

I also need to adjust my CAD model as the wrist attachment’s top is interfering with the lower arm, and the grippers are actually more easily modelled as revolute joints, and not sliding joints as I had initially thought. I’ll also increase the initial gripper opening as suggested by Rosen here

UPDATE: It turned out that the collision was happening because I had a virtual wrist that rolled, to which the wrist attachment pitched up and down. So, what this was doing was that whenever the virtual wrist (wristZ) rolled, the pitching axis of the wrist attachment also changed, so that any pitching movement would lead to the wrist obliquely colliding with the forearm. To amend this, I split the wrist attachment into two parts, with first wristX pitching up and down, and wristZ then rolling about that axis (the grippers are attached to wristZ). Here’s a screenshot of the new model in action. This has also eliminated the occasional wobbling of the arm during a move.

The updated CAD model. Note that the grippers have become revolute joints, and the wrist attachment has been divided into two subparts – wristX is the projecting portion behind the differential gears and wristZ the part in front, to which the grippers are attached. Also note the small 1 mm clearance I introduced between the differential gears.

Advertisements

Dis-arm-ament

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