Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit)

For this robot (Haddington Dynamics' Dexter), I downloaded the Collada/.dxf files from: https://cad.onshape.com/documents/2af8ed0e61a34ebf...

Then, I arranged all the parts into a transform hierarchy in Unity3D (a popular game engine), and rotated the models such that they were all pointed upward when their joints were in the identity rotation.

Then I wrote a simple Constrained CCDIK solver that orients that transform chain to touch the pink sphere. The source for that is available here: https://github.com/zalo/MathUtilities/tree/master/...

The version in the embedded demo simply attempts to find the minimal rotation necessary to make the tooltip match the sphere, but the one in the above source also attempts to match the direction that the sphere's forward vector is pointing (since this is a 5-DoF robot after all). You can disable that functionality if you want by simply deleting ", j < 2" in the CCDIK.cs file (this tells it to treat the last two joints differently than the rest).

The above github repo replaces the Dexter models with scaled cubes because the Dexter models are licensed funnily and they ballooned the file size.

If you decide to stick with Python, hopefully you have a good technique for representing transform hierarchies and ways of constructing rotations from a pair of directions. Here's a good place to get started on implementing that function (since my world-space CCDIK makes extensive use of it: https://web-beta.archive.org/web/20161105145605/http://lolengine.net/blog/2014/02/24/quaternion-from-two-vectors-final ).

Thanks a lot for your extensive response. I still need to spend more time digesting the pieces of your code and articles that you mentioned, but they seem to address most of my concerns.

My robot arm has also 5 DOF, very similar to Dexter. The way I handle inverse kinematics is by matching the orientation of the object that needs to be picked up with the last two DOF's (I think like what you have done for Dexter). For the rest of the 3 DOF's I've written down the transformations in terms of joint rotations and have solved them explicitly for a given target position. But I think the systematic representation based on quaternions is much cleaner for implementing the transform hierarchies and are easier to extend them later.

For now, I'm planning to stick to python, because of the other constrains including the interaction with the hardware (Arduinos, sensors,...) and also other available math libraries like opencv. But on the downside, creating an attractive and interactive 3d graphics seems to be a pain in python. But I think at some point I should find a way to either use external tools for handling the graphics or instead write the whole thing as a web application and use Unity for handling the graphics.

Excellent work!

I'm not familiar with Unity3D and i'm also developing my own Dexter control software with regular javascript and WebGL renderer.

Maybe you can share some sources and save a lot of time for others who also doing the same job?)

I'm not interesting in inverse kinematics  algorithms because I know how it works. I need model of the Dexter in any  usable format witch I can import in the Three.js scene.