Wally Z axis alternative linear designs

Simpson has nothing to do with this thread. Wally was a concept with a first cut at implementation by Nicholas. It has not had full followthrough while Nicholas has been busy with his job, but Nicholas did demonstrate a working Wally, you can't say Wally does not work, just because some others have not made their variations work from his open source alpha design. Working on an Alpha design takes someone who could build the whole works from scratch. Not every maker has skills to do all the tasks. In fact it often takes a team to get all the skills.

I have other ideas of where to take the Wally concept to make it into a practical and workable bot. Nicholas may or may not agree with some of my new ideas as far as what he might wish to do, but he is the most supportive person I have known for encouraging and helping others to explore their different creative ideas.

A linear Z axis is just the one area to nail down, and that does help make the software one little step easier.

I have not had my own 3D printer to try to build any Wally parts or variations yet. My first 3D printer kit just showed up and I am starting to assemble it now. It will take me a while to learn how to make good parts though. My play time is also limited right now.

Quote
Feign

I understand that the Wally really just doesn't work, it seems like it would take a built-from-scratch firmware to get the coordinate system right, and even then it would be tough to calibrate. Even if the interest existed to do that, I'd rather see that effort go to finishing the Simpson. (It looks like Nicholas is going in this direction as well.)

I at least think the Wally had more potential for the 'no-rails' criteria than the Rhombot... At least there's that.

I have a printer kit waiting for me but until i can retrieve it i want to think about experimental bots... so I would like to assist in building a linear x crane bot using alot of the concepts of wally any thoughts reprap community.

It would be to create an open frame stationary platform that uses a robot arm which can build parts larger than itself.

Quote
creativeautomaton
would like to assist in building a linear x crane bot using alot of the concepts of wally.

Can you make a sketch of what you have in mind?

Here is an idea.
Take the section that the Wally X Y motors and bearings are mounted on,
and connect that to a Z mechanism.
Printed part is fixed.

Hefty section to move up and down
but
the massive original lift table better used this way than hoisting printed part.

Probably could keep to "NO simple linear" lift constraint here.

Hydraulic lift assembly -- to keep with -- complex is more better?

Wait... have the arms on an identical lever arm lifting up the arm assembly as the one lowering down the plate so their relative horizontal position remains the same?
Attach the two so thet they counterbalance each other somewhat. So crazy it might just work!

@Feign: I am not quite sure but I believe that idea has been thrown around before. I like it a lot. It does add a bit of complexity. (I would love to figure out a way to use that concept in all 3 dimensions.)

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Well, the disadvantage I see to it is that it adds a lot of momentum to the axis, though that's not ever been an issue in the Z-axis, as opposed to it always being an issue in the X and Y.

As an aside, if the arms are suspended off the backboard, then it's likely that they would work well with the more centerally arranged Morgan arm setup (I'm assuming the Morgan's arm arrangement is also a bit easier to calculate the positions on, but I'm not a math guy at all)...

Actually, I kind of thought this might be useable with the polar printer idea waaaaay back in UnlimitedBacon's thread (link to that old post.). With the weight on the lower arm of the z-axis, you would have the printer default to an open position, and not risk the hotend falling onto the print if you lose power.

I'm sure there are ways to make it more stable, but I just went for a quick sketch of the basic concept, intended to go with the sketch in that post.

@Feign: I love how you are driving the z. That is such an easy zero backlash drive. Looks like it would be a fun build. (That initial post was my original idea for a railless printer before I hit on the Simpson geometry.)

I feel that there is something really great hidden in your concept. I filled a page in my notebook looking at variations and simplifications. Nothing worth sharing but there is something here. (With some added complexity you can get rid of the trig needed to drive the z.) If nothing else, this is a good way to drive 1 linear axis without rails.

I don't like this arrangement for the XY because of all the alignment issues you get with the singularity in the middle. You also have to have path planning that most firmware won't support to get through the center.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

@Feign: Interesting approach to the Z. I like the concept. Not exactly a Wally, but interesting none the less.

I sort of understand the problems with the basic turntable style polar printer having the hard to resolve center point, but like I said before, I'm not a math person so much as a general concepts guy. I had figured that the turntable style printer already had a lot of the math worked out already for existing designs. The z-axis could be made to fit the Wally arms pretty easily.

(also, I just realized one of my old posts was missing a few words... "I realise the Wally really just doesn't work for everyone." Sorry for that.)

Hey everyone,

Just joined the forum, I was just today working on some sketches for a scara robot but ran into trouble when doing the basic math (either speed problems or resolution problems, not even calculating any stability).
Let me at this point congratulate Nicholas for some great designs and thanks for all the work you put into your designs.
I was thinking of doing a classic scara with only one arm but the resolution you would get just never works out without using multi-stage gears (I calculated a 1:25 gear ratio minimum to reach 50micron resolution at 250mm total arm length). So I came to the conclusion that the simplest way is how you did it in Wally: use tow arms, drive both elbow-joints and cut down the positioning error by about 50%. Genius.
What remains from my original sketch Idea is using a linear rail to move the arms up and down and keep the bed steady, like cozmicray suggested a few months back. I see this as a viable option when z-travel is limited to let's say 150mm. I will try and work on this one to get a 3D sketch for illustration.

Not sure how you will take the following Idea and it kind of branches from the original Wally concept. Hope I am not stepping on anyones toes here:
Owning an RepRapPro Huxley I love the concept that was used: use very little 3D printed parts and fill the gaps with simple threaded rods. It makes a very cheap but still sturdy printer.
What I am thinking basically is that most people do not have access to Laser cut or CNC machined parts and bulky 3D printed parts are expensive. What I can get easy and cheap are threaded rods or aluminium/steel rods and tubes. These can be cut and filed to size by very simple means, no lathe, no CNC. So in a nutshell:
-Keep the design concept of the two joint-driven arms
-Replace some bulk 3D printed parts by aluminum tubes (cutting down the printing time significantly but adding to assembly time)
-Move the arms instead of the bed on linear rails: I am thinking 3 steel rods with 6 linear bearings, 8mm. Driven by an M8 screw (Huxley uses two M3 screws)
-Make it as low cost as possible

Welcome DedeHai,

You might find that square steel tubes of about 3/4 inch size can make a good external structure (instead of or in addition to the wood parts).

Because of the reaction forces from moving the arms, it is easier to make a moving bed that is linear on Z rails. The bed has no reaction forces, so the rails do not see any. This will facilitate being able to use more massive arms made from aluminum square tubes. 3D printed arms look massive, but they are mostly air inside, so they do not actually cost much, but are very rigid. They can also incorporate the various features to make assembly easier. Replacement parts are also easier to print than re-fabricate. Other parts, like brackets could be OTS metal parts.

I get your point, but I disagree Well not exactly but I got a different standpoint. The Huxley has a moving Bed (y-axis) and it makes removing parts harder. Sometimes you have to yank pretty hard to get printed parts unstuck, moving beds must be able to take that force (broke support parts more than once already). My preference for a non-moving bed comes from that experience.
You are of course right about reaction forces, but how precise do you need it to be? During perimeter prints, printers move slow, on infill, precision does not matter much. If this is constructed right I think the error could be negligible.

As far as 'printed plastic parts are cheap' goes: this is only true when you already own a 3D printer. If you want to sell a kit, printed parts are expensive, did not someone mention 100$+ for the printed parts of Wally?

Started to do a quick and simple sketch. No Idea if this could actually work this way, it looks fragile... also it is far from complete, really just a sketch.

The moving platform would have to go around the supporting rods (grey) somehow, probably on the inside. The motors and arm joints would be outside (left and right, at the front) of the Z-axis-tower to get full freedom of movement. The ground plate board is drawn as 350x550mm, fixing clamps and so on are not drawn.

It looks more complex than what I initially thought it would be. Also assembling of this thing is a nightmare to get all the rods aligned takes a lot of time. Maybe someone else has a good idea on how to get this done simpler.

If this is your main concern, then I would take a different approach. Have a removable bed surface that you can take away from the printer to remove the part. I supported a KickStarter for the Gecko print surface. It is just a thin steel plate with a special surface that parts will stick to, but give it a bit of flex and the parts fall off. I am expecting my 300mm x 300mm plate to show up an a few weeks for my 300mm x 400mm bed printer with a moving Y axis. The simplest solution is usually the best for DIY. My next designs will have a removable bed. Glass also seems to work as a removable bed, and can be very inexpensive.

Quote
DedeHai
The Huxley has a moving Bed (y-axis) and it makes removing parts harder. Sometimes you have to yank pretty hard to get printed parts unstuck, moving beds must be able to take that force (broke support parts more than once already). My preference for a non-moving bed comes from that experience.
You are of course right about reaction forces, but how precise do you need it to be? During perimeter prints, printers move slow, on infill, precision does not matter much. If this is constructed right I think the error could be negligible.

To pretty much review: The main problems with the Wally arms are due to a joint (the "shoulder") being between the motor and the driven joint (the "elbow") meaning that changing the angle of the "shoulder" will slightly change the angle of the "elbow" and all other things being static, when the motor changes the "elbow" the angle of the "shoulder" is changed as well, reflecting in a difference in angle of the "elbow" from what would be calculated from the change in the motor alone.

It doesn't make the math impossible, but it does change the math for finding the position of the arms from the motor position from a moderate trigonometric equation to a complex differential equation. This isn't to terrible when you're using a computer to do a few calculations, but when you have to do hundreds of position translations per second in firmware it has the potential to bog down.

This is all fixed by attaching the motors to the arm between the "shoulder" and the "elbow" rather than against the back plate (the way THOR Simpson does it). The GUS Simpson arms simplify it further by making the motor position-to-arm-position a linear ratio, making the extruder position a very simple trig equation.

The Main problem with Wally
the development was NEVER completed.
My Wally Chrome is sitting on my JUNK pile
because firmware / software was never developed
to drive the mechanics, and convert from cartisian to polar (Wally) coordinates.
and

linear mechanisms (leadscrew) were NOT permitted

A Z table that weighs 10 lb and moved up and down
like a car lift.

The math is bad but not intractable. It has been solved. (inverse kinematics) The real problem is calibration. The non-linear z is probably the biggest roadblock to calibration. That is why this thread exists.

For the record, I have abandoned development on Wally. That doesn't mean that someone else can't pick it up and work on it. I am personally targeting a 1-arm SCARA as a Wally replacement. Simpler math, simpler calibration, bigger build volume, etc.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Quote
nicholas.seward
The math is bad but not intractable. It has been solved. (inverse kinematics)

Did you ever get a non-iterative solution for the forward kinematics? If so, I should dust off my Wally and BeagleBone and get this working. When I last left Wally, bugs in the LinuxCNC code essentially required a function for the forward kinematics (which I didn't have) or fixing up the GUI code to avoid errantly switching between joint and world mode (which I didn't have time for). With forward kins (and a decent extruder), I think I could get Wally printing!

I never followed up on the forward kinematics. I have no doubt that it could be done without iteration but it would be some fun math.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

I also see the non linear Z as the main problem, affecting the math for the Y axis that has to be compensated.
Lifting the arms instead of the bed is risky and needs a very, very sturdy solution. But there is many ways to lift the table in a linear manner, some were suggested here. My favorite so far is the scissor-arm approach, which needs a linear rail. Foolowing image is from Thorlabs, they make optics-table equipment meaning it is rigid and precise:



About the complicated math of the arms: I did not calculate the inverse kinematic, but how could that be a differential equation? It is all a static problem, it could only be differential if position were speed or accelaration dependent, right?
Anywas, to get this done on a microcontroller: when I last uploaded marlin to a RAMPS, the memory used was about 64kB (basic firmware, no SD, no display). The ATMEGA 2560 has 256kB of flash memory, which is plenty more. Would it be possible to create a clever lookup table and do a linear or squared interpolation between points? The table would convert x-y positions to motor position for each motor. Using a 128kB table with two 16bit numbers (=4bytes) per x-y position, the table would have space for 32'000 points or 178 points each in x and y direction (assuming a linear distribution of points). on 200mm bed that would be almost 1 point per mm. Depending on how this map looks and (correct me if I am wrong) I think it would not look too wild (in a mathematical sense), linear interpolation could be enough to reach the resolution the printer actually has. The table can be pre-calculated and voila, simple math.
That's how I usually do it when there is not enough computational speed on a microcontroller but abundant memory.

Nicholas: since you already did the math, do you have a writeup of the full equation (x&y in, motor positions out)? Wolfram Alpha may help to convert to a 3D plot. Or I could use Matlab at the office.

@DedeHai: You are right that there are no differential equations involved. You are also right that a 2D lookup table would be a decent approach for this. One slight problem would be that a change in calibration will be a complete change in the table. (On second thought, it might be possible to have a generic table but I will have to think on it.) You might be able to generate a new table at runtime.

I don't have the full equations but you can piece it together in short order from the image I linked above.

Edited 1 time(s). Last edit at 11/03/2014 05:55PM by nicholas.seward.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Quote
DedeHai
Nicholas: since you already did the math, do you have a writeup of the full equation (x&y in, motor positions out)? Wolfram Alpha may help to convert to a 3D plot. Or I could use Matlab at the office.

Equations are in the python pre-processor code: wally_segmentize.py

Thanks for the hints. I quickly looked through the code but did not really get it. I printed the inverse kinematics image and looked at it on my train ride home from work. I may be overlooking something so please feel free to comment! but here is what I realized:
for given angle (d and c in the image) each arm can perform a circle of the radius of a or b. They only cross at one point when assuming that the angles cannot be bigger than 180°. So if the two angles are given, it results in only one possible point or 'the function is bijective in the given realm' to throw in a mathematical term. This means that for any given x and y coordinate, there is only one possible solution for the angles (i.e. motor positions). To get it symmetrical I placed the origin in the center of L, making the formulas almost identical.
To get from an x and y value to the angle, the formulas are already on the drawing and are using pythagoras and the law of cosines. Using a centered origin, the formulas for a and b slightly change:

a = sqrt(L^2/4 +Lx + x^2 +y^2)
b = sqrt(L^2/4 -Lx + x^2 +y^2)

putting these into the formula for c and d you get (i am using k instead of l for the lenght of the arms for readability):

c = acos((2*k^2-(L^2/4+L*x+x^2+y^2))/(2*k^2))
d = acos((2*k^2-(L^2/4-L*x+x^2+y^2))/(2*k^2))

This is all you need to determine the angle from an x and y position. I do not see any point of calculating the angles at the shoulder as these are given. If you want to shift the origin back to its original position, just replace x by (x+L/2).
Using wolfram alpha to plot thes functions (L=200, k=150):

Plot of c
Plot of d

As you can see, the functions are mirrored along x=0. To get from positive x value positions to negative x value positions simply swap the angles of the two arms. This means that the lookup table needs to contain only values for one arm and for the other one the x value can simply be inverted and then the same lookup table can be used. This doubles the possible resolution.
As the function from angles to x-y position is not linear, changing the angles in a linear way to move from one point to another will not result in a straight line (but almost). What this means is that the motion needs to be controlled in small segments to achieve high accuracy. I do not know how moves are actually implemented in the firmware and whether this is a problem or not.

The lookup table can be generated using excel (I'd rather not) or a python script and then put into the Marlin firmware (flash not eeprom). Now what I am not sure about is whether the linear interpolation is fast enough on a 16MHz Arduino, since it involves reading 4 values from a 16bit array, doing 9 additions/subtractions and 7 multiplications for each arm, all in at least 16bits.

Any suggestions and comments are appreciated.

Edited 1 time(s). Last edit at 11/04/2014 03:59PM by DedeHai.

@DedeHai: You would be right if the motors were mounted between the shoulders and the elbows. As it is, the motors are static on the backboard. Therefore, you have to rotate to match the arm angle plus the rotation to change the elbow angle.

stepper_1=constant(mechanical_advantage*c-g)
stepper_2=-constant(mechanical_advantage*d-h)

I was challenging myself to build the bot with all static steppers. It was an artificial constraint so moving the steppers to on the arms would make a lot of sense.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ

Oh, I see what you mean. Never having actually seen it live made me miss that, I assumed the steppers directly set the elbow angle. I will re-calculate the formula then. It should still be symmetrical though.

Another off-topic question: You are using M8 bolts to hold the bearings. M8 is just below 8mm (like 7.8mm usually) but the bearings are exactly 8.0mm. Is this no a problem (play, off-center rotation, tilt)?

I think it would be a good idea to mount the motors to the arms, but keep them in the same X,Y position (the center of the motor shaft at the center of the shoulder rotation). That way the steppers would just rotate about their center on the shoulder, which would keep the inertia very low, and the forces on the arm balanced above the strongest place (the pivot). I think it would be well worth the design change to make it easier to control.

I tried my luck on the full mathematical formula today. Not sure if I got it right though. It definitely would be an improvement to mount the motor on the arm, that way mechanical errors are much reduced because the angle of the shoulder joint is independent of the motor position. If it the motor is mounted on the wall any mechanical errors (tolerances) get amplified.

Here is what I calculated:
When the arm rotates around the shoulder by 'alpha', the motor needs to correct for the angle change in the elbow by rotating by an angle 'gamma'.
gamma = alpha*(R/r-1) , R being the radius of the elbow pulley and r the radius of the motor pulley. This is derived from the fact that alpha*R-alpha*r = gamma*r.
The full formula for the motor rotation is:

c*R/r+alpha*(R/r-1)

putting this all together with the formulas given above and the ones on the inverse kinematic sheet (with adaptations so the origin is in the center) the formula gets huge. 'k' is the length of one arm, 'L' the distance between the shoulders, I assumed an initial position where the angel 'g' is 90° and the angle c (elbow angle) is zero. I only did this for the left side (right side is almost identical, let me know if you want it):

acos((2*k^2-(L^2/4+L*x+x^2+y^2))/(2*k^2))*R/r+(pi/2-atan(-y/(L/2+x))+(pi - acos((2*k^2-(L^2/4+L*x+x^2+y^2))/(2*k^2)))/2)*(R/r-1)

using k=150, L=200, R=100 and r = 10 this plots as:


Left Arm (x,y) to motor angle in [rad]

It looks like it could be right but there could be a sign error in the formula when adding 'gamma' (maybe need to subtract gamma?) anyways, it is complex and since there is no huge advantage in mounting the motors to the wall it may be worth a shot doing the design change, accuracy may improve.

Combining this with a linear z-axis or a scissor arm z-axis it would probably work just fine with a static lookup table that can be created after doing a calibration like finding the exact number of steps it takes to do a 90° elbow turn and maybe some other procedures to measure the exact length of the arms and the distance between the shoulders. For example drawing a straight line, measure the deviation from a real straight line and using the inverse kinematic formula to calculate the actual lengths.

Edited 2 time(s). Last edit at 11/05/2014 03:57PM by DedeHai.

Quote
DedeHai
Another off-topic question: You are using M8 bolts to hold the bearings. M8 is just below 8mm (like 7.8mm usually) but the bearings are exactly 8.0mm. Is this no a problem (play, off-center rotation, tilt)?

After you tighten the bolts there is no play or tilt. The worst problem would be off-center rotation. In theory, this would remain constant and could be calibrated away.

---

ConceptFORGE
Wally, GUS Simpson, LISA Simpson, THOR Simpson, Sextupteron, CoreXZ