### Software for inverse parallel kinematic equations

Hacker404 wrote 05/11/2017 at 05:18 • 0 pointsI am looking for software for inverse parallel kinematic equations.

I found lots (including OpenRave) but everything seems to be for series robotics and not parallel.

The Project is a half inverted arc delta robot, here -

https://hackaday.io/project/18186-arc-delta-3d-pcb-drill-and-other-failures

I really don't want to re-invent the wheel with this and I haven't studied kinematics so to do the math will be a challange for me.

## Discussions

## Become a member

In order to follow projects & hackers or give likes

Already a member?you need to create an account.

You say you don't want to reinvent the wheel, but it turns out that it's not so complex after all. It's literally just a bunch of simple equations. I recently tried to work them out myself, and I tried to explain what I learned here: https://hackaday.io/project/20379-deltabot/log/55101-inverse-kinematics-redoux

Are you sure? yes | no

Thanks, I am reading this now. I was trying to use only Pythagoras and sine law in integer math on an 8-bitter and that may be too much of a challenge. My math is rusty as I did those studies almost half a century ago.

Are you sure? yes | no

In that case you will probably also want to take a look at https://hackaday.io/project/6050-tote/log/50664-cordic and https://hackaday.io/project/6050-tote/log/50708-imathh

But I would first get it to work with floats.

Are you sure? yes | no

Your kinematics may work for a very small x-y build envelope with some error. The greater the movement in the x-y (x^2 + y^2) plane the greater the error because the kinematics are incorrect.

Because you have chosen such small arms and long rods that may not be an issue for you especially given that you are using servos that will introduce a high level of error anyway.

Your formulas assume that the rods are in the same plane as the servo pivot plane (or arm) when they in fact different planes depending on the Cartesian coordinates needed. The tips of the rods (end effector) are only in the plane of rotation of Arm(s) when x = y = 0

There are two ways of correcting it -

1) adjust (reduce) the length of Rod to compensate for the fact it is shorter in the servo pivot plane when the two rods are most offset diagonally.

2) assume the plane given by servo - arm - rod - servo, and compensate the angle of servo given that the servo pivot plane is different to servo - arm - rod - servo

All the same you have a very neat solution and the math should be fine given the high error of servos. The problem would them be the z-axis but with such short arms this shouldn't be a big issue.

Are you sure? yes | no

You are right, I completely missed this. I will have to fix that, thank you for pointing it out.

Are you sure? yes | no

You have given me an idea about how to do this with just #define for cos30 and cos60 and sqr/sqrt and Pythagoras

Are you sure? yes | no

Have you tried the KDL Library from Orocos, that is inside ros now?

http://wiki.ros.org/kdl

Are you sure? yes | no

Thanks for that. It's an impressive package and it's going to take more CPU horsepower than I intended but I will just have to accept that.

Are you sure? yes | no

ah sorry. i missed that requirement. kdl is huge and you are "buying" a whole ecosystem with it. its more for something >= beaglebone

Are you sure? yes | no

I will give the 8-bitter another go, just because that's the way I started. I expect a 16 MIPs 8-bitter will be too slow anyway but I will try the math there first as an exploration.

I think your right that this isn't going to work well with anything less than a 32 bitter with a bit of horsepower lol.

Are you sure? yes | no