Tales of a modern life: Arduino

Posts mit dem Label Arduino werden angezeigt. Alle Posts anzeigen

2015-11-16

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

2013-11-04

BMPCC LANC and Sysclk DX (USBee DX clone)

I received my Sysclk DX from China. It's an affordable clone of the USBee DX.
A 2 channel USB Mixed Signal oscilloscope paired with an integrated 16 channel logic analyser.
The first task I'm giving it is to analyse the LANC protocol on the Blackmagic Pocket Cinema Camera.
Why? Because I need to have a way to meassure what's supposed to be on the wire and what is actually there to implement LANC into an Atmel microcontroller and build a better LANC remote. ;)

First try:
On a breadboard I pulled the data line high and tried to analyse the signal. The camera is supposed to send data packets... absolutely no luck. :(

Second try:
I put the breadboard in between a working LANC remote and the camera and ran the logic analyser.
I may be doing something wrong but I can't see anything on the wire. The LANC remote however works fine!

UPDATE: Third try:
I dumped the Sysclk DX and got my old Usbee AX and it worked fine.
I found the following LANC commans on the Blackmagic Pocket:
//LANC(0x18, 0x33); //send REC command to camera
//LANC(0x28, 0x45); //send MANUAL FOCUS FAR command to camera
//LANC(0x28, 0x47); //send MANUAL FOCUS NEAR command to camera
//LANC(0x28, 0x53); //send IRIS+ command to camera
//LANC(0x28, 0x55); //send IRIS- command to camera
LANC(0x28, 0x43); // AUTO FOCUS
Update: Blackmagic answered: IrisAutoAdjust = 0x28 0xAF
I search in the area of 0x55 and 0x47 but could not find anything that triggers auto iris or auto focus.
Aparently these commands do exist but I don't know the command code.

UPDATE:
Using the code from "Control your camera" it seems to work more reliable when removing the -8ms adjsutment for the digitalWrite command and replacing that with a macro from here:

#define fastWrite(_pin_, _state_) ( _pin_ < 8 ? (_state_ ? PORTD |= 1 << _pin_ : PORTD &= ~(1 << _pin_ )) : (_state_ ? PORTB |= 1 << (_pin_ -8) : PORTB &= ~(1 << (_pin_ -8) )))
// the macro sets or clears the appropriate bit in port D if the pin is less than 8 or port B if between 8 and 13

my send-byte routing now looks like this:
void send_8(char dat) {
char abit;
char index;
for(index = 0; index <= 7; index++) {
abit = ((dat>>index) & 0x01);
if(abit==1) {
    fastWrite(cmdPin, HIGH);
} else {
    fastWrite(cmdPin, LOW);
}
delayMicroseconds(bitDuration);
}

//Byte is written now put LANC line back to +5V
fastWrite(cmdPin, LOW);

}

Also: I can successfully power the Arduino Uno from the LANC cable.

2012-09-15

Arduino ADC confusion

I don't get it.
I want to meassure 1g-200g with an #Arduino .
Alexis Wiasmitinow made me a PCB using the
http://www.robot-italy.com/it/3132-micro-load-cell-0-780g-czl616c.html
750g load cell and an op-amp with adjustable gain and offset.

When I place a 150g load on the cell it sometimes increases *or decreases*.
When I remove that load it sometimes doesn't return to the value it had before.
When I adjust the offset to get very small values with no load placed on the load cell, I get no change in the value at all. With higher offsets I get value changes depending on the gain.
But never more then 3-4 bit of resolution .

I'm using pin A1 on a Arduino with the LCD-Keypad shield connected (shield uses A0 and 4-10).
http://www.robotshop.com/dfrobot-lcd-keypad-shield-arduino-1.html

Any idea?

Update: We solved it via Skype chat (G+ hangouts only produced "server error" and "severe server error".)

I simply had my load cell mounted the wrong way. My load was in the wrong place!!!

Tales of a modern life