encoders

[benjamin1748]

I was working on a program using the encoders to get my robot to drive straight. I ran into a problem. When I tried to get my wheels to drive at the same speed they would slow down, speed up, and would repeat this until they stopped. If looked as if the wheels were playing catch up. Does anyone know a solution or have any helpful advice on how I should go about this problem?

[TubaMorg]

It sounds as if you have implemented a simple PID control, or at least the proportional part of PID. If you are unfamiliar with this just search for it here on ChiefDelphi. Believe it or not, you aren't too far away from making your drive behave properly. I am guessing you are finding the error between the speed you want and the speed the encoders are showing and applying that error to your motors to make the correction. The problem is you keep overshooting the mark, this is a common problem in all mechanical control systems. You just need to scale down your error so that the response is slower and doesn't overshoot:

correction = error*.4 (for example)

In a true PID control you would scale it down to just enough to prevent oscillation, however this often results in the error never going to 0. That's when you can try adding in the "I" and the "D" part of the control. I will let you find out more about that after you search for "PID"

[BradAMiller]

Originally Posted by benjamin1748

I was working on a program using the encoders to get my robot to drive straight. I ran into a problem. When I tried to get my wheels to drive at the same speed they would slow down, speed up, and would repeat this until they stopped. If looked as if the wheels were playing catch up. Does anyone know a solution or have any helpful advice on how I should go about this problem?

If the problem isn't related to PID stuff - another easy way to use encoders to drive straight is using this algorithm:

error = GetEncoder(LEFT_ENCODER) - GetEncoder(RIGHT_ENCODER);
Drive(speed, error);

The Drive function (either from the easyC samples or built in to WPILib) takes a speed and direction. When you are driving straight, the wheel counts will be the same on the two wheels. If the count is different, you need to speed up either the right or left wheel. The amount of the correction is proportional to the amount of error.

A few implementation details:
1. You should make sure that the sign of error matches your robot.
2. You should probably limit error so the robot doesn't make wild turns.
3. You might want to stick this into a function, like DriveStraight where the encoder counts are reset at the beginning of the straight driving segment.
4. The drive function simply sends speed+direction to one wheel and speed-direction to the other wheel, so make sure that they don't exceed +/-127 since that's all the range that speed controls have.

[Jon236]

To Brad & Adam,

Kevin Watson's code apparently handles 8 interrupts......how many does EasyCPro handle? We are using 3 ultrasonic sensors and 4 encoders!

Jon Mittelman

[Kingofl337]

John,

The controller only has 6 interrupt ports and easyC handles all 6 of them. You are going to need to loose a sensor or use a VEX co-processor. Why are you using 4 encoders do you have a mechanum(sp?) drive system?

[Greg Marra]

Originally Posted by Kingofl337

The controller only has 6 interrupt ports and easyC handles all 6 of them. You are going to need to loose a sensor or use a VEX co-processor. Why are you using 4 encoders do you have a mechanum(sp?) drive system?

Would it even be possible to use a VEX coprocessor (or any coprocessor for that matter) with EasyC? That sounds far beyond the scope of what EasyC can handle.

[Kingofl337]

No, it would not be beyond the scope of easyC. You could connect the two serial ports together and and pass data all day long. We even have a feature to select the baudrate for devices that use a slower serial speed.

If you start calling some of the Microchip libraries you can touch and piece of the hardware you can touch in MPLAB.