Simpler Kinematic Equation

Simpler Kinematic Equation

Postby machinofacture » Thu Jun 19, 2014 10:15 pm

Hey guys,

I am half way into my own simpson build and I was wondering, isn't there a simpler, analytic way to express the GUS simpson's kinematics, to avoid iterative numerical solving? I wonder this because it would be really great to write the kinematic solutions into the arduino firmware, as opposed to doing it with a python post-processing script.

Anyway, tell me if the below makes sense:

If you consider the bot as a sort of tetrahedron, with the top point being the extruder head and the movement of the geared arms being like extending or retracting the length of the tetrahedron's edges, several key assumptions (which I think are true for this design) simplify the kinematic problem and we should be able to write an equation for it.

Assumption 1: The geared arms are like linear actuators. (I think this has been proven)

Assumption 2: the angle of the joints always forms a straight line between the point represented by the print head and the corner of the base of the tetrahedron, if you look straight down on the printer from above.

Assumption 3: un-actuated joints always stay in the same plane, parallel to the tetrahedron's base.

Here is a picture:

Image

Thus, at any X,Y,Z position, we can calculate what the angles of all the un-actuated joints should be, and in so doing find exactly what the length of the edges (and thus arm extensions and motor positions) should have to be.

I have not written the full equation yet but I imagine it will not be too difficult to do so.

Is there anything I am missing?
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: Simpler Kinematic Equation

Postby Nicholas Seward » Thu Jun 19, 2014 10:28 pm

You are quite right. The kinematics for Simpson is stupid simple. If you look at Segmentize you can see the equations. Fitting it on an Arduino is not a problem. It is effectively the same firmware as a Rostock with one sign difference.

Why hasn't this been done?
Segmentize takes a bunch of touch points and uses them to numerical solve for many parameters that would be hard to measure. It substantially different from the bed leveling that a lot of firmware seems to use.
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Re: Simpler Kinematic Equation

Postby Niggle » Thu Jun 19, 2014 10:42 pm

I suspect that you are slightly confused by the script.

There are two distinct parts to the script. The first part includes the use of leastsq, which is iterative.

The second part is much simpler. It parses the gcode file and converts any move longer then SEGMENT_SIZE into shorter segments. It then does a coordinate transform (in GetABC()) to transform a Cartesian XYZ coordinate into a spherical ABC coordinate. This is the kinematic part of the code, and it is about as simple as it can be.

The purpose of the first part is calculate the maximum length of each arm and the height of the hub bolt above the shoulder bolt for each arm. The calculation is done by a least squares analysis of the coordinates in the points array. The analysis calls equation() repeatedly until it gets an answer it likes. This actually only needs to be done once for a set of points and so the 150 iterations that I saw and not significant.

I have a version of Marlin adapted for GUS but I want to get my machine printing so that I can test it before releasing it.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Simpler Kinematic Equation

Postby machinofacture » Thu Jun 19, 2014 10:57 pm

Ok so what I was thinking about sounds like exactly what you, Niggle, have already implemented.

Awaiting anxiously your Marlin fork.

Excuse my ignorance, but how does one go about getting these touch points? Do you mount a clicky button to the extruder head? What is the most accurate way to do this?
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: Simpler Kinematic Equation

Postby Nicholas Seward » Thu Jun 19, 2014 11:10 pm

@Niggle: That is good news.

Can you allow for the switching between GUS and Cartesian mode without reflashing the firmware? Can you put all of GUS's parameters in EEPROM? If those things happen, we can just convert Segmentize over to an optimization tool.

@machinofacture: I just manually move the effector around until I can just barely slip a piece of paper between the effector and the bed. I do this for a bunch of points spread out over the bed. For each point you just record the machine coordinates.
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Re: Simpler Kinematic Equation

Postby machinofacture » Tue Jun 24, 2014 8:20 pm

Any word on the GUS-capable marlin fork, Niggle?

I would like to give it a shot. I don't care if you haven't got it printing as I don't have a hot end mounted on my machine either, but I would just like to get it moving. Getting your mod will be easier than implementing it myself, which I want to do anyway.

Thanks
machinofacture
 
Posts: 20
Joined: Tue Jun 17, 2014 12:02 am

Re: Simpler Kinematic Equation

Postby Niggle » Tue Jun 24, 2014 9:28 pm

I had a busy weekend, so no progress so far. I'll try to get what I have into my repository tonight.

Nicholas made a good point about stuffing the calibration results into the EEPROM, which I haven't attempted yet.

I find the idea of trying to pass through segmentized gcode scary.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Simpler Kinematic Equation

Postby Nicholas Seward » Tue Jun 24, 2014 9:40 pm

@Niggle: I wasn't talking about making it so you could run it with or without Segmentize. I was thinking it would be nice to switch to where you can control each stepper separately so you could get touch points for calibration. I suspect that could be hard. What do you think?
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Re: Simpler Kinematic Equation

Postby Niggle » Tue Jun 24, 2014 11:33 pm

@Nicholas
I have an LCD panel with click controller wired in to my Ramps board. The LCD support has a menu allowing fine control of each axis independently (extruder included) so I haven't needed to add any such support.

Without the LCD and click controller, it gets trickier.

I could see adding a custom Mcode to bypass the coordinate conversion.

It also might be interesting to try to add an Mcode that reported the distance from the current position to endstops triggered. So you could 1) disable the motors, 2) manually move the hotend to a touch point, 3) send the Mcode, 4) copy the coordinates from the log, 5) repeat until done.

However, I'd rather work on getting an FSR to work and then hijack the M29 code.
Niggle
 
Posts: 84
Joined: Tue Feb 11, 2014 7:27 pm

Re: Simpler Kinematic Equation

Postby Nicholas Seward » Tue Jun 24, 2014 11:48 pm

@Niggle: Sound like a good plan. I don't have an LCD on any of my printers so a Mcode bypass would be sufficient.
Nicholas Seward
 
Posts: 738
Joined: Mon Nov 25, 2013 10:41 pm

Next

Return to GUS Simpson

Who is online

Users browsing this forum: No registered users and 1 guest

cron