Hi,
I am new to this. I want to steer the robot with an arrangemnt similar to the front wheel of a bicycle. At the top of the fork our plan is to mount a cim motor and gearbox.
does anyone know how well we can control the motor rotation to steer the robots.
Thanks!!!
Get a single turn 100k pot, mount it to a sproket and start researching PID control. You will probably need P I & D to get good steering feedback. You also might be able to spring load the wheel to make it center itself once power is drop from the cim.
To expand on the above: Assuming the gearbox allows the shaft to turn slow enough, you tell the motor to turn in one direction (for example, PWM 0 means counter-clockwise, 255 means clockwise) until the potentiometer (attached to the steering “fork”) reaches the desired position.
A potentiometer is a vailable resistor, they usually have about 270 degrees of rotation. Use a 5k or 10 k Linear potentiometer for this application (100k is too high a value). The center pin of the pot goes to thr Signal Input pin on the RC, one end pin of the pot goes to the RC 5 volt supply, the other end to the RC ground (All at the Analog inputs). This will return a value of 0 to 1023, depending upon position.
So, let’s say a left turn is a 184 reading on your potentiometer: Command the motor to spin in the correct direction until the pot reads 184. Or, take the steering input from a joystick (0 to 255), multiply by 4, and that’t the Pot’s target value.
It really requires PI or PID control, not hard to implement but really important.
Don
Potentiometers are pretty much the tried and true system but also look into the US Digital Magnetic absolute Shaft Encoder ( Part number MA3-A-B8 ) A bit pricey but very accurate and 360 degrees of revolution so you can revolve the wheel without the limitation of the 270 most potentiometers allow. ( Order the connecting wire as well.)
Steve
Molly,
I am guessing your plan is to use the CIM motor as the steering. Although this is a great motor for driving, the Globe motor may be better suited for you needs. It already contains a gear box that converts this little motor into a very powerful but slow system that lends itself well to the kinds of control systems mentioned above.
Okay I understand that part, but how do I implement PID onto easyC?, Sorry but it’s our rookie year and I’ve been reading on PID control and all I’ve been getting are the theory but I don’t understand how to code it with easyC
Very gutsy plan for a rookie team! I love it
Our team is struggling also (but using MPLab), so take my advice with a grain of salt, but the equations for PID are really pretty simple. A lot of teams use the C code from Kevin Watson
http://frc.kevin.org/frc/2005/navigation_frc2005_01_08.zip
there are files pid.c and pid.h in that zip file. There is a newer flavor of the same on his web page too, but the zip format was corrupt when i downloaded it.
I suggest you just take the pid function and implement the same formula using expressions and variables in Easy C. I’ve only used Easy C for about an hour, so I won’t pretend to know exactly how to do that, but I’m pretty sure it is straightforward.
The Hard part is getting the “tuning” right. The tuning tells your control system how Much to correct for a given error. If you correct too much, you overshoot, and then get an error the other way, which overshoots back to the original side, etc. If you correct too little, then the steering will lag the joystick significantly.
To further complicate life, there are 3 factors of interest, the P, I, and D factors, and each of them contributes a different problem.
If I figure out a good tuning strategy, i’ll let you know. 
Generally, I think people start with I and D zero, then get P so that it doesn’t oscillate out of control, then increase I until the control loop reaches the desired steady state value in a reasonable time. There are lots of texts on it and lots of variations on the control scheme, but the challenge I find is that you get such a short burst of test before the steering is locked all the way to one side. It would be easier if you could test the response to various steps without hitting the stop. I guess I’ve blurred the distinction between steering position control and steering velocity control (i.e. a pid controlling the speed that the steering wheel turns). As I recall Kevin Watson has a version for position as well as for velocity. Sometimes (e.g. in the industrial robot I worked on in the '80s) there are several layers - an “outer” layer, controlling Position, which results in a Desired Velocity to turn the motor to correct the Position, which then produces a Desired Acceleration, which then produces a desired Torque, which then produces a Desired Current. I think it reasonable to attempt the Position and Velocity layers in a FIRST robot, and you might think of the other parts as the job of the Victor speed controller.
Also fwiw, we are using the Globe motor as recommended earlier, and I find it to be way faster than necessary even though it has a gear reduction box. That might contribute to the difficulty we are having tuning, and I sometimes wish we were using one of the worm drive motors instead.
EDIT: I see on the vex forum, someone has posted something about PID in EasyC. I didn’t read it, but perhaps it is worth a look: http://www.vexforum.com/showthread.php?t=1510
As other have said, look into PID control. I’d personally recommend just trying P or PD control first and see if that gets you the desired results. Adding the I term to the system can introduce a lot of instabilities and problems if you’re not careful. If you feel you must have it, keep your I gain as low as possible and look into adding “Integral Anti-Windup” into your control equation. The I term tracks errors over time and if your system simply can’t meet your commanded value for some reason, then the I term can build up to a huge value, overflow your variable, etc. None of these things are good, so keep things simple at first and stick with P or PD control.
FYI, we downloaded Kevin Watson’s example PID last night and reworked it for our situation and it worked OK once we got some good tuning numbers in it. (it was easier to tune our Vex robot than our FRC robot. On the other hand, the FRC robot was a much more exciting process)
One thing that has always puzzled me is where he divides the integral of the error by the pid_time. This seems like it calculates the average error, not the accumulated error. We deleted that part and it worked better. YAMMV.
Also on the “anti windup” stuff - we basically don’t add the error to the error_i if the motor is already turning as fast as it can.
Not working 100%, but getting close.
David Fort
Team 1001
Hacksaw