Native cubic bezier curves for Sprinter

Hi All

Thought this might interest a few people... I've started to add native cubic bezier curve support to the latest Sprinter firmware. So far, I've implemented a basic forward differencing algorithm (much more efficient than subdivision, but still fairly simple) that will interpret a new G Code (G5) and plot the resulting curve.

G5 parameters are of the form: G5 I0.0 J0.0 K0.0 L0.0 X0.0 Y0.0

the curve will start from current position
I/J are the X/Y co-ords of first control point
K/L are the co-ords of the second control point
X/Y are the co-ords of the end of the curve

The algorithm works by splitting the curve into a number of straight line segments and then re-using the current prepare_move() code. The number of segments is automatically calculated based on a simple heuristic, that keeps line segments within a given ratio to system units (i.e. mm) - for now I've set it to a max (approx) of one segment mm - this may be a bit extreme, as many segments are only a few tenths of a mil, but it's good for testing.

I've only spent a few hours on it and there's plenty still to be done, but even at this point it seems to work pretty well. I've been plotting out various curves (just using a pen) at a reasonable feedrate via the Printrun interface - no obvious issues. Curves are currently only supported in the X/Y plane - in fact the Z/E axis are currently ignored completely.

I've attached the code in case anyone wants a sneak preview and will post a video in a day or so.

To-do:
Extruder axis - planning to take a feedrate parameter and then use to ensure a steady feed rate over the length of the curve
Z axis - start with simple linear interpolation, not sure 3d curves are necessary on a reprap?!
Feedrate support (standard F param)
Look at optimising the acceleration calculations between short line segments

Feedback, thoughts, etc appreciated...

Dedicated blog for my reprap build/notes is at: [axrap.blogspot.com]

D

Almost forget... Here's my rather charming heart test code.... just for fun:

G28
G1 Z5
G1 X100 Y30 F9000
G1 Z0
G5 I130 J0 K150 L40 X100 Y90
G5 I50 J40 K70 L0 X100 Y30
G1 Z5
G1 X0 Y0
G1 Z0

Must make a reprap logo test, but not tonight.... need sleep

D

How would one implement this? Does a program automatically calculate the curves? I thought it would have been implemented differently and in firmware using an extra buffering trick, but this is interesting. Is there a tool to calculate the G5 code automatically so more of an audience can test this out?


I like the video you have on your blog of the table moving and the Allen wrench does not move or fall off. So something here is working. It would be of benefit to print an ellipse circle about 1cm high and 3cm wide. This would show how well your machine handles curves.

Thx for your work!

Converting cubic beziers to straight line segments isn't hard. just pick a decent sized step. See the fantastic animations on wikipedia for conceptual overview.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Now, could we get this down to single step resolution somehow?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

James - Currently I've either hand written test gcode or generated a few tests from some simple java code. Spent the last couple of evenings working on a simple SVG parser (in java), as with the addition of the bezier support it's possible for the firmware to interpret all native SVG primitives (at least after they're converted to GCode). Will hopefully have that ready for demo by next week - then you should be able to very quickly go from art in something like inkscape (or anything online) to the printer. The current videos are just early electronics test code, not based on the bezier code at all... will upload something relevant after the weekend (currently away from home).

Triffid - agreed, albeit choosing the step size can be non-trivial. The main challenge is that the simplest recursive algorithms don't fare well on an embedded processor, esp. with limited stack. The forward differencing algo's fit the bill nicely, as long as the cumulative error is kept small - i.e. there aren't too many steps.

Traumflug - possibly. I did try implementing a promising algorithm based on a chinese paper from several years ago, but it turned out to be fundamentally flawed. The recursive algos just won't work on a simple processor. and the forward differencing ones have major cumulative error issues beyond several hundred steps. Adaptive forward differencing techniques would probably be required to try and keep the segment size constant (or close to a single stepper step), but the overhead would be significant. it would also complicate calculating the extruder steps. All in all, I figured the simplest way would be to reuse the existing bresenham code as much as possible. I'm also not sure it would be that much better... as Triffid said, if you get the step size right, a segmented curve is almost indistinguishable from a non-segmented one.

Thanks for the interest/comments - should have something more to share next week.

Evening all

So... I've got a basic toolchain working and posted a short video to show the end to end process:

http://www.youtube.com/watch?v=AxBV1-kySjs

Enjoy

Awesome!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Extended the "tool" support for the bezier G5 code by adding visualisation support for the curves in Pronterface.py - also added relative co-ordinate support to the visualisation (both in gviz.py). Then felt the need to stress test the code, so vectorised one of Gary Hodgson's Prusa images and ran it through the mill...

http://youtu.be/wlsl61eo3i8

Sorry about the poor quality video, couldn't face waiting for an HD version to upload (must find a way to edit the MOV files my camera produces, otherwise even a short clip can be 400MB )

D