Correction for arm
 

I decided to take on a task, now that I have a bunch of free time, and not a lot of robotics to do. Since we don't have the robot, I've been doing Misc programming stuff on older robots, and thinking up useful programs to use. I've now decided to write a correction into our arm from last year, because when we drove it at parent teacher Conferences, the new kids on the team nearly destroyed the arm due to it's tendency to move quickly and have a high angular momentum. So I'm wondering exactly how one would accomplish this in the code. I know in my head, how to do it mathmatically, we did some problems like this in physics. I'm guessing some kinda stuff with POT's and some nifty calculus, but I'm not sure how to put it all together, Some concept help on this would be appreciated, I'll look for a good pic of us and our arms, so you can get an idea..

Hopefully this link works :DClick here for the Robot Pic
If the pic doesn't show up, tell me, and I'll beat Geocities over the head, and then upload it to my PWS, and post a link to that.

PS...It was very hard to find a picture of the robots arms, close up and with us not doing bad, Last year bad..This year good....
Thanks
~Alec

You probably want to use a PID (Proportional Integral Derivative) control algorithm with feedback coming from potentiometers on the arm. PID control has been discussed on this forum before, but I could not find the thread. Here is a link to some lecture notes on it from an engineering class here at Notre Dame, the important stuff begins on page 8 or 9:

Feedback control notes

If anyone knows the link to the previous thread discussing PID control could you please post it.

Hope this is of some help.

Eric

PID
 

I was browsing the forum a few days ago, and I remember reading a thread about PID, and I think I remember where it is, So I will check that out too. Thanks for the help.

PID thread
 

It's here

Re: Correction for arm
 

You've said a couple of different things here. (1) you wish to "write a correction" apparently to slow it down, and (2) talking about changing things from however you're doing things now to a pot feedback system.

The first is simply "slew limiting" (controlling maximum speed) to make it more controllable, but the other involves changing things to a feedback control setup (servo / PID loop).

Please describe your current control setup in more detail. Tell us how it behaves now, and exactly how you want it to behave. You said: "I know in my head, how to do it mathematically".. Feel free to spell out what you want that way (and how that differs from current behavior).

Given that, we can then discuss in more detail which solution would be best for you.

Remember the KISS principle. PIDs are cool, but you may not NEED a servo setup, and if the pot or its wiring/connector breaks (and you've left out limit switches and manual overrides), you've got bigger problems. Simply gearing things down, using a Max_Time_On counter variable, or programming a speed ramp up&down curve might be better and more reliable. Gearing down limits your top speed and gives you more power for stopping right there.

(BTW... the robot pic link doesn't work...)

- Keith

I'm not sure if this is exactly what you want to do, but it sounds like the movement is too sensitive - if you put the joystick suddenly full foward, it just shoot up; the drivers need to be more gentle with it, but it's kinda hard under pressure. Do I have that right?

If thats so, my team solved it not using PIDs (we have no idea what they are), but adding 'lag' to it. Basically our program works like this.

Say during one cycle, the input is 128. The driver gets a bit excited, and shoots up to 254. Our robot would normally just shoot off, and this is damaging to our motors, so we added some lag.

Basically during the first cycle, it saves the pwm output from the joystick to a variable - call it last_pwm. During the next cycle, it gets the difference between last_pwm and the current_input. If this input is greater than a max_move variable (we have it set for 10, but this is the tweaking part), the output to the pwm is the current_input + max_move. Else, the output is the input.

So, back to our scenario. Say during cycle 1, the input is 128. During cycle 2, the input is suddenly 254. The program calculates the difference, sees that delta_input is greater than max_move, so it outputs 128 + max_move to the pwm.

Cycle 1 - input = 128, last_pwm is set to 128
Cycle 2 - input = 254, last_pwm = 128, delta_input = 126, 126 > max_move, so pwm = last_pwm + max_move, or 138 (and last_pwm is set to 138)
Next cycle the output to the pwm would be 148
Then 158
Then 168
...
Then 148
Then delta_input is less than max_move, so output to the pwm = 254.

This makes your motor respond slower to the input by adding a bit of lag to it if the difference is too high. So instead of going right from 128 to 254, it increments by 10 every cycle until it reaches 254 (the 10 part should be adjusted depending how long your code is, and so, how long it takes to execute one cycle) Hope you see what we did - if you decide to do it this way and need some help writing the code, just ask

I'm gona add a bit to Dan's code. I believe i added the Delta_T variable to count the amount of cycles missed (if you hav elong code). Therefore, the only tweaking variable that you should have to change would be the "max_move". Basically, the higher it is, the less "lag", the lower it is, the more "lag" (this kinda goes without saying, but hey, never hurts to be specific).

I think that describes the "Auto-Calm Down" code (as we call it). If you need any help implementing this into your code, justdrop by our pit (Team 810) at nationals and either me or Dan (or both of us) will come over and help you. Also, if you need help with anything else programming wise, drop by and we'll try to help.