[attachment 43413 OpenSCAD_splitTube_01.png]]]>

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)?

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.]]>

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.]]>

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)?]]>

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.]]>

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.]]>

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.

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]]>

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

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.

]]>

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! :)]]>

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.]]>

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.

:S]]>

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

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

]]>QuoteDedeHai

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.

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.]]>

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?]]>

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.]]>

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]]>

[attachment 42744 IMG_0651.JPG]]]>

I am working on an OpenSCAD design for a printable split-tube segment, will post when done.

[attachment 42539 split-tube-four-bar-linkage.jpg]]]>

I didn't make this video, though after finding it, I just had to try it myself. It seems like this could be very useful in other 3D printing situations, but I'm drawing a blank as to

Also, they've basically declared the Beta Test portion finished and have opened preordering of the Peachy kits to the public (and it has almost as many preorders now from the website as the Kickstarter got during the campaign) with a predicted ship date in July 2015.]]>

G28

G92 X0 Y0 Z0

The end result is as can be seen here: End Stop Test

The endstops are adjustable and also swing up and out of the way so that the arms will stow flat, yet won't lose their zero.

[attachment 42109 Assem1.6.JPG]

[attachment 42110 IMG_2022.JPG]

[attachment 42111 IMG_2023.JPG]

[attachment 42112 IMG_2019.JPG]]]>

[attachment 41810 IMG_0572.JPG]]]>

[attachment 41773 IMG_0566.JPG]

Now to attach the end stops.]]>