Hello! I was wondering what is the most accurate turning and going forward and a robot during autonomous. This year I am looking for an accurate autonomous when turning and going forward. Right now all I know of is Drive for distance, Drive for revolution, Normal and, Gyro. Which is best? If you have another option feel free to help out and list it.
if you have no extra sensors like tracking wheels, then slowly (to minimize wheel slippage) driving forward for distance would probably give the highest accuracy. if you have tracking wheels, you can use them to get a more accurate representation of how far your robot has traveled.
1 Like
By normal, I assume you mean time based. Where you set the motor speed, then wait a set amount of time (delay), and then turn the motor off once that time passes. It’s good since it gets the job done and it does it without much need for programming knowledge. However it will start to become inconsistent if you go fast due to slippage and the lack of any correction. It works, but it won’t be efficient.
Drive for distance and drive for revolution are both types of control loops that are effectively the same thing to my knowledge. They both use encoders and PID. For most cases its a good way to get a consistent auto. You can also due slew rates and a few other tweaks to make it even more consistent. And now its pretty easy to use since V5 motors have a microprocessor and encoders built in for this very purpose. This is probably what most teams will use.
The gyro is only for turning, and it also has lots of drift late in the match. If you can handle the drift though (first 15 seconds should not be a problem), its the best for turning. Basically just due a PID with the gyro value. If you have one handy, I’d use it.
A new trend also emerging is to put encoders on unpowered wheels (motorless wheels) to help combat wheel slippage, but this is pretty extreme for most robots. The built in encoders work pretty well. Only really needed unless you are doing something like full odometry tracking or you got really fast chassis. If you have the extra parts, space on your chassis, and ports, I’d do it just for that extra accuracy, but its not a requirement for most bots.
1 Like
What is a slew rate and by other tweaks could you give examples?
slew rate makes it so that if u put ur joystick from 1-100, the code basically says “woah, ur accelerating too fast” and makes the robot start slower. Think abt it this way. normally (moving the joystick at a constant rate) the relatioship between position of joystick and speed is y=x. With slew rate it becomes y=2/3 x^2 or something similar.
Slew rate is the ramping up and down of voltage, in this case the voltage powering the motors. As @64540A said, it basically just limits the acceleration. This is useful for V4 so the motors don’t trip and shut off. And it also acts as an easy way to slow the robot down as it gets closer to its goal so it doesn’t overshoot if you aren’t using PID. It isn’t as much as a big deal with the built in PID for V5, but it is still good to know about. Tweaking the built in PID values or making your own control loop will let you have finer adjustments to how the robot interacts with the field too.
While for FRC and the code/control system is different, this is a pretty good talk on Motion Control.
1 Like
Here is a simple implementation of slew rate, which is simply the act of limiting the rate of change of a motor output:
/**
* limits the increment a variable can change
* @param input the input to this function, the output power from your code
* @param last the last output of this function
* @param slewRate the increment per loop that the output matches the input
* @return the slewed output power
*/
double slew (double input, double last, double slewRate) {
return std::clamp(input, last - slewRate, last + slewRate);
}
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.