A rendering next to the arms of the other machine.

[attachment 47817 Assem1.1JPG.JPG]

[attachment 47818 Assem1.2JPG.JPG]

This one would have a stationary platform and the arms would move up and down on some Makerslide.]]>

The good point of the Cartesians printers is that calibration is lower. It is not calibrated x-y. It depends on how the endstops are made, they will win or lose a few mm of bed printing (offset of printing these mm in x or y,) but the good news is that printing is not deformed.

In polar printers will be calibrated to the xyz perfection. Require more work or obtains deformed printing.]]>

A agree though, this turned out quite well even though it was so ambitious.]]>

The problem is that Sarrus is not 100% linear motion (in theory yes, but not in the real world). And Sarrus obliges use 4 engines for Z axis.

The initial idea was that could have more of 1 extruder (in top dish you can see a prepared hole for another extruder).

The engine + gear must have sufficient force to move the dish with 2 spools. Although the spools may also be outside.

The files are in my dropbox (solidworks, documentation and software), the link in my website.

Sorry, but the documentation is all in Spanish. My English is not the best. XD

When I have time I would like to explain the design and software, and because I chose these options (Bipolar and Sarrus). But not this week.

If someone wants to make a same printer, you note that there are better options (Cartesian).

All the polar printers, including mine, are concepts that need to be polished.

My printer meeting the most difficult concepts that occurred to me. Collapsible design, no Cartesian movements and non-use of linear bearings (Sarrus) and Bowden.

I am too ambitious XD

Still, the results are more than satisfactory]]>

A very nice design, are there any plans to release files and a BoM? (sorry if this was answered in the link, I don't speak Spanish at all.)]]>

Is a bipolar printer and the Z axis is a Sarrus.

I have thought of doing several posts on my website to explain the code and the mechanics (and the problems I encountered).

But for now, and for lack of time, I made a brief explanation. :D

+info: [robertmenetray.com]

[youtu.be]

I will be happy to answer questions or suggestions in this forum.

Please note that English is not my language, forgive any mistake.:(

]]>

You can also hide them behind non-magnetic materials, which is nice for aesthetics, which of course made me think of your sleek looking printer.

[notanumber.net]]]>

I'll stabilize my frame and fix the stepper-problem and should get an even better quality.

However, the photos of the torso show the accuracy of the positioning between layers quite good, because the print is made in spiral-mode (only one layer wall thickness).]]>

]]>

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