Single-Arm Robot

I’ve been contemplating this video and others like it and wanted to see if I could build a robot arm for playing games on phones. I started looking at dual-arm SCARA robots but decided that a single arm would be better suited to the task as there needs to be a camera looking at the phone screen and there is less to get in the way with a single arm SCARA.

Looking for an open-source design to get started with I found one on Thingiverse which didn’t look too complicated although, at the time, nobody seemed to have made one.  I got to work printing out the parts – which took a couple of days on my Ultimaker Original.

Thingiverse SCARA by Idegraaf

 

Unfortunately the parts didn’t go together as easily as I would have liked – mainly I think because there was no allowance for tolerances in the original model design – so, for instance, the space to accommodate a 15mm outer diameter linear bearing was exactly 15mm in diameter. On my 3D printer that isn’t workable so I had to re-draw many of the parts (I used Rhino 3D) from the STL meshes and increase the openings where needed.

I then had some trouble with the belts used to drive the arms. I wasn’t able to find 160 teeth belts cheaply in the UK so I bought some 158 teeth ones. They were, unsurprisingly, too tight so I had to re-print the motor mount pieces with the holes moved.

I also found that the 320 teeth belt (which I did manage to source) was too tight. In this case I solved the problem by re-creating a 60 tooth gear to replace the 62 tooth one in the original design. I found a great SCAD template for this here – and modified it accordingly.

Control Electronics

To control the steppers I used a pair of driver modules like this which have a micro-stepping ability. This allows a conventional stepper motor (with 1.8 degrees of movement per step) to be driven in increments of slightly over 0.1 degrees (actually 1.8/16 degrees).

For the controller I wanted to try out a MicroPython PyBoard I had recently bought together with an LCD display and touch keypad. It didn’t take much time to get to grips with and I can heartily recommend this as an alternative to writing C++ for every little project.Scara Arm Control

 

Test Program

My simple test program worked fine to move the arms around by pressing the buttons on the keypad.

Circle Intersections

The next thing to do was to work out how to move to a specified position in Cartesian coordinates. I started to work out the geometry and quickly realised that I essentially had two intersecting circles, one centred on the point I wanted to reach and the other centred on the origin of the robot – i.e. the position of its shoulder.

Searching the internet I found a collection of geometry and then a convenient algorithm in Python – copied below – to perform the calculations.

Moving to an XY Position

The only challenge then was to perform a couple of simple trigonometric calculations (to calculate the required angles at the two joints) and drive the stepper motors to the desired positions.

A significant aspect of this is that there should be no cumulative error. When a stepper motor moves it can only move in increments of a little over 0.1 degrees (using microstepping as described above).  If a particular angle requires a movement of, say, 10.03 degrees then the number of steps will be rounded to approximate this angle. If this rounding is performed repeatedly there will be an increasing error in the angular position. To avoid this I remember the location of the “elbow” and the number of steps each arm segment has performed since being at the origin position – which I assume is straight out initially. Then everything is calculated from this origin position.

A further piece of minor trickery is the section of code which actually moves the motors. This uses a variant of Bresenham’s Line Algorithm which handles a situation where one variable increments on each loop and the other only periodically – the great advantage of this approach is that it can be done with integer arithmetic if required – although this particular MicroPython implementation has floating point.

This is actually the final code with an additional fix which is described below.

Drawing a Straight Line

Next step was to attempt to draw a straight line.  The code is simple now that we can move to an X, Y position. The only thing we need to do is draw the line in small chunks because the MoveTo(x,y) code doesn’t guarantee that the point will be reached by moving in a straight line – it simply moves in the most efficient manner.

The result, unfortunately, wasn’t so good as can be seen …Straight Line Attempt

 

The line (marked with the red arrows) started ok – it was drawing from top-left to bottom-right and is reasonably straight for about 2/3 of its length. But the code then detected that it needed to change from a “forehand swipe” to a “backhand swipe” and rotated the arms accordingly. However, as can be seen, the continuation of the line is not where it should be – the discontinuity between the two lower red arrows.

A Flaw

The first test didn’t show up an unexpected consequence of the changes I had made. But when I tried the straight line test it immediately showed a problem.

Eventually I realised that when changing the number of teeth on the pulley (which transfers the motion from the lower arm motor to the lower arm itself) I had unbalanced the two intermediate pulleys in an unexpected way. I actually had considered that this change might affect the ratio on the lower arm but had decided that the same intermediate pulley is used by both the motor drive belt and lower arm pulley. So actually there is no such change as the two cancel each other out (i.e. there is a 20:60 ratio on the first belt and a 60:62 ratio on the second so the overall effect is just 20:62 as it was originally).  But what I hadn’t thought about is that when the upper arm moves (and the lower arm motor stays still) there is an effective turning of only the second stage of the drive belt mechanism. So when the upper arm moves through 90 degrees (for instance) there is a consequential movement of the lower arm by:

(90 * 62/60) – 90 = 90 * 1 / 30 = 3 degrees

Scara Arm alignment

 

So in the end I added code to correct the angle calculation and tested with customised graph paper as you can see above.

robSingle-Arm Robot

Comments 8

  1. Swift

    I am thinking of building a scara 3d printer. How many hours of design and testing did it take you to get to this point?
    Are there any regrets? Things you would have done differently?

    1. Post
      Author
      rob

      Hi Swift, apologies for slow reply. I have tried to do a few things with SCARA arms and, so far, I haven’t managed to conquer the “droop” that these kinds of arms often have. The Morgan dual-arm looks pretty solid but I do think that to accurately create layers with less than 0.1mm accuracy across the layer would be a tall order for any SCARA arm that I could conceive of building. I’ve also experimented with deltas but I really find it hard to better the Prusa style rep-rap geometry for stability and consistency. Best Rob

  2. Pingback: Play 2048 with a Robot Arm | robdobson.com

  3. ZhangZQ

    Hi, I also built such arm, and I also found the belt is very tight, so I modified the gear from 62 to 60 teeth, And then I want to drive it using Marlin, but it can’t run the straight line. Did you try marlin?

    1. Javier

      Hi! I am also thinking on building a printer based on this scara. Why it cant run an straight line? Does it make it curved? There is an experimental Marlin that include normal SCARA (not the morgan one) Do you have a video or blog where I could see your work? Thank you in advanced!

      1. Post
        Author
        rob

        There is no problem drawing a straight line if the maths is correct! The problem I’ve had is mainly due to testing and the fact that the base of the arm is too small and the vertical supports are not rigid enough. I’m still working on another version but haven’t really got a solution to the rigidity of the vertical posts.

    1. Post
      Author
      rob

      To be honest – so am I. It’s taken quite a bit of effort to get this far – mainly because I had to print pretty much every part at least twice – and redraw in the middle – which I wasn’t really banking on.

Leave a Reply

Your email address will not be published. Required fields are marked *