Programming our Arm [Archive]

brennerator

01-02-2007, 00:38

Our arm is controlled by a motor with a sprocket at the base of a long beam. Obviously there is much torque on this system, and when the motor moves slightly, the arm jerks a lot. Understandable. How can we make the arm motion more fluid persay--if we just twitch the joystick right now the arm makes a wide movement.

Second: If the motor stops the arm immedietly jerks back down. Suppose we wanted to keep the arm in a set position--how would we do that? So if we let go of the joystick, the arm would stay in the same position that it was in.

dpick1055

01-02-2007, 01:16

You could use a potentiometer and write some code to only use the max value sent to the arm. Then when you want to reset or go to some preset height press a button on the joystick. You can also create a dead band so that if the joystick moves to 135 it only sends 130 to the motor. You may also want to consider moving to different motors (I'm not exactly sure which ones) but out team has been able to create a smooth arm without any special code.

Tom Bottiglieri

01-02-2007, 02:00

While programming may help this issue, it wont completely fix the problem.

Based off of your description of the mechanism, it seems like the bounce in your arm can be attributed to slack in the chain drive system. Try tensioning the chain, and possibly writing code to limit your motor output values. Now, it doesn't have to be full out closed loop control.. some ramping up/ramping down of the output values should do the trick.

dtengineering

01-02-2007, 02:47

If you are going to use a motor to actively hold the arm in position, just watch current consumption and temperature on the motor. The Fisher Price motors that come attached to the plastic gearboxes, in particular, can let out the magic smoke fairly quickly if they draw current while moving slowly or stopped.

Not that they can't do it... just watch for it. Some of the other motors, such as the window motors, are less powerful, but also much happier holding position when stopped.

Jason

brennerator

01-02-2007, 12:34

Also, how would we sense rotation? Is there anything better than a potentiometer? THe potentiometer has only 300 degrees of motion, which is not suitable for our application. We would also like something that can easily attach to 1/2 inch shaft.

Tom Bottiglieri

01-02-2007, 12:42

brennerator

01-02-2007, 12:58

I am trying to measure how far each motor should move for presetting the arm. The arm is jointed with powered 1/2 inch shafts. I have not figured out an effective way to attach the pots to it.

Jonathan Norris

01-02-2007, 13:04

I am trying to measure how far each motor should move for presetting the arm. The arm is jointed with powered 1/2 inch shafts. I have not figured out an effective way to attach the pots to it.

Its simple, get access to a simple lathe, and bore a small hole in the end of one (its usually 1/4"). Then if you can setscrew the POT in place, or grab some hot glue. Then all you need is some simple mount to keep it in place and hopefully protect it.

kaszeta

01-02-2007, 14:33

If you are going to use a motor to actively hold the arm in position, just watch current consumption and temperature on the motor. The Fisher Price motors that come attached to the plastic gearboxes, in particular, can let out the magic smoke fairly quickly if they draw current while moving slowly or stopped.

I'll second this. Team 95 has used FP's for running arms before, and we had to add a deliberate "twitch" to the arm to make sure the motors weren't stalling (after burning two FPs).

brennerator

02-02-2007, 12:09

Can we put ten turn pots on the motor shaft itself? Would that be effective. I know that it will only turn 4 times...Is a ten turn pot a beast to program tho?

Jared Russell

02-02-2007, 19:18

One solution to help reduce the "jerkiness" is to apply a low-pass filter to that motor's output. A low-pass filter smooths everything out so that the arm motor PWM value can only change by so much in a given time.

http://en.wikipedia.org/wiki/Digital_filter

If you need help implementing one, I'd be glad to help. A simple, first order IIR low-pass filter on PWM01 would be like this:

// Put this at the top of user_routines.c
#define LP_PARAM_N 900l
#define LP_PARAM_D 1000l

// Declare this variable at the top of Default_Routine()
static unsigned char pwm01_old = 127;

// And this one too
unsigned char arm_command = 127;

...

// After you do whatever calculations you need for the arm, store the value in arm_command
pwm01 = (unsigned char)(pwm01_old*LP_PARAM_N/LP_PARAM_D + arm_command*(1000-LP_PARAM_N)/LP_PARAM_D);

Tweak the "LP_PARAM_N" parameter (the numerator of the filter constant) between 1 and 999 as you need. The lower this is, the quicker the response will be, but the more jerkiness. The higher it is, the slower the response, but it will be much more smooth.

You can do the same thing with floats more intuitively, but I try to avoid them wherever possible.

Andrew Schreiber

05-02-2007, 23:33

Simplest solution to the falling problem I'd say would be gas shocks to help hold the arm up... granted I can only go from what Ive managed to overhear from the people who do the building on the team (I'm almost exclusively electrical and programming)

As for positioning the arm, a pot is the simplest way. If you are worried about not being accurate enough there is a relatively simple work around that will make the pot 4 times more accurate (or seem that way). Inside the user_routines.h file where the analog inputs are #defined as whatever you call them you should see a bunch of code that looks similar to "(unsigned char)getAnalogVal(pwm01)>>2" or something like that... If you remove the >>2 and the (unsigned char) your pot will be returning values from 0-1023 instead of 0-255. The pots are actually built to do this as are the analog inputs in the brain. For some reason most people think that 8 bits is enough info. Oh well.

If you need to be REALLY accurate with the positioning of the arm I would say you should use a software PID loop. Try running a google search on it (or CD search) If you cant find anything PM me and I can try to help.

burkechrs1

05-02-2007, 23:45

try a counter wieght with sorings or something like that. we're using springs to help our arm move fluidly around its axis, we had teh same problem. It's pretty lightwieght too.

Uberbots

06-02-2007, 16:25

Dont stall the motor: the backdrive issue that you are concerned about is something that the mechanical team has to fix. We got around this with a worm gear drive in the shoulder joint of the arm, along with a spring to add force while going down and working against gravity.

stalling the motor will let out the genie (=

shawger

07-02-2007, 15:18

We are using a similar setup to the one the original poster described, except we have a 10-turn pot attached. We then have a proportional closed loop control system in which we specify a setpoint, and the code evaluates our current location, finds an error, and applies a correction to the motor. The logic really isn't that hard, but it will require tuning.

With this system, we are able to set three automatic heights as well as control it manually. It is important to note that manual control is still accomplished through the closed loop control, but the driver is varying the setpoint (in our case with a pot on the control board). We don't have any jerky movements so far.

The closed loop control system will automatically keep the arm in a set position. It will maintain its setpoint once it gets there. If you are using a joystick for control, the joystick will always return to the middle, so you will need some sort of code for remembering the value you were at.

Hope that helps.

robind

07-02-2007, 15:27

I'm using an encoder wheel, geared for higher precision. More accurate than a pot from my experience (easier to code, too).

Alchemist

07-02-2007, 16:34

Well,There are several ways you could go about this. I'm only a student and still learning, Yes I admit it. But what we did was we set "0" on the control stick to 127 (Since the joystick registers from "0" to "255", this is half) meaning, when you don't touch the joystick, the returned value is 127, full forward is 128, fell back is around 100. If you don't have it like this, full foward is 255 and full back is -255. also, you may use "If" statements to say (If "value you use for the joystick" > 200: "Value you use for joystick" = 200) and the same for the opposite. Like I said, I'm still learning, and I'm not 100% on how to do this exactly (the program mentor is busy since he is the main coach of the team or I would ask him). Anyone know how to explain better? :(

JBotAlan

07-02-2007, 17:38

full forward is 128, fell back is around 100.

Holy guacamole! Sounds like your mechanical guys really need to switch motors if you have to limit it that much...

My team has a few limitless pots that we will be using for our...manipulator (:p ). They go up to their maximum, then snap back to their minimum. I can't seem to find them on Digikey, so you're pretty much on your own for finding them...you might be better off using a plain vanilla encoder (please note that's not a technical term...:D ).

But please, rag on your mechanical guys to get rid of the slop in the system. It *is* their fault, and it *can't* be fixed in code. It can be slightly improved in code, but code is almost never the fix for a mechanical problem. This mentality will save you a headache. Big time.

And if you still lose the battle, post here and we'll gladly help.

JBot

lukevanoort

07-02-2007, 18:12

My team has a few limitless pots that we will be using for our...manipulator (:p ). They go up to their maximum, then snap back to their minimum. I can't seem to find them on Digikey, so you're pretty much on your own for finding them...you might be better off using a plain vanilla encoder (please note that's not a technical term...:D ).
You can modify some encoders to remove the mechanical stop and have it simulate a endless pot, it is really easy on RadioShack pots, but I have not tried others. With the RadioShack pot this results in ~60 degrees where there is no reading, but with two mounted so their ranges overlap, one can get the same effect as a endless pot, but it requires a little code.

ghost_dude2

07-02-2007, 18:31

Hey everybody out there i was wondering if anybody knows about auto desk visualization just reply if you do Thanks!!!!:cool: ::] :] :D

Alchemist

07-02-2007, 23:07

As I said before, I'm still learning (even after being on the team for two, and this being my third). The first year, I was the guy doing the chasis, and things lie that, last year I was a little programming, but still mostly the worker. This year, I'm programming fully but stil learing quite alot. I may have said a few things wrong. all in all, I believe that it'll all work out in the end. But, at the same time, I understand what your saying, and thank you for the help.:D I'll check it out and see if there really is something wrong. But i'm still confused on the programming thing alot..:confused: :(

shawger

07-02-2007, 23:09

Hey everybody out there i was wondering if anybody knows about auto desk visualization just reply if you do Thanks!!!!:cool: ::] :] :D
You'll probably get better replies in the AutoCAD / Inventor forum. http://www.chiefdelphi.com/forums/forumdisplay.php?f=57. And its not nice to hijack threads.

Golto

09-02-2007, 06:11

What we did is move the break jumper on the PWM and made a curve. Also, we applied a small backwards voltage to keep our arm in place

Alchemist

10-02-2007, 14:59

We have it on a lazy suzan type metal plate, so we can turn it and pick up the tube any where around our robot. Also, we Have the arm made of three seperate piece's, attaching them with motors, so the whole thing together is like a snake, and can have more mobility. we also tried to have an omni drive so the robot could go any direction from one spot without havingto turn, but we made a few flaws in the beginning that made it unable to do it that way. But the way the drive is set up now will still give us fair mobility.

paulcd2000

10-02-2007, 15:42

for ours, we use a rope wrapped around a spool to raise and lower the arm. it's great because one revolution of the motor moves the arm about 5 inches. with a low RPM, it controls amazingly

Alchemist

10-02-2007, 18:37

So your saying it's like a crane? Hmm, that could be good and bad. Are you using suction or claw? With suction I wouldn't think it's as bad, but if you have a claw or other type of grabber, you have to be percise. But, if your bumped it may swing and be hard to use. With suction though, it could still touch it, and with enough suction it would just latch on. Well Atleast, that's my opinion.

WGRAY

13-02-2007, 10:58

How do you "Tweak the "LP_PARAM_N" parameter (the numerator of the filter constant) between 1 and 999 as you need. " I am a rookie using easycpro, and your solution works great yet I would like to slow my motor dowm a little. Could you show an example of what the code looks like at both ends of the spectrum?
"between 1 and 999 ".

amirjpl

14-03-2007, 18:48

You guys have made some good points about controlling the arm. Now I am an electronics guy not a coder, but I can still do some programming if needed. Our programmer is lazy and never gets things done, so I was wondering if you guys had some ideas of how we could use an encoder (connected to a cim motor to control our arm) to give our arm a smooth and controllable movement. How can we control the speed of the motor based on encoder feedback.
We are planning to use the Y-axis of the joystick to control the direction of the arm.
We are using the Banebots encoders, and are ready to use the divider kits if necessary.

Some example code would be appreciated, because then I could understand the solution better.
Thanks in advance to all the helpers.

foemill

15-03-2007, 00:02

We have successfully used optical encoders with a PID loop for setting arm position. There's some good code to get you going at kevin.org. Also for a qick fix you can use the following calculation to reduce the joystick to pwm output values:

// defined at top of header file for ease of use...
#define BOOM_PWM pwm04

/****************************************
* this code fragment is contained in a function elsewere in your code...
* it divides your input in half. We used this to limit our voltage to
* the motors to 6 volts (1/2 of the 12V max)
****************************************/
BOOM_PWM = 127 + ((p1_y - 127) / 2);