Hello everybody.
I am new to the forum and to Arduino as well. In my microprocessors class we are required to develop the code to make a Rhino robot arm move. This arm has six 12 volt DC motors which are to be controlled with an Arduino Mega board, and the voltage will be provided through a custom built H mosfet board. The project requires that we "home" all six motors first, and then make them move. The "home" position is determined by 6 limit switches (one per motor) and we are not required to use a joystick or any other controlling device, just tell the code to home the arm and then move the motors to a fixed position of our choice.
This task is definitely too much for my level of knowledge so I thought I'd put it out there for the pros to give me some input, I will greatly appreciate it.
Thanks
R.
Do you have a link to the Rhino robot arm so one can know what it is?
If you are using the controller - why do you need code for an Arduino (the controller is the thing that controls the arm - it should have a fairly well documented RS-232 interface)?
The link refers to those motors as servos: albeit pmdc servos with encoders which I suppose do not work as servos typically known here, ie rc hobby style. (It would be a piece of cake, if they did work that way.)
Your first task is to find out how those servos are controlled: what makes them move and how does the encoder inform you of position.
(But then, as cr0sh asks, where does Arduino fir in if you're using the arm's native controller?)
They are servo-motors, as opposed to servo-mechanisms, technically, although
the distinction is moot when the angle of motion is limited. Servo-motors normally
have unlimited rotation and position, velocity and torque control options and combinations
thereof.
I guess the arm provides the encoder outputs and requires you to implement the
position feedback loops for each motor (ie PID controller typically)? Or does this
MOSFET board do that as well?
I own one of these arms as well (although mine needs some love to get it operational again) - it's an older version, with a very similar controller.
Again - I am not sure what the OP is attempting to do - my best guess is re-implementing the OEM controller - perhaps as a learning/educational exercise, and perhaps to allow for modern computer control.
The original controller itself could be programmed via a hand-held "teach pendant" (similar to older industrial robots) - or you could control it (IIRC) via the serial port (using BASIC via an Apple IIe or IBM PC generally).
The motors are standard Pittman DC motors with slotted encoders - there are one or two "home" microswitches per joint as well.
I would think that (provided the h-bridges are up to the task of controlling these motors) all one would need to do would be to command the h-bridge to move until you sensed the switch closing. Then, move the motor in the opposite direction, counting the slots on the encoder, until you sensed the other switch closing. The count would be the number of "steps" the motor could move the joint in it's arc.
You could make it slightly more accurate by moving the motor in the other direction, and counting downward - until you hit the other switch, or got to zero (if you hit the other switch before hitting zero - take your original count and subtract the remaining amount and use that as your "max number of steps"). Basically by moving from one end to the other and back, you would be able to get a fair knowledge of the limits of travel.
From there, it's just a matter of moving the joints, noting the counts, and stopping the motors when the desired counts are reached (well, you'd probably want some form of ramp up and ramp down as you started then approached the desired angle - to avoid overshoot - a PID could help here, but you might be able to get away with a simpler approach).
Once you have all that in place - then the hard problems begin - namely that of implementing forward and reverse (or inverse) kinematics algorithms so you can tell the arm to move from point to point in the work volume...
Hard problems? That's surely the fun algebra bit!
MarkT:
Hard problems? That's surely the fun algebra bit!
It all depends on your perspective, I guess. If you aren't someone who enjoys the stuff, the mathematics can be very frustrating, I would imagine.
RK/IK even more so - since depending on the configuration of the arm from point A to point B - there may be 3 or more potential solutions - then you get into how to select the "best" (by whatever criteria you select) solution (and this assumes there isn't any intervening obstacles for the arm to collide with - add sensing for those, and the RK/IK problem becomes extremely challenging).