Armature IK-chain workaround. Anyone?


I’ve got this robot emulator, which is implemented in the embedded Python interpreter, and commanded in real-time over ZeroC Ice. Everything works fine. The kinematics for the controller of the robot is implemented in the Python controller, as well as various canonical controllers, such as 6D-tool velocity, tool-linear, and, of course, joint control. It uses a serial equivalent of the real kinematics of the controlled robot. The real robot kinematics has, like most medium to larget industrial manipulators, a parallelogram linkage on the upper arm. I haven’t modelled it, since it plays no significant role. However, it would look nice, and more natural, as long as it does not sever the performance.

So, I made the linkage with an armature, very easy, works as expected in the modeller. However, I then went on discovering that there was no motion of the linkage in the game engine … scratch my head … To the fora! Seems a lot of people are waiting for the IK-solver of the armature chain to be available for having its target as a game engine object. Is this an upcoming feature? And will it work on 2.49x?

If not, are there any workarounds? Say we got blender object boA and boB, which gets an armature rooted at boA and solving for IK-target boB. Is it possible to get the armature translated to the corresponding game engine objects goA and goB, as the game engine kicks in? I read some suggestions about solving the IK chain for a floating bone. But it seems that I cannot make that floating bone follow the target object goB.

Best regards,
Morten Lind.

Try Walkomatic You will get in the forum.
My Walkomatic Walk with Blender, How it is?

Thanks for the reply, Patricia. However, am I right, when I say it seems that walkomatic is for animation only? The script ( deals only with Ipos and blender objects, not game engine objects. So, it will not make the armatures work in the game engine, right?

Update: I tried to put an empty as the target for the IK-solver. The python code that controls the placement of game engine parts for the robot was modified to let the blender object for the empty always follow the corresponding game object for the empty. However, the blender object does not get updated during the game engine execution. At game engine exit, the new position of the blender object for the empty is finally updated, to a now wrong position, and the armature follows. HMMMM … dang.

External targets for bone constraints work in 2.5. Also what are you using to move the object? It sounds like you are moving the blender object instead of the game object.

@Kupoman: I tried first to move the game object. That didn’t work, so I made a version as described, where I move the blender object from the python controller. That didn’t work either …

@Kupoman: I now tried a simple setup in blender 2.53. Two bones, two mesh objects parented to the bones, a cube on top set as target for the IK-solver. Works fine in the modeller, but nothing happens in the game engine, with the cube actuated by a simple motion actuator, activated with keyboard input sensor. Do you know if this should only work in newer 2.5x-versions? Or is there some special setup for making it work, besides just an IK-target for the armature?

So, I finally got around to reading the whole of the iTaSC page at I deemed it irrelevant the first time I came across it, since sufficient functionality of the armatures was already in the legacy IK-solver. It turns out that the desired operation of the armature in the game engine is achieved with a startup-triggering (Delay-sensor) of the “Run Armature” actuator.

That was wonderful to find out, and thanks to Benoit Bolsee for the iTaSC page!

The “Run Armature” actuator is only in 2.5x, and I am stuck with 2.49 for the time being. Reason: My entire implementation depends on ZeroC Ice and NumPy. These are, currently in Debian testing/unstable, unavailable in versions compatible with Python 3.x … So, I’ll be waiting around a while :slight_smile: