Tales of a modern life: Fun with robot arms

The Plan

I'm planning on building a large robot arm using stepper motors.
It shall execute G-Code with absolute, cartesian coordinates.
The job it so assist with some repetitive tasks in the workshop when casting small batches of parts that for quality, material or number can't be 3D printed individually.

As with all my blog postings, I'll keep updating this one.
It documents one, single project in all (public) details and all findings as I progress.

Start Small

To start small, I got myself a laser cut hobby-servo driven robot arm and attached it to an Arduino Uno with my usual LCD+Keypad Shield.

The objective is to get my inverse kinematic calculations right and to see how much can be acomplished with this much simpler setup already.
I also wish to experiment with absolute posistion feedback by attaching and ADC channel of the Arduino to the potentiometers of the hobby servos (maybe using a multiplexer to get all of them).

Hobby Servo issues

So far I identified a number of issues with hobby servos, that I want to document here:

Power supply

Running the Arduino from USB you only have enough power for 1 servo.
Adding a 12V 1.5A power supply for the passive step-down DC-DC-converter of the Arduino Uno is enough for 2 service. Only the 12V supply works for 1 servo only.
The path to go seems to be a 5V supply powering the servos only, pulled to a common ground with the Arduino (so the PWM control signal has the right right voltage level).

If the display gets dark, the servo motion jerky, the software resets of ommits steps, then you are lacking power.

Jerky movement

The default servo.h that comes with the Arduino SDK allows for an integer of 0-90 (degrees).
This isn't a very fine control.
I found in this blog posting that:
It also assumes minimum and maximum PWM timings that are beyond the range of many servos.
You should set minimum and maximum milliseconds in the attach() call and use the servo.writeMicroseconds(int milliseconds) call with 1000-2000 ms. This allows for a much finer control and stays within the allowed range for your servos.

G-Code interpreters

I'm currently evaluating options for g-code interpretation.
What I want is the g-code to contain X,Y,Z coordinates, gripper opened/closed and interpret a number of micro switches as probe inputs or end-stops.

GRBL on an Arduino seems to be a common option but is limited to 3 axis, drives the Arduino at the absolute limit of it's capacity and only has a serial/usb-serial connection.
A Raspberry Pi CNC-Head is a GRBL-running, Arduino-compatible Atmel board as a shield for a Raspberry Pi. For 3 axis maximum this would be a simple solution.

I'd rather go with a Raspberry Pi that can be trontrolled via Ethernet and communicate with other machines to coordinate and integrate. E.g. tell another robot that it has placed an item or be informed that there is one of multiple possible things to be picked up and moved.

I found the L6470 dual-stepper controllers. Simply calling them stepper drivers is wrong because they do their own timing, support microstepping, take end-position, maximum speed, acceleration+decelleration as inputs, support a hard-stop input directly, have a number of safety checks in there,... and work via SPI. Even daisy chained, so multiple axis stay in sync.
(Simple "stepper drivers" just take DIR+STEP input pins.)
Of that that still needs the actual interpreter -part.
I'll have a look at rs274ngc . It seems to be the old base for the EMC g-code interpreter.

Next steps

Next I'll

convert my test-code to use writeMicroseconds()
map the servo-locations to angles
implement my inverse kinematic code.

Designing the Real Thing [TM]

TODO...

manipulator

My manipulator is a fairly standard gripper design that has been modified to perfectly grip one specific type of container.
Nothing special about it, except that I was too lazy to design proper gears and thus am simply using 3 9g servos opposing each other. Each gets the same signal and each moves one side of the gripper.
These things cost about 1.20eur, so I don't bother with the time to save one.

Y+Z axis (arm)

I'm definately going for an arm-type that always keeps the tool horizontal automatically.
That means less degrees of motion and thus more stiffness. (And less things to worry about.)

I'm also opting for maximum stiffness and am using bearings everywhere, so the arm stays accurate and lasts for a great many moving cycles without any wear and with little resistance.
For the attachment to the stepper motors, I'm thinking of using this:

involute spur gear generator (with proper undercuts)

X axis (base)

The arm is not to have a rotational base but slide along a table-edge.
Linear motion systems for >=3m length are hard to find, so I'm thingking about having it drive between 2 aluminium profiles using tracks.

Another option would be CNC milled rails in wood.

on thingiverse
involute gear part of the Guerrilla guide to CNC machining, mold making, and resin casting

Tales of a modern life

2015-11-16

Fun with robot arms