Quote:
Originally Posted by SamcFuchs
Ok, I can see how that would be effective...how does it compare to using encoders for correction?
|
I think this question mostly stems from a misunderstanding.
The Motion Profiling you're describing, like most motion profiling, is based upon distance, velocity and acceleration. Something to note is that these all function in a single dimension. For devices like actuation arms or conveyors, this makes sense, as there is only one direction of motion. (there can still be issues here in tracking, but that is not related to a difference in distances)
If you want to start using this in a 2D sense (i.e. a drive base), these distances can be misread. For example, if a wheel (or track) on one side of your drive base slips (assuming 'tank' drive), it will mistakenly read a distance, even though it hadn't moved that far. To the code, your drive base is tracking properly, but in the real world it isn't. This is a common problem with drive bases. The most common way to fix this is to add an extra proportional gain based on the error between what you want your heading to be, and what your heading is reported to be by the gyroscope (per Austin's example). Let's say you have the following code:
Code:
float left_power = calc_power_left(time, profile_l, encoder_l);
float right_power = calc_power_right(time, profile_r, encoder_r);
The profile will have already generated the desired distance for each side of the drive base (the arc length along the curve of motion for each side), so in a perfect world, this would track just fine. However, we don't live in a perfect world, so we add something like the following:
Code:
float gyro_heading = ... your gyro code ...
float desired_heading = get_heading(time, profile);
float delta_angle = desired_heading - gyro_heading; // This is our error in alignment
float turn_power = 0.8 * (-1/80) * delta_angle; // Change these coefficients as required
setLeftMotors(left_power + turn_power);
setRightMotors(right_power - turn_power);
In the above example, get_heading returns the heading of the path at the given time (i.e. the 'tangent' if you were to plot the curve). This accounts for errors in the heading by 'nudging' the robot in the right direction.
The main point I'm trying to clear up here is that it isn't entirely possible to use encoders for correction, as they rely on continuous, perfect connection to the field floor. Adding in a gyroscope will account for any errors in heading that the encoders, wheels or field introduce.
I hope this clears up any misconceptions you have.