开云体育

Again with my broken record about the spidery looking parallel robot...

I ran across this website which has what appears to be an open design:


It hasn't been updated in quite some time, basically because the guy who
wrote it got a job. In any case, this also appears to be compatible with the
goals of the reprap project. It seems that this design would be simpler to
build than a cartesian positioner, and since reprap doesn't require the
rigidity of a mill, this might be a more versitile design. Judging from the
stated intent on the website, the author might be willing to donate it to a
GPL type open license.

Dear Dennis,

Thank you for the tip.
I think we'll start about by making a cartesian robot, i.e. some traditional
mill/gantry/router type thing, and then eventually move over to a Stewart
platform.

(I'm including the above link for the benefit of others. I know you know what
a Stewart platform is.)

The one thing a cartesian robot has going for it is that it's easier to
design, build, control and troubleshoot, because it's conceptually simpler.
(It's something the reprap group discussed briefly some time ago.) Stewart
platforms are harder to figure out, but I think they make more economic use
of materials, require smaller motors, etc.

On the other hand, even someone who's very clever would have trouble building
one in a weekend, like this thing:





Once we've got a few reprap units going, we'll think about switching over, and
using those systems to bootstrap a stewart platform.

Still, I'll drop that guy a note.

Regards,
-Sebastien

On Sunday 27 August 2006 16:16, Dennis Schmitz wrote:

Again with my broken record about the spidery looking parallel robot...

I ran across this website which has what appears to be an open design:

It hasn't been updated in quite some time, basically because the guy who
wrote it got a job. In any case, this also appears to be compatible with
the goals of the reprap project. It seems that this design would be simpler
to build than a cartesian positioner, and since reprap doesn't require the
rigidity of a mill, this might be a more versitile design. Judging from the
stated intent on the website, the author might be willing to donate it to a
GPL type open license.






Addresses:
FAQ:
FILES:
Post Messages: CAD_CAM_EDM_DRO@...

Subscribe: CAD_CAM_EDM_DRO-subscribe@...
Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@...
List owner: CAD_CAM_EDM_DRO-owner@..., wanliker@...,
timg@... Moderator: pentam@... indigo_red@...
davemucha@... [Moderators] URL to this group:


OFF Topic POSTS: General Machining
If you wish to post on unlimited OT subjects goto:
aol://5863:126/rec.crafts.metalworking or go thru Google.com to reach it if
you have trouble.

I consider this to be a
sister site to the CCED group, as many of the same members are there, for
OT subjects, that are not allowed on the CCED list.

NOTICE: ALL POSTINGS TO THIS GROUP BECOME PUBLIC DOMAIN BY POSTING THEM.
DON'T POST IF YOU CAN NOT ACCEPT THIS.....NO EXCEPTIONS........ bill
List Mom
List Owner


Yahoo! Groups Links

I'm curious about the Stewart platform, and what kind of actuators might be
salvaged to create a small one - like meter or less in dia? I suppose just
some salvage steppers with threaded rod, but if others might have better
ideas, I'd love to hear. One of these "sandtables" would be cool to build.





Chuck Merja

Dear Dennis,

Thank you for the tip.
I think we'll start about by making a cartesian robot, i.e. some traditional

mill/gantry/router type thing, and then eventually move over to a Stewart
platform.
<>
.org/wiki/Stewart_platform
(I'm including the above link for the benefit of others. I know you know
what
a Stewart platform is.)

_

--- In CAD_CAM_EDM_DRO@..., "Dennis Schmitz"
<denschmitz@...> wrote:

In any case, this also appears to be compatible with the
goals of the reprap project. It seems that this design would be
simpler to build than a cartesian positioner, and since reprap

doesn't >require the rigidity of a mill, this might be a more
versitile design.

No way, a hexapod is a can of worms. Software, calibration, joint
accuracy, singularities etc etc

Plus you need 6 motor drivers and motors and you don't even need
6-axis control.

A triaglide perhaps but not hexapod. Especially an unproven virtual
design (as far as I can tell)

Graham

From a Machinists view and knowing basically what is required for general machining. The Stewart platform, although clever and innovative would have to be built on a massive scale to even be adequate for modest machining including plastics. The key is mass and close tolerance and even resistance in the ways can add to the stability.

From a programming standpoint it would be a challenge. It would be an absolute production and choreography just to move the table two inches and keep it in a straight line and on the same plane radially, square to the spindle etc. Folks have enough trouble getting their cartesian machines to even cut a round circle without backlash etc., can only imagine the issues that would be involved with six actuators attempting to position a table aloft.

These designs are fun to discuss, but the reality is they are way out of the loop for the home shop. Hotwiring styrofoam possibly, but not even machining plastics.

Just my opinion, Ron

Graham Stabler <eexgs@...> wrote:
--- In CAD_CAM_EDM_DRO@..., "Dennis Schmitz"
<denschmitz@...> wrote:

In any case, this also appears to be compatible with the
goals of the reprap project. It seems that this design would be
simpler to build than a cartesian positioner, and since reprap

doesn't >require the rigidity of a mill, this might be a more
versitile design.

No way, a hexapod is a can of worms. Software, calibration, joint
accuracy, singularities etc etc

Plus you need 6 motor drivers and motors and you don't even need
6-axis control.

A triaglide perhaps but not hexapod. Especially an unproven virtual
design (as far as I can tell)

Graham

I was only thinking of the 3dof machines for the glue-gun application as
opposed to the 6dof stewart platforms. As near as I can tell, the transforms
for those don't have singularities, but I could be mistaken.

--- In CAD_CAM_EDM_DRO@..., "Dennis Schmitz"
<denschmitz@...> wrote:

I was only thinking of the 3dof machines for the glue-gun application as
opposed to the 6dof stewart platforms. As near as I can tell, the

transforms

for those don't have singularities, but I could be mistaken.

In that case I'm confused with the reference to that design.

The singularities are in the joints, it depends on the joint type but
certainly the easy to build types (like universal) can cause problems,
just and example of one problem.

Graham

Dennis,

What about an articulating arm? I've even thought about this for a machine tool. It would need to be massive (within reason 800-1000 pounds), I have some 2 hp servos already. Would be nice to mount a router on it. Could turn any large flat surface into a machine. Pick up three points from the plane to reference.

Would retract up tightly for storage and take up very little room. The perfect homeshop solution to wood cutting/shaping.

There are so many of these in use, and just as cartesian CNC found its way, I think this technology could find its way as well into the hobbyist' realm. By now there has to be some open source robotic design software somehwere. Or cheap anyway. Mach could handle the 4 or 5 axis' of movement.

Ron

Dennis Schmitz <denschmitz@...> wrote:
I was only thinking of the 3dof machines for the glue-gun application as
opposed to the 6dof stewart platforms. As near as I can tell, the transforms
for those don't have singularities, but I could be mistaken.

Arms have transforms that are full of singularities. In order to get an xyz,
you must translate that into joint positions. There are multiple solutions
and linear movements can go through singularities (named for the math), so
path planners need to avoid them. The math isn't supposed to be so
unforgiving for parallel machines, though. According to my reading, anyway.

I've been thinking about this quite a bit.

The problem breaks down to a couple of different issues. In a
cartesian positioner, everything is fairly simple. Calibration is
linear -- a step corresponds to a linear displacement in x,y, or z. Or
it corresponds to an angle in a rotary table.

On the other hand, calibration of a stewart platform, or delta robot
requires that for every movement in x,y, or z you have to adjust the
position of all the servos. 6 for hexapod platforms, and 3 for the
delta robots. And it's not linear -- you have a higher resolution in
the center sweet spot than you have at the limits of movement.

The inverse kinematic transform appears to be stable for both and have
unique solutions. This means for any x,y,z coordinate, you arrive at
only one solution for leg-lengths to get to it.

So what does this mean to the home-shop or hobbiest builder? There
would be a layer of software between the xyz and the motor positioner
that would be responsible for positioning. This transform also
introduces some quantization error and also decouples the g-code
interpreter from the actual motor positions.

I'd venture that most people who build machines don't really
understand the details of PID controllers, basically because most
people aren't required to learn calculus, but are more than capable of
using or even expertly tuning them. This level of abstraction doesn't
seem insurmountable.

On the other hand, you do need to develop a transform for your own
machine. It might seem daunting to delve into the matrix math, but the
functions used in them are all high-school trig and geometry. This
could be facilitated by a module that calculates it for you, I
suppose, taking parameters in the form of leg length and platform
size, and doing the transform for you.

Building a delta robot isn't all that difficult either, and it's a
fine platform to set a router on, especially if you're carving 3D
shapes. The accuracy of the ball and socket joints seems crucial, but
like I said, I think you could grind a ball on the end of a rod and
clamp a delrin socket around it. Since all three axes are identical,
you repeat it rather than have three different axis designs.

The other crucial thing is the gearbox for the servo arm. It's a lot
different than mill screws, and probably more expensive. I'm still
pondering that.

Anyway, that's it for my thinking on the matter. I did pull down a
couple of Matlab simulations on hexapods to play with. If I learn
anything useful to home CNC, I'll let y'all know.

Dennis Schmitz wrote:
....

The inverse kinematic transform appears to be stable for both and have
unique solutions. This means for any x,y,z coordinate, you arrive at
only one solution for leg-lengths to get to it.
So what does this mean to the home-shop or hobbiest builder? There
would be a layer of software between the xyz and the motor positioner
that would be responsible for positioning. This transform also
introduces some quantization error and also decouples the g-code
interpreter from the actual motor positions.

I don't think this is necessarily the case. I am working on a tripod-style design (yes, for home use), and so far, my software doesn't decouple the g-code interpreter from the motor positions. And, there is no quantization error introduced by the interpreter -- my algorithms basically operate in stepper motor space.

Does that make sense?

Mike

--- In CAD_CAM_EDM_DRO@..., "Dennis Schmitz"
<denschmitz@...> wrote:

On the other hand, calibration of a stewart platform, or delta robot
requires that for every movement in x,y, or z you have to adjust the
position of all the servos. 6 for hexapod platforms, and 3 for the
delta robots.

Delta robots can also be 6-axis. The "deltaness" comes from the fact
they use rotational actuators. You can build three axis platforms
with either actuator type.

This means for any x,y,z coordinate, you arrive at
only one solution for leg-lengths to get to it.

Actually you will always get at least two but you can normally ignore
one of them. The second solution is when the whole mechanism is
toggled or turned inside out. You can remove the generalism of the
matrix form and "tell it" which way it is basically configured

So what does this mean to the home-shop or hobbiest builder? There
would be a layer of software between the xyz and the motor >
positioner that would be responsible for positioning. This transform
also introduces some quantization error and also decouples the g-code
interpreter from the actual motor positions.

When using mach I set up secondary axes, these were the actuator
postitions which were defined in terms of the primary axes using the
equations function. The quantization error is no more of a problem
than it is for a normal machine thought the positional error will tend
to grow as you move from the sweetspot.

I'd venture that most people who build machines don't really
understand the details of PID controllers, basically because most
people aren't required to learn calculus, but are more than capable
of using or even expertly tuning them. This level of abstraction
doesn't seem insurmountable.

What's your point?

On the other hand, you do need to develop a transform for your own

machine. It might seem daunting to delve into the matrix math

I sometimes wonder if I am talking to myself. I have posted a link to
my kinematics page at least twice. You don't need matrix maths you
can calculate the lengths or base positions directly using pythagorus.
For example if you take a triaglide, you know the position you want
the table to be in, the points on the rail where the carriage should
be are given by the intersection of a sphere with a line. i.e. the
possible positions of the struts other end with the rail. You will
get two solutions but you can ignore one. Also if you keep the
equation in its most general form you can account for rails not being
parallel etc.

Building a delta robot isn't all that difficult either, and it's a
fine platform to set a router on, especially if you're carving 3D
shapes. The accuracy of the ball and socket joints seems crucial,but
like I said, I think you could grind a ball on the end of a rod and
clamp a delrin socket around it. Since all three axes are identical,
you repeat it rather than have three different axis designs.

PLEASE have a look at my page, you will see that ball joints aren't
even needed.

The other crucial thing is the gearbox for the servo arm. It's a lot
different than mill screws, and probably more expensive. I'm still
pondering that.

Again see my page, there is a cool way of getting high gear ratios
using a belt.

Bottom line, I think triaglides and deltas have real homebrew
possibilities, I've done the ground work, please run with it. BUT
hexapods specifically don't fit the bill for reprap or most homebrew.

Cheers,

Graham

www.indoor.flyer.co.uk/kinematics.htm

Not really. Since CAD models are built in a cartesian coordinate system,
somewhere along the way you need to translate into a motor space. Whenever
you translate co-ordinate systems, you get quantization error at the encoder
(or step) resolution.

The point is that you don't really need to know how the transforms work to
use them, and that people shouldn't be put off by the bit of robotics math
because under the arcane terminology, it's pretty easy.

--- In CAD_CAM_EDM_DRO@..., "Dennis Schmitz"
<denschmitz@...> wrote:

Not really. Since CAD models are built in a cartesian coordinate system,
somewhere along the way you need to translate into a motor space.

Whenever

you translate co-ordinate systems, you get quantization error at the

encoder

(or step) resolution.

surely you get quantization error of this sort even if you don't
translate between co-ordinate systems.

Graham

HI Graham,

*I* looked at your site! I've been back a few times, for that matter. I
like the Hexel platform, and would love to make a working model of it. Not
sure if I could work out ALL the kinematics, but it would be a good
exercise. What is the stuff that looks like links (copper colored) down ON
the table?

Alan KM6VV
P.S. It's OK to talk to yourself; it's when you start ANSERING yourself
that you want to worry about!

<SNIP>

Dennis Schmitz wrote:

Not really. Since CAD models are built in a cartesian coordinate system,
somewhere along the way you need to translate into a motor space. Whenever
you translate co-ordinate systems, you get quantization error at the encoder
(or step) resolution.

In the cartesian axis case, I don't think quantization error is a given, because the step resolution can match the coordinate system resolution. In my case, for example, steppers are 200 steps/rev, and leadscrews are 10TPI. That gives a quantization of 0.0005".

So, as long as I specify coordinates in 0.001" increments (which is what I normally do), there's an exact representation in motor coordinates (and no quantization error).

Mike

Graham,

Let me second that -- your site is excellent. In fact, your site was one of the reasons why I started working on my design (which is a "triaglide with vertical rails", as per your diagram).

Mike

Alan Marconett wrote:

True enough, but I was thinking about straight-line movements and
non-linear resolution in cartesian coordinates. A straight line
movement through the range would have stepping.

Some stuff I didn't have time for this morning...

On 8/31/06, Graham Stabler <eexgs@...> wrote:

--- In CAD_CAM_EDM_DRO@..., "Dennis Schmitz"

When using mach I set up secondary axes, these were the actuator
postitions which were defined in terms of the primary axes using the
equations function. The quantization error is no more of a problem
than it is for a normal machine thought the positional error will tend
to grow as you move from the sweetspot.

Sorry, I'm not familiar with Mach because I don't own a copy.

On the other hand, you do need to develop a transform for your own

machine. It might seem daunting to delve into the matrix math

I sometimes wonder if I am talking to myself. I have posted a link to
my kinematics page at least twice. You don't need matrix maths you
can calculate the lengths or base positions directly using pythagorus.

I'm not sure why the distinction. It's still the same number of
operations. Matrices are just an easy form to work with in code as
well as conceptually. Of course I spend a large part of most days in
Matlab, so I might be biased.

For example if you take a triaglide, you know the position you want
the table to be in, the points on the rail where the carriage should
be are given by the intersection of a sphere with a line. i.e. the
possible positions of the struts other end with the rail. You will
get two solutions but you can ignore one. Also if you keep the
equation in its most general form you can account for rails not being
parallel etc.

I find the matrix to be a more general form, probably because I'm used to it.

PLEASE have a look at my page, you will see that ball joints aren't
even needed.

I saw the stuff about the clevis, but I think the ball with self-lubed
plastic bushing is a simpler design. In any case you're right about
what's required, if you're making a 3dof platform and parallelograms,
you only need a universal joint since there is no twist to account
for.

The other crucial thing is the gearbox for the servo arm. It's a lot
different than mill screws, and probably more expensive. I'm still
pondering that.

Again see my page, there is a cool way of getting high gear ratios
using a belt.

Bottom line, I think triaglides and deltas have real homebrew
possibilities, I've done the ground work, please run with it. BUT
hexapods specifically don't fit the bill for reprap or most homebrew.

Fair enough. I wasn't suggesting a hexapod for reprap anyway, but a delta.