Programming our Arm

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.

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.

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.

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.


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.

10 turn pot? Encoder? Gear Tooth Sensor? Accelerometer? Gyro?

What is the application?

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.

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).

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?

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.

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.

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.

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.

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 (=

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.

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

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? :frowning:

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 (:stuck_out_tongue: ). 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…:smiley: ).

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.


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.

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