Is there a way to have a motor HOLD an arm up in the air at a fixed position without having the weight of the arm rotate back downwards? I have heard of a programming acronym called PID loop. But I am not sure exactly what this is. Do most of you just calculate a gear ratio needed to raise the arm efficiently using the stall torque of the motor?
Help! And thank you in advance.
Ken
The way our team usually does it is by using 1/2 or ~ 60% stall torque of the motor in our calculations. Rarely do we have back-driving problems then, but in the event that we do, we also will counterbalance our mechanisms with some elastic tubing as well. A combination of these two things should give you a sweet spot where mechanisms will not back-drive and motors will not be operating at stall torque. It is not ideal to have to provide power to the mechanism in order for it to maintain a position.
Search around on the forums, and you’ll find a lot of information on how to keep an arm in position using programming as well as with mechanical support. Here’s a place to start: https://vexforum.com/t/arm-help/19650/1
Mechanically, this can be accomplished with gearing (chain too). Basically adding torque to a joint will increase it’s ability to hold with a weight on it without the need to be powered. This comes at the cost of speed of course.
If you need significant speed, I would recommend a dual approach. Some gearing, and some software control.
In order to apply power to a motor in order to maintain a given position, a feedback loop is needed. For this, your going to need a sensor (such as a POT) to provide feedback to the robot.
With said feedback, you can create a control loop which will aim to keep the joint at a given position. If the joint has significant weight on it, I would recommend a PID loop.
PID loops fall into the “more advanced” programming category, but the idea is simple and easy to find material on.
Now if there is next to no weight on this joint, I would just use a servo.
-Cody
or you can use elastics to help assist the weight of the arm (or whatever thats sagging down)
[Delta]
Just a piece of advice:
you may write a debug program that getting analog value from one of your joystick, and use that joystick for driving the robot arm. note down the minimum value which prevents the arm from dropping, and the maximum value which can still keep the arm stable and not beginning to rise. Then you may take the mean of the maximum and minimum one. Generally, it should be the motor output value which can hold the arm at any position. it may not be the best solution comparing with other algorithms like PID, but its performance is still acceptable.
There are many ways to achieve that… of course PID method will work. But I think it will be a case of “over-kill” to apply PID approach for this case.
Simple methods like increasing the torque (ie. change gear ratio), using the latex tubing or using software programming (ie. potentiometer) will do the trick.
hmm, many of you are suggesting a pid loop
but that would still put (a bit of) strain on the motors if it is just resting at that position
whats wrong with adding a few more elastics to (for example) the 4-bar?
Nothing wrong with using elastic… as i had mentioned earlier, using latex tubing will definitely do the trick as well.
but the main issue with relying on elastic alone is that - elastic being elastic… it is difficult to accurately and precisely determining the position (or angle) of your arms. This might give you problem during programming skill challenge or even certain autonomous movement.
my personal preference is a combination of using elastic and PID… elastic to reduce the strain… some form of PID to have better control 
Yeah, my thoughts exactly. Just a side note though, most people don’t actually have PID control on their arms; it’s usually just a proportional correction loop, not a proportional integral derivative loop.
[Delta]
Look,
PID comes up pretty often here on these forums. Here is the end all:
Here’s the breakdown:
The “P” is the proportional, the proportional is a linear change based solely on the error. The P term is actually the error multiplied by a constant which is set when tuning. The P term does not factor in your rate of change at all, for this reason a P band (in a perfect world) will always overshoot it’s target by some amount.
For this reason, P loops are not advised, but (thanks to friction and acceleration) are acceptable.
The “D” term, or derivative, factors in, you guessed it - rate of change (yay calculus)! What this means is that a PD loop will not only factor in the error, but it will adjust itself as it approaches the set mark to not overshoot. The “D” term (when tuned correctly) should smooth a signal out.
PD loops are best used when a linkage does not have a constant load
Finally, the “I” term is the integral. The integral is a sum! The “I” term is constantly summing the amount of error present in a loop. Conveniently when this error is consistent (IE gravity), the integral can find the needed amount of offset signal to deliver the right amount of power to the motor to sustain the load, and thus hold a load at a constant position.
PI and PID loops are really only for situations where a constant force is being exerted on the control loop. Since our robots work in an gravity-enabled environment, we often need to use the “I” term.
http://www.expertune.com/tutor.html
[http://www.eetimes.com/design/embedded/4211211/PID-without-a-PhD
PID really isn’t that hard, just read up on a proper tuning method and utilize a very function/thread/OOP approach to the code, which you should already be doing anyway! Modular coding is good coding…
In fact PID loops and tuning are actually very good programming exercises to do anyway, rig up a small test setup with a potentiometer a motor and a piece of metal with a detachable weight on the end and have the programmers play with various loops and tuning values. Should be a fun application of programming with functions, and an application math you never thought that you were going to use in the real world.
-Cody](http://www.eetimes.com/design/embedded/4211211/PID-without-a-PhD)
[Delta]
Wow… Cody really hits the nail on its head!!
Really well explained and defined 
Thanks,
Having fulfilled my engineering, CAD and robotics desires, and having no animation work currently, I’ve decided to drive into programming topics with the aim of becoming an independent game developer.
Particularly OOP stuff, so C++ and Java. Additionally I want to bridge my knowledge of 3D and software engineering via OpenGL. Also, I’m convinced that we now live in a multi-platform world, so I have no interest in single-platform solutions (like DirectX), instead I’m interesting in multi-platform solutions like Qt/Java.
So things I’m diving into now are:
So with these topics in mind, PID is now somewhat trivial. It’s half pre-calc topics and half programming with a dash of control/signal stuff (which is relatively easy stuff).
Guess I’m just tired of seeing people and teams run in fear when PID comes up, either that or they look at the concept as if it’s some kind of “black magic.”
Anyway, life is pretty good. When this is all said and done, I’m going to be a one man army capable of doing all the necessary tasks required to create a company, a product, a brand and ultimately make (lots of) money.
-Cody
This solution was simple enough for us to implement, but worked as well as we needed it to. I posted our pseudocode modification of it here.
@Anarkia: Xie xie nin!
My team’s robot consists of primarily latex tubing. It is the duct tape of vex.
That and zip ties, those are good too!