RepolaRap splines - performance

Still making progress on firmware for RepolaRap spline segment strategy.

Firmware Currently has:
4 axis stepper control
parsing for splines path buffering / execution
reliable comms from host to firmware; using windowed packets and crc

Code Size at 9186 bytes. Main loop, performing spline steps for 4 steppers, and assuming an extremely noisy spline (I.E, a stepper direction change and/or step with each iteration) still at around 5000 iterations per second (1500+ RPM limitation for full step steppers) Even with half or quarter stepping, this still feels like I have plenty of room for the print performance.

Firmware Still needs:
Encoder input logic and feedback into controllers.
PID controller template for temp + potential for servo.
homing commands / parsing

Host side still needs pretty much everything; GCode Parser, motor physics parameterization, spline translation and segmentation, etc.

I currently also have assumed that all motor commands driven from a single motherboard, rather than the separate slave extruder driver board. I may need to address this by adding a separate controller type, a slave controller, that transmits a target position over the communication channel to the extruder slave. I'm not sure how this will affect the performance of my inner loop if I need to do this. Certainly there could be strategies that would minimize this impact (I.E, have a master 'clock' signal that drives all slave boards to keep everything synchronized.)

Hi,

looks good! I am currently working out a similar scheme for the delta robot. Its nearing completion :-) 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. The Arduino however is having plenty of time to spare. As for code side, it still got plenty of space over, but the calculations code is taking up more space than i anticipated :-/ It is nearly a 8kb more due to all the floats About 50% of the Flash free

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.

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!

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?

With regards,
Reinoud

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.

Okay, have spent another good chunk of time on the firmware. Tried to get Triffid_Hunter's serial into the mix; unfortunately, it looks like it doesn't work on the Mega (port/io wrong, I'd guess). Rather than spend too much time getting it to work, I'm shifting back to the Arduino provided serial comms; my logic has reliable transfer, so losing bytes or having noise just slows things down, no garbage gets passed into the spline engine. I'll work on that later when I'm closer to having a full working hardware platform.

I removed all command line stuff, and switched to fixed sized packets, feeding an extremely simple byte-code interpreter to drive the spline engines. I'll consider re-adding a command line interface later, maybe..

Also, unfortunate -- the Arduino hardware Serial adds 2K to the program size. With Triffid's code, I got the firmware size down to 5.1K total. With arduino HardwareSerial, it jumps to 6.8K. It appears division, mod, and other ugly functions get added, as a result of it trying to figure out the best hardware profile to use for the baud rate specified in the Serial.begin(..) call. They'd really do better to get rid of all the nasty divisions trying to figure out clock/skew rate. Even better, allow a compile time BAUD rate specification, as Triffid did, and the overhead drops to nearly nothing.

On the host side, I have not progressed much further beyond a tiny baby stage... It can talk to the board (it sends a SYN, and the board responds with a SYN+window+available buffer space.) That works very nicely. Now, I just have to send it some real meat -- splines, and re-hook the motors up. I think I may just create some algorithmic spline paths to test platform repeatiblity, and print speed. As I still don't have encoders, it's not going to result in straight lines -- but that doesn't matter for testing the spline logic .. even without encoders, I should be able to approximate angles to steps on the steppers to get something reasonably euclidean...