Kinematics task

[GoogleCodeExporter]

Investigate implementations of:

*Forward/Inverse Kinematics
**Position
**Velocity

*Path planning/Trajectory
**G-code
**Cartesian space interfaces

Original issue reported on code.google.com by Mad.Hephaestus@gmail.com on 17 Dec 2011 at 5:20

[GoogleCodeExporter]

Original comment by Mad.Hephaestus@gmail.com on 17 Dec 2011 at 5:29

[GoogleCodeExporter]

Any progress on this?

Original comment by Mad.Hephaestus@gmail.com on 1 Jan 2012 at 9:52

[GoogleCodeExporter]

I've emailed Nestinger and his team to set up meetings about this stuff.
Also I have 2 MechE that are interested in helping out.
I found a good kinematics resource I posted in the wiki
Unfortunately I've been ill this week, feeling better now so I'll be working on 
it in earnest before the next meeting.

Original comment by alixens...@gmail.com on 2 Jan 2012 at 1:31

[GoogleCodeExporter]

alixenshen and I met yesterday to work on the kinematics. Relevant things that 
came up:
* Raw minimum change in angle across all axes being below the minimum angle is 
not a problem so long as at least one axis is moving by a sufficient amount and 
the error from discretization through the kinematics does not exceed allowable 
error.

Also, during and shortly after meeting I threw together an octave sketch of the 
position kinematics, which I am attaching here. The forward kinematics is 
rederived with the tree-sphere intersection at 
http://en.wikipedia.org/wiki/Trilateration - I'm seeing error of .09mm at some 
points with a 2^13-count-per-rotation encoder, well within the range that light 
gearing could resolve to meet .1mm.

Original comment by jono...@gmail.com on 10 Jan 2012 at 9:46

Attachments:

• kinematics.m

[GoogleCodeExporter]

Original comment by Mad.Hephaestus@gmail.com on 19 Jan 2012 at 7:41

• Added labels: Milestone-feasibility

[GoogleCodeExporter]

Less matlab-ish and more english&math explanation of the forward kinematics I 
threw together.

Original comment by jono...@gmail.com on 19 Jan 2012 at 10:06

Attachments:

• kinematics.pdf

[GoogleCodeExporter]

Original comment by Mad.Hephaestus@gmail.com on 22 Jan 2012 at 3:52

• Changed state: Started
• Added labels: Milestone-FeasibilityAnalysis
• Removed labels: Milestone-feasibility

[GoogleCodeExporter]

Nestinger has been contacted regarding pro/cons of 3 or 4 arm delta robots.
Forward Kinematics for 4 arm system have been determined to be over constrained 
and as such impossible to solve.

Inverse kinematics code for the 4 arm system will be committed to the SVN once 
my repository bug is squashed.

Jono has most of a sufficient G-code parser to handle the G-code that all of 
the reprap crowd's driver software produces, in java.

Jono's math based on the numbers I put up on the board for the initial testing: 
Looks like for a 100mm cube centered x and y and from -200 to -300 z it's 14 
degrees through -75 degrees from horizontal.

Original comment by alixens...@gmail.com on 24 Jan 2012 at 12:30

[GoogleCodeExporter]

The velocity kinematics simplifies beautifully when you do it via implicit 
differentiation of the kinematics system of equations.

Original comment by jono...@gmail.com on 3 Feb 2012 at 8:04

[GoogleCodeExporter]

Original comment by jono...@gmail.com on 3 Feb 2012 at 8:05

[GoogleCodeExporter]

Original comment by jono...@gmail.com on 5 Feb 2012 at 1:40

[GoogleCodeExporter]

Math and prototyping for kinematics is essentially done. I'm going to spin off 
a task for writing an implementation in whichever of microcontroller C/C++ or 
Java is relevant. G code parsing and such isn't really related to the 
kinematics, so that'll go somewhere else too.

Also, I suspect that I can get acceleration kinematics for the whole machine 
together and compute live a theoretical required torque at the motor if this is 
useful information for the control loops.

A form for sending data through the octave prototype is up at 
http://tcita.com/~jonored/nr-replicator/UI.cgi and the octave code itself is at 
http://tcita.com/~jonored/nr-replicator/kinematics.m
This may change to a different address on a beefier machine at some point in 
the future, as doing the slop error calculations this way is a bit expensive.

Original comment by jono...@gmail.com on 15 Feb 2012 at 6:21

• Changed state: Done