Our teams autonomous has an issue in which the IEM seems to glitch out. For example, if our robot is running forward for a set distance according to the IEM, the robot will instead move forward for less than half a second, and then skip the following 5-6 lines of code. Note, the next few lines of code DO include more functions including the IEM. However, it also skips lines of code that do not involve the IEM whatsoever. Also this only occurs probably everyone 1/10 times we run the auton. Every other time it seems to work fine. What might the issue be?
Here is our function:
void autoDriveDist(int speed, float dist) {
nMotorEncoder[ChassisL] = 0;
nMotorEncoder[ChassisR] = 0;
float ticks = dist/(4*PI) * 392;
while (abs(nMotorEncoder[ChassisLLL]) < ticks * .6 && abs(nMotorEncoder[ChassisRRR]) < ticks * .6) {
autoDrive(speed);
}
while (abs(nMotorEncoder[ChassisLLL]) < ticks && abs(nMotorEncoder[ChassisRRR]) < ticks) {
autoDrive(speed/2);
}
autoDriveTime(-speed/2, 50);
}
By IEM I assume you mean IME (integrated motor encoder). If that is the case, just don’t use IMEs. They are simply bad. Static on the field makes them all but unusable.
Your code looks fine, but I could have missed something. At any rate, I would switch to PID. The debugger output would probably also be useful in diagnosing the problem.
We’re not that very familiar with PID control. Do you know how to use a PID control with an IME or a guide that describes PID control with IME sensors? @Aeden_6007
First, Check this out: A PID controller in RobotC - General Forum - VEX Forum
@Aeden_6007 is right, you need a control loop of some sort. While interval speed settings based on proximity (what you are currently doing) may work:
A) You need more speed settings than just full power and 1/2 power for any real accuracy
B) Its a total pain to set a dozen settings, and accomplishes the same thing as a pure proportional control but instead it adds a dozen of extra lines
If you aren’t comfortable programming a full PID based on that guide, I’d recommend doing a proportional (P) control with min speed. Proportional control is really simple: the farther from the target, the more power you apply. The closer you are, apply less power so you slow down.
Simple example code is the following (for just one side):
const int threshold = 1; //Add a ticks threshold just in case you slightly over/under shoot target
const float kP = 0.8; //A constant that can be determined through trial/error tuning and reading motor vals
void autoDriveDist(int speed, float dist) {
nMotorEncoder[ChassisL] = 0;
float ticks = dist/(4*PI) * 392;
int speed = 0;
while (abs(ticks - abs(nMotorEncoder[ChassisLLL])) > threshold ) { //check to see you are not at target
int error = (ticks - abs(nMotorEncoder[ChassisLLL]));
speed = error * kP;
autoDrive(speed);
}
}
It is important to add the min speed however because at some point you will be very close to the target, and the generated motor values will not be able to move your robot due to friction and gravity. The min speed will allow your robot to move to the final position but stop almost immediately. You can figure this out through some simple tests. Eventually, the integral (I) gain will solve this problem but you can worry about that later after you’re P + min speed works.
Wow! Thanks so much @Ashwin Gupta!!! I have two questions though. One is how do I find kP? I understand you have to read the debugger menu and do some trial and error but I don’t really understand what we’re trying to look for. Two is I recently found this video http://www.education.rec.ri.cmu.edu/products/cortex_video_trainer/lesson/3-6IntegratedEncoders4.html which describes using the IME with a PID control loop. In the video, it uses the function moveMotorTarget which seems to be just a function with a PID already integrated in it. Do you know if this function can act as a PID loop or does it not work for our purposes?
- kP is pretty much whatever it needs to be to have realistic and steady output values at some reasonable distance being your benchmark. For instance, if you are having your robot move, eh, lets say 24 inches (a tile), you probably want speeds like:
127, 110, 100, 90, 50, 30 , 20 (min speed)
if you set up you’re kP to achieve those values at that distance (or similar) then for 12 inches it will have speeds like:
90, 50, 30, 20, (min speed)
and at 48 inches:
127, 127, 127, 127, 127, 127, 127, 110, 100, 90, 50, 30 , 20 (min speed)
Which are pretty good because it will be slow at short distances and go full speed at longer ones. Note, that it will technically calculate values above 127 some time but these will be handled like 127 the motors. Does that make sense? If not lmk I can clarify further.
- No idea, I’ll look at that tmrw and get back to u
oh and PS use Quad encoders for your own sanity. IMEs are terrible circuit design and will cause you all sorts of trouble with static reset design flaw.