reinoud Wrote:
-------------------------------------------------------
> Hi,
>
> looks good! I am currently working out a similar
> scheme for the delta robot. Its nearing completion
> :-)
Sounds like we might have some opportunity to steal the best bits from each other's code then.
> I've opted for a first setup/try to keep all
> the calculations onboard the Arduino just because
> its possible... not optimal i have to admit since
> it still misses some inter-move
> optimalisations/knowledge.
I briefly considered that.. translating the linear segments into model space on the extruder; I suspect you use a strategy to do a few expensive calculations (I had 1-2 ms time to compute the inverse kinematics) for course approximations, and use ultra-fast high speed splines for the details? Sounds like a great approach assuming you have the space available for the floating point (I too found the floating point bloated the code significantly.)
> Did you go for bezier splines or for B-splines?
> also taking into account double/triple nots? I
> opted myself for 3rd (or later 5th) order polynoms
> for each of the extruder stepper and the three
> steppers; they proved very easy to derive and to
> compute.
On the firmware side, it is straight 3rd degree polynomial computation driving a target point. The splines computation enter in on the host side when generating those 3rd degree polynomials; Actual strategy can use whatever scheme you like. More than likely, I'll probably start with Hermite form rather than BSpline, since all curves I'll be dealing with are differential (E.G, the kinematic and inverse kinematic formulas.) I'll test accuracy at t=1/3, 1/2, and 2/3, and if it is too far from the target points at those points, I'll split the spline in half and recompute at the point with the greatest inaccuracy, recursively. I'll also split each segment into up to 3 splines, an accelleration phase, a 'top speed' linear phase, and a decelleration phase (I.E, accellerate after coming around the corner for the previous linear segment, then truck as fast as possible along that segment, then decellerate to prepare turning onto the next segment.)
I will most likely never set the axis motors to use a velocity of 0 (unless they actually are fixed while other axies move), but rather, model maximum torque/acceleration for the physical model, and then limit the splines to always have less than some margin of error for that (I.E, it will race thru corners, rather than dwelling with velocity 0 instantaneously at endpoints.)
> Like you i'm also seriously considering removing a
> slave controller; its simply not needed :-) Even
> my Arduino Duemilianove can handle it by itself,
> let alone a Sanguino!
My only concern with single control is the number of available IO. For my repstrap, I'll need 5 or 6 pins each for X + Y (11 pins minimum) -- 3 encoder inputs and the STEP + DIR + EN. Adding in the Z stepper, extruder stepper, temp, fans, solinoids, and other gadgets, and I start to get a little worried -- though, I do have a Mega available, so I doubt I'll run out if I use that.
> As for the host software, are you considering
> sticking to the raw G-code you input keeping the
> line segments or are you contemplating curve
> fitting to get nice roundings? or do you even
> consider writing your own slicer?
Sheesh, it's gonna be hard enough getting the firmware alone, and now you want me to write a slicer too? Okay, maybe I've thought about it myself.
Short term, I'll simply port the GCode parser to the host, and write a backend that generates splines. The protocol I use with the firmware is very simple; everything is a spline so it is just sequences of velocity, accelleration, and jerk, and occassional 'step this many times with the current spline set' command; oh, and a few extended commands to query current board state. I will not be sending temp pings, etc. back to the host.. if the host want's to know it, it will ask for it. So fans, solinoids, steppers, heaters, etc. will all use a spline, and specialized controllers to interpret those splines into the desired output (Steppers will step to the target, PIDs will approach the target, On/Off will simply have targets of 0 or 1, etc.) This isn't the most efficient, as it incurs an overhead of 20 bytes RAM and the 15microsecond for spline compututation, but even there with my limit of 26 controls, that is still < 500 bytes RAM and .4ms overhead (And I doubt I'll configure for all 26 controls, at least not until I add 2 extra print heads with their own Z axis
). I think it should still zip along nicely.
I believe using GCode will afford the greatest compatibility with existing RepRap software, leveraging all the hard work others have already done.
Edited 1 time(s). Last edit at 02/18/2010 10:53AM by BeagleFury.