Rostock delta robot now moving at 400mm/s

I'm working on a new delta robot 3D printer prototype called Rostock. It's still a very early prototype but it's now moving pretty reliably up to 400 mm/s.






Build volume: 8x8x8 inches (20x20x20 cm)
Extendable: 8x8x15 inches (20x20x38 cm) by using longer timing belts only
Footprint: 12x12 inches
Speed: currently up to 400 mm/s in all three directions
Positioning accuracy: 40 steps/mm for Z, around 30 steps/mm for X and Y
Electronics: RAMPS 1.4
Firmware: unmodified Marlin (planning to fork and implement realtime Delta geometry)
Endstops: 3x top, 3x bottom ZM micro switches (adjustable with M3 screws)
Steppers: 3x NEMA17
Timing belt: GT2 TruMotion belt, 2mm pitch
Smooth rod: 6x 8x762mm drill rod
Linear bearings: 6x LM8UU
Ball bearings: 6x 608 (skateboard bearings)
Plastic parts: printed with PLA on Prusa Mendel

Today's demo video, taken at metrixcreatespace.com in Seattle:
flickr.com/photos/metrixcreate/7028636503

More pictures (slightly older so they still have printed PLA parts instead of LM8UU):
flickr.com/photos/jcrocholl/tags/rostock

OpenSCAD source files, some documentation, comments, more pictures:
github.com/jcrocholl/rostock
thingiverse.com/tag:rostock

Looks a really neat design. I was wondering how good a belt driven delta would be and it appears that the movement is very good and quick unlike my lead screw driven one. The universal joint implementation is also really neat. Has it shown any signs of wear yet? I also like the labyrinth method for attaching the belt to the moving carriages.

I was wondering about your choice of firmware. Using Marlin as a base may be the wrong thing to do. A linear move in a delta does not mean motor steps are equal like in a cartesian robot. This was a restriction which is why I implemented a time based algorithm in my Helium Frog robot rather than using existing code which pre calculates the step times. The firmware is on the link below should you want to give it a go for comparison.

Helium Frog Firmware


I'm looking forward to the progress, so make sure you update us regularly.

Incredible,

Registered at these forums for this thread... Really impressed, I think this design is going places.

My grasp of the coordinate system here is weak, when you quote 30steps/mm in X/Y is that resolution constant across the whole range of movement, or does it vary like a polar/SCARA type bot?

At the Vancouver Hack Space we've been working on a similar design.

[www.marginallyclever.com]

I love the elegance of your part design. How many iterations have you gone through in designing the parts? Do you have any problems with lateral stability? I thought I needed diagonal braces to keep everything in place. Judging from your design I could be wrong.

Keep up the great work!

How's the frame shake at those speeds? That would be my main concern with this type of design.

Impressive! Also seems to have much more room at the location where the nozzle would be.

Can you test it weighed down?

Here are most of the plastic parts that I have printed for the Rostock prototype over the last 2 months:



Lateral stability is okay but not awesome. I think I'll probably end up adding at least one vertical plywood or two diagonal metal tubes, which could also be useful for the cables to the top endstops and extruders.

I'm currently implementing a better G28 homing routine in the firmware: first move up until we touch all three top endstops, then touch each of the three bottom endstops with the adjustable screws on the end effector (moving platform).



When I get that working, I'll generate some more interesting demo gcode and post another video. I agree the next speed test should have some weight on the end effector, for example a dial indicator, which would also be very useful to demonstrate the precision of horizontal moves.

SanjayM wrote:
> My grasp of the coordinate system here is weak, when you quote 30steps/mm in X/Y is that resolution
> constant across the whole range of movement, or does it vary like a polar/SCARA type bot?

The 30 steps/mm X/Y resolution is for the middle of the print bed. The X/Y resolution gets dramatically better near the edges of the print bed, because when the diagonal push rods are almost horizontal, the vertical carriage has to move down 10 mm for a 1 mm horizontal adjustment to the end effector (moving platform). So the vertical resolution of the three carriages is constant (currently 40 steps/mm), but the horizontal resolution of the end effector is somewhere between 30 and 300 steps per mm, depending on the elevation angles of the diagonal rods, which depend on the position of the end effector.

Oh wow! Great picture. Where did you get your bushings from, and how did the integrated bushings perform?
I hope I have a booth next to you at the Seattle Mini Maker Fair, we'll have so much to talk about.

A question:
How do you calculate the carriage resolution with 40 steps/mm?

I think that most NEMA 17 stepper motors that were used here, make 200 real steps per round.
Your pulley seems to be a big one, with about 50 teeth, pitch 2mm.
This makes 200 steps per round, per 100 mm = 2 steps per mm.

Or do you calculate with half steps etc?
What motor type and pulley do you use exactly?

Anyway - a real simple and clean looking, good design!
The best design and speed i have seen yet.
Congratulatons!

I purchased the LM8UU, LM8LUU and hardened 762x8 mm smooth rod and F608Z bearings from vxb.com, and the GT2 timing belt and pulleys from sdp-si.com. The motors are Kysan 1124090 Nema 17 from ultimachine.com.

Kalle3D: RAMPS 1.4 supports 16x micro steps. My motors have 200 full steps per rotation = 3200 micro steps per rotation. The pulleys have 40 grooves with 2 mm pitch = 80 mm per rotation. 3200 steps / 80 mm = 40 steps / mm.

The printed PLA bushings in the pictures above are my own experimental design, but it was difficult to make them tight enough to keep the vertical carriages exactly horizontal and avoid binding. They would probably work okay if we put 3 printed PLA bushings on each vertical carriage, but I didn't want to print the carriages twice as tall.

Currently I'm using LM8UU linear bearings (24 mm long) and they are working really well. On one side of one carriage I'm testing LM8LUU (45 mm long) but the extra length doesn't seem to be necessary.

Quote

On one side of one carriage I'm testing LM8LUU (45 mm long)

The extra length is pointless if you mount that bearing on just the same small surface as the shorter one, of course. To get an advantage of the long bearing, you have to lengthen the carriage, too.

Other than that: nice work!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

really realy cool, great work
i like the clearance of the design and I'm looking forward to build my own

Especially it is easy to change the motor size.

---

[chaozlabs.blogspot.de]

Beautiful. Can't wait to see it print!

---

- akhlut

Just remember - Iterate, Iterate, Iterate!

[myhomelessmind.blogspot.com]

Looks good! Nice design even though its strictly not a delta-robot

The resolution you claim is quite high. Have you meansured the REAL resolution? How do you do your coordinate transformations? In real-time or by liear approximation?

Cheers,
Reinoud

(sorry, have been away for quite some time)

Johann, I have some questions about the firmware, so I started a new topic:

[forums.reprap.org]

---

Frédéric

Are there any plans to add features I have come to love from the Makerbox with Accelerated firmware such as being able to preheat, prime the extruder before printing, print from SD card. I haven't printed from a computer for some time. The makerbot saves a special file that is then interpreted by the firmware and printed.

Are there any types of lcd or interfaces to control without a computer?

What's the progress on dual extruders?

Jamesarmstrong97 Wrote:
-------------------------------------------------------
> Are there any types of lcd or interfaces to
> control without a computer?

Plenty. See:
[www.thingiverse.com]
[www.thingiverse.com]
[www.thingiverse.com]
etc.

Most RepRap firmwares and electronics support SD card readers, LCD displays, and click encoders.

As for dual extruders, it is still quite experimental at this point. I have the parts to set up a dual extruder on my MendelMax but haven't gotten around to it yet.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

im new to this, and ima ask some newb questions LOL ... (and im poor in math, but i scored quite well in physics )

so to have this machine work, the 3 double shafts "spots" are equi distance form each other, and the shafts are theoretically double the distance of the perpendicular bisector it forms? am i right?

so in my imagination, the build area has to be enclosed by the triangle? or ... how do you position the square in that triangle? i cant figure this part out ... LOL ... or it depends on the length of the double support struts holding the hot-end? (or theres a sin/cos thingy going on there?)

The build area is essentially a Venn diagram of the maximum reach of each arm. The central, intersecting set is the build area. If the reach of an arm is less than the pillar-to-pillar spacing, then there are cutouts in the set where the arms cannot reach.



You can see that as the reach of the arms increases, the build area becomes a triangle. As the reach of the arms decreases, the build area becomes a rounded triangle. There is an optimal range in the middle, where the build area is a rough hexagon (pictured above)

I am assuming, in that diagram, that the arms can reach a full 180deg arc, but that may not be the case; it could be significantly less, in which case, the shape will become somewhat more complex.

Here's the math for converting x,y,z to ha,hb,hc, the three pillar heights, using arbitrary placement of the pillars:

A quick definition, the length of some vector, V, is the square root of the vector dotted with itself:
|V| = sqrt( V.V )
|V| = sqrt( Vx^2 + Vy^2 + Vz^2 )


In the x-y plane:
First define three vectors from the origin to each support/drive pillar: A,B,C
Define a vector from the origin to the desired location of the print head: W
Define the length of an arm: r
Define the height of each carriage on its pillar: ha, hb, hc

Then the horizontal distance from each pillar to the print head is:
a = |W-A|
b = |W-B|
c = |W-C|
(note that the subtractions here are vector subtractions


In 3D space:
Then, knowing the length of the arm, each height is defined as:

ha = z + sqrt(r^2 – a^2)
hb = z + sqrt(r^2 – b^2)
hc = z + sqrt(r^2 – c^2)

Substituting to get rid of one square and one square root operation,
ha = z + sqrt( r^2 – ( W-A )^2 )
hb = z + sqrt( r^2 – ( W-B )^2 )
hc = z + sqrt( r^2 – ( W-C )^2 )
Note that ( W-A )^2 = ( Wx-Ax )^2 + ( Wy-Ay )^2 + ( Wz-Az )^2 since this is a vector subtraction and a vector square.

Annirak: what happens if instead of '3 arms', we use 4 arms instead? Would such design be kinimatically possible? And would it have any benifits compared to the 3 arm standard delta configeration?

4 arms is over constrained and has the potential to bind.

Annirak: why do you regard the rounded hexagon size working area as the optimal one? In what sense is that more optimal than moving the pillars a little bit further appart & getting a Reuleaux triangle as the working area?

I'd really like to find out the reason for this, as I'm making my own Rostock and am trying to figure out the best dimensions for the frame.

@ Mofosyne:
Absolutely, four arms is possible. The math is, in fact, the same. The only problem is that with an additional degree of freedom, the movements of the arms must be more coordinated to prevent binding, which makes calibration far more important, though you do end up with a more stable and more accurate platform.

@Darhuuk:
There are several tradeoffs involved. You want to have the shortest arms possible to reduce flex. You want the shortest pillars for the same reason. You also want to eliminate any possibility of binding where endstops can't detect. I think you're right: the rounded triangle is actually better. But one where each vertex is precisely at the base of a pillar.

> Nice design even though its strictly not a delta-robot

Is there some other, more technically accurate name for this kind of design/kinematic arrangment?

Parallel axis robot?

---

Frédéric

Another name can be triglide (Tri-Glide), hexaglides are know for using 6 linear independent linear guided motions

parallel kinematic mechanism

I would call it a column bot.