Tri-Polar Bot Concept -- Meet Wally

@cratos: I am defining the macrocreation factor as the change in length divided by the currently length. (Not that it matters. I am making up this terminology mostly to just entertain myself.)



@conscripted: I am making beta kits now. You can go to ConceptForge and give me your email and you may be able to squeeze into the beta run. I will probably send an update to the followers later today or tomorrow that will give instruction to anyone wanting to get some of the last machines in the beta run.

@Guizmo: Now that I am building both Wally and Simpson, I like Simpson better. However, Wally has a few things going for him. Constraining the extruder to the xy plane is going to make calibration a lot easier. I think Wally could be THE desktop machine and Simpson could be THE large format machine.

@Everyone:

I have a few issues to work out but I think I should get some first prints in a week or two. One thing is clear, Wally is faster than he needs to be. That gives me some wiggle room if I need to change the mechanical advantage.

Edited 1 time(s). Last edit at 08/26/2013 11:44AM by nicholas.seward.

Here is some awesomeness! (This proof was accidentally engraved sideways. I have extras!)

Edited 2 time(s). Last edit at 08/27/2013 03:25PM by nicholas.seward.

Looks great!

Was that laser marked? I work with a laser marker on my daily job and they are fun.

Looks Cool! I can really tell where the center is.

@Guizmo: We used a 100W 5'x10' laser cutter. It takes about 150 seconds per board.

Where is WALLY?
Kits
CAD drawings, STL files, build files

Let him out Eddie Haskel!

I am going on the record. I will release Wally on or before September 21st, 2013. We all know this means it will be on the 21st at 23:59:59.9999 CDT. I am holding back for a few reasons. (I picked this date because this is the date of NY Maker Faire and if Wally isn't ready then I am in trouble.)

1) It takes a lot of work to do a release. I have done the design but I have to add the documentation.
2) Wally hasn't printed anything yet. If I release now, I will be sure to have many revisions.

I will try to setup a repo for those that want to live on the bleeding edge. The repo will just have my working folders for people to creep on but there is no guarantee that everything makes a cohesive robot.

I like SVN over GIT. Do you guys have any suggestions for a hosting service. I would like a ConceptFORGE repo where it is all GPL. That doesn't really fit with google code or sourceforge. Thoughts?

Github actually does support subversion access including commit: [help.github.com]

Has anyone worked through the kinematics for Wally? I'm willing to give it a go (so I can use LinuxCNC on a BeagleBone to control my new Wally beta, to be delivered 9/22 at 0:00:00:0000 , but I don't want to reinvent the wheel if someone has already gone to the trouble of accounting for the ways the arms interact.

Just came accross this project, I must give you kudos. This is an impressive piece. I will be rooting for you once you finish it! An increadibly low cost, easily replicatable and wall-mountable machine like this is ideal for clubhouses and school rooms everywhere!

-Kaze

This project is awesome, I'm just obsessed with it, what are you doing now, does it work as expected? any problems with the kinetics or something???

Presently, I am working up to "first prints" on Wally and Simpson. They have to be together and functioning by Wednesday so I can make it to NY Maker Faire. I should have some more videos this week.

I'm very excited to see your progress in the NY Maker Faire!

BTW: do you ever realized that your project seems to be easily foldable into a toolbox-size box if you add a couple of hinges just above the printing surface??? XD obviously the mods will come later, now the most important is to get this thing working!

wally is great! cant wait to see source.


can you upload firmware?

please

I use unmodified firmware. All the magic happens in (currently unwritten) software.

cdsteinkuehler Wrote:
-------------------------------------------------------
> Has anyone worked through the kinematics for
> Wally?

So far the best method I have figured out involves calculating the location of the arm joint via the intesection of two circles: [paulbourke.net] (scroll down to "Intersection of two circles")

Here's a picture from Paul Bourke's site (worth 1000 words in this case for sure!):


r0 = Base arm (mounted to the platform)
r1 = Moving arm
P0 = Base arm mount point (fixed)
P1 = Desired X,Y coordinate (print-head)
P3 = Arm joint X,Y position (calculated)

Once the X,Y location of P3 is calcualted, it requires two inverse trig functions to get the angle of the base arm (X-axis -> P0 -> P3) and the actual joint angle needed (P0 -> P3 -> P1). Calculating the commanded joint position is then a straight-forward matter of compensating the actual joint angle with the base arm angle using the ratio between the stepper and the joint pulleys.

There are full equations and code on Paul Bourke's site for the circle intersection. The calculations for determining P3 look complicated, but it's all add/subtract/multiply/divide, which is as close to "free" as you get with floating point (even on a simple chip like the ARM core in the BeagleBone I'm using for control). Plus, a *LOT* of the terms are known constants so quite a bit of the complexity can be pre-calculated. The inverse trig functions take some work (typically implemented as a series expansion behind the scenes in the FP library or the FPU itself), but this should still run fast enough for real-time on the 'Bone.

Anyone got a better idea for the kinematics equations? It seems like it should be _possible_ to combine the base and arm angles into a single equation and get rid of one of the two inverse trig functions, but my symbolic geometry math-foo isn't up to the challenge at the moment (it's been ages since I worked with stuff like this).

I've done a bit on the forward kinematics, but that's not required for Nicholas' "pre-compute" strategy, and even with LinuxCNC the forward kins are optional.

I think I have an slightly different approach to that mathematical problem, but my question is, you only need the equations that tells you the angle you need in each elbow in order to reach any point in the printable space???

I need the elbow angle and the shoulder angle. I have to combine those to drive the pulley.

Edited 1 time(s). Last edit at 09/16/2013 11:59AM by nicholas.seward.

harguinxx Wrote:
-------------------------------------------------------
> I think I have an slightly different approach to
> that mathematical problem, but my question is, you
> only need the equations that tells you the angle
> you need in each elbow in order to reach any point
> in the printable space???

You need more than the elbow angle. Since the motors are not mounted on the arm and do not directly control the arm joint angle, you need to know the angle of the base arm as well. Or to put it another way, if you command a given motor position, the effective elbow angle will change as you move the base arm since this is the same as turning the motor pully in relation to the elbow joint.

The equations would be a lot simpler if the commanded motor position didn't depend on the arm base angle. You could figure the elbow angle with the law of cosines using the known length of the two arms and the calculated distance from the arm mount and the desired X,Y location (one inverse trig function vs two, and a lot fewer FP calculations).

You make an interesting point. If the motors rotated with the shoulder joint, there would be no interaction between elbow angles. That would simplify a couple of things -- including allowing the figure 8 strings. The inertia of the motors rotating with the shoulders should be small.

The rotating inertia would be small but I am bound and determined to have all the motors static. BTW, I think future Wally's will have Proportional Gear Drive Joints(PGDJ). They are out performing my expectations. If I keep the static motors I will still need to do two inverse tangents for the firmware but with the PGDJ you don't drive the angle you drive the actuated length.

I will stick with the current design for the initial file release and NY Maker Faire.

One of the beauties of Wally is you can make a design that works, then experiment with alternative X,Y arm designs independent of alternative Z designs. You can do it within a single Wally ecosystem and easily back out of a design that is not working to try again. The hardest part might be adding extra mounting holes accurately to the wooden parts if needed. Could probably make that work by printing out a drill jig that locates itself from the current holes. Love this RepRap concept.

Good luck getting everything working by the show. Don't even think about changing the Wally design before the show. You have your hands full getting both Wally and Simpson running.

I remember many all nighters in my youth when trying to finish debugging a new design before different computer fairs in the 70s. I always seemed to make it just in the nick of time, but keeping upright the first day in the show booth was a challenge.

left stepper rotation=c*(mechanical advantage)+g
right stepper rotation=d*(mechanical advantage)+h



Let me know if I have a math error. I did this quick. I am a few hours from putting it into code.

Edited 2 time(s). Last edit at 09/17/2013 12:25AM by nicholas.seward.

nicholas.seward Wrote:
-------------------------------------------------------
> Let me know if I have a math error. I did this
> quick. I am a few hours from putting it into
> code.

It looks good to me (give or take a sign or initial constant here or there). You're simplifying based on equal length arms...I didn't know that was a constraint and assumed the arm lengths could differ. One comment is since you are already calculating the hypotenuse (a and b), you might consider asin() instead of atan() to calculate e and f. IIRC, asin() and acos() converge a bit faster than atan() in most floating-point implementations, but that's just nitpicking. At least atan() won't potentially throw NaN unlike it's forward counterpart! :-)

Best of luck!

f=atan(-y/(L-x))

@cdsteinkuehler: The arms can be differently lengths in theory but there is no mechanical benefit. Any arm difference puts a no go zone around the steppers. A little difference could be okay but if the difference is small wouldn't it be easier to just make them the same.

Good tip on on acos/asin! I will leave it to others to cram this into firmware. I just gcode preprocess.

@DaveGadgeteer: Thanks!

The same here, I thought that the arms length may differ, but if that is OK, the rest seems mathematically correct to me, great work!!!

This is my aproach, as you can see is very similar to yours...



Edited 1 time(s). Last edit at 09/17/2013 12:53PM by harguinxx.

Is Wally ready for the NY Maker Faire along with GUS Simpson?

No first print. I have a round of fixes lined up. Everything he is doing is amazing. I am flying in today and will have to button Wally up in the hotel.