Mike's SCARA Robot

[macardoso]

Whoooo! Figured it out. Turns out there is a misprint in the manual and the T2 gearbox ratio is really 80:1! That would really mess up the kinematics. I also confirmed the T1 is 100:1.

I did have to pull the harmonic drives apart to get these numbers so all of my home position measurements are now wrong. No big deal, I will remeasure.

Here is the T1 gearbox showing the Harmonic Drive Corp part number 52-100-960006 (100:1)



Here is the T2 gearbox showing the part number 25-80-960007. (80:1). "25" refers to the diameter of the gearbox.



I still want to validate some other numbers but this might be all I need to fix my issues.

 

[Boswell]

Gotta hate it when the documentation is wrong. Glad you found the issue. I was also wondering if you could build a jig to help calibrate it. some way to bolt flats on the different moving parts that you could get reliable/repeatable measurements from?

 

[macardoso]

Gotta hate it when the documentation is wrong. Glad you found the issue. I was also wondering if you could build a jig to help calibrate it. some way to bolt flats on the different moving parts that you could get reliable/repeatable measurements from?

Oh this has been driving me nuts. I've been in a great mood all afternoon after figuring this out.

Modern robots have a place to bolt on a mastering fixture which has indicators. Once the robot is moved such that all the indicators read zero, then it is in a known position. I could probably come up with something like this... Haven't thought about it yet.

 

[macardoso]

Got the homing angles measured again just as before. Took 26 measurements for each joint and threw away the highest and lowest outliers. This should be moderately accurate, but between the table flexing and the perhaps 80” loop of bendy stuff between the end of the robot and the tip of the indicator, I found the measurement to be very fiddly. I got values within about 1/2 of a degree at the joint which actually is a fairly large distance at the end of the 18” section of arm. I’d like to come up with a more accurate way to measure this, but it will do for now. Here is the T1 zero angle offset measurement setup



I was able to get the indicator over the centerline drawn on the table by clamping a level to an angle plate, then centering the indicator tip on the edge of yye



And repeated for T2



After updating the program to reflect the new gearbox ratio and zero angle offsets, I booted It up and it worked! All the motion is now linear and constant velocity. Even the absolute distances are accurate as closely as I can measure. It is mesmerizing to watch. I need to write a sample program and then I’ll get a video together to show it running.

Big thanks to everyone following along and commenting. It gives me a drive to keep going on this!

 

[macardoso]

Here is the very first program running coordinated motion with inverse kinematics and path planning. This has been a long time coming.

The robot is executing a series of point to point moves with linear interpolation and constant velocity between each move. The motion is programmed in XYZ space and the PLC handles calculating the joint motor motion. Motion to each successive point is velocity blended such that the commanded position comes within 0.005” of the specified target position.

Move velocity is 10 inch/second. I've tested it up to 30 inch/sec so far without issues. The whole table starts shaking long before then.

 

[Boswell]

Way Cool ! It is great to get to see the results of you considerable effort. Thanks for bringing us all along.

 

[macardoso]

I am working hard at creating a requirements document for the robot's control software. This will help me organize my code and stay focused on the goals. There are a lot of "neat features" that are not critical to the function of the robot but will be fun to try to invent.

Likely the most challenging will be a routine which continuously calculates the robot's workspace based on the tool offsets and orientation, then looks at the robot's position and velocity to determine if the robot is going to exceed the working space or crash into an avoidance zone that has been defined. If this is true, then it will activate a maximum rate stop to keep the robot from entering a singularity or otherwise crashing into an object I wish to avoid.

I am also designing the motion control architecture which will allow me to accomplish my goals. Here is the one I have designed for the V33 software:



There are 3 coordinate systems (blue), 4 real motors/servo drives (grey), 4 analog servo cards (red), and 10 virtual axes (green). These are linked with background motion instructions (purple) and commanded motion instructions (orange).

Without going too deep into how this works, The red analog cards send commands to the grey servo drives - simple. The 4 red analog axes are grouped into a robot coordinate system (blue). This is linked through the Motion Coordinated Transform with Orientation (MCTO) to the cartesian coordinate system (blue) with six virtual (non motor controlling) axes. 3 axes are for the cardinal directions X, Y, Z, and the other 3 control rotation about those cardinal axes. My robot does not support rotation about X or Y so those are essentially unused. The command Motion Coordinated Path Move (MCPM) controls this coordinate system and supports linear motion with coordinated orientation control (change tool rotation while moving).

In order to support circular motion, a 3rd coordinate system (Command CS) is added with 3 cardinal virtual axes (green). These link to the Cartesian coordinate system cardinal axes through 1:1 electronic gearing (Motion Axis Gear - MAG). The non-orientation controlling coordinated instructions Motion Coordinated Linear Move (MCLM) and Motion Coordinated Circular Move (MCCM) can now be used. All of this is linked to a master speed reference virtual axis using Master Driven Coordinated Control (MDCC) and Master Driven Axis Control (MDAC). This is the most complicated part but it allows me to turn one knob and adjust the overall speed of the robot. This can accomplish speed override and feed hold very easily. The master speed is set by the Motion Axis Jog (MAJ) command against the Master Axis.

Orientation of the tool can be controlled in coordination with a linear move using the MCPM instruction or independently using a Motion Axis Move (MAM) instruction while another instruction is running. I can issue commands only from the orange blocks.

This is probably the most complicated motion structure I have ever worked with and will be the first thing I actually program.

Once I get the requirements specification a little more polished, I will share it with everyone.

 

[macardoso]

Alternatively, If I wanted to program in V32 (before automated control of tool orientation) then the architecture would look something like this:



Fewer axes but a lot more motion instructions. One challenge is that you cannot have more than one Motion Axis Gear (MAG) active on a slave axis at one time. Therefore I'd have to come up with something else for T3 and T4 since they have too many gear instructions. There are other instructions that can be set up to behave like a gear if needed.

After all this, I'd still be short of the Tool Center Point (TCP) control available only in V33.

 

[brino]

Mike I was following along .....to a point....
.....but now I think these smilies say it best......














-brino

 

[hman]

I've ALWAYS been impressed with the ability of robot controllers to do the coordinate conversions required for cartesian motions and linear (or other path) interpolations - in real time!!! It really illustrates the computation speed of computers (even the ones 20 years ago, when your robot was built). As with others, I've been "lightly" following your fascinating build, but you've definitely left ne in the dust with respect to many of the details.

Congratulations on the first functional test!