Inaccurate Motion Profiling


#1

During the off-season my team has been working on motion profiling using the built in API in the TalonSRX. To generate the paths, we use this tool: https://github.com/vannaka/Motion_Profile_Generator. However, when we use the measured drive base width, the robot consistently under-turns.

I did some research online, and apparently the “effective drive base width” must be empirically determined. By guessing and checking, the robot consistently turned 90 degrees correctly with an effective drive base width of 40in, rather than the measured with of 29in.

While the turning works accurately, the robot’s final position wasn’t where it was supposed to be. Rather, the left side of the robot followed the left path. However, when the robot turned right, the right side of the robot followed the right path.

This means that for complicated turns, we have no way of determining where the robot ended up, since the center of the robot isn’t following the center of the path. I think this is caused by the incorrect drive base width, since the path generator believes that the robot is bigger than it actually is. This results in the robot inaccurately following the path.

What existing solutions are there for this problem? Why does the path generation algorithm require an incorrect drive base width?


#2

Can you explain what “under-turns” means in the context of how wide your drivetrain is?

“empirically determined” can be true sometimes, but usually this is to account for small inconsistancies, like carpet squish or wheel compression. that sort of delta between empirical & theoretical you mentioned seems far too big. With the drive base off by that much, I don’t expect the profiler to generate accurate left/right wheel commands. I’d set that drivebase width to 29 and look for other issues.

Have you generated plots of your SRX’s desired and actual speeds? How well do they match up? How much error is present between them for various scenarios? What type of PID are you using (velocity, position)? If velocity, are you using a non-zero feed-forward gain?

For turning, do you have a gyroscope to help keep you pointed in the right direction? Our team has found we pretty much need these to get motion profiling to work.


#3

One question for the OP: how well are the left and right sides of the drive tracking the trajectories you generated for them? The first step is figuring out whether the problem is poor tracking performance, or poor trajectories being generated.

Not at all, depending on the wheelbase. Our pneumatic 8WD in 2016 had an empirical wheelbase width almost double what we measured with a tape measure.

The contact dynamics of multi-wheeled skid-steer vehicles can be very complicated. Sometimes modeling the robot as a slip-free two-wheel differential drive that turns about its center is a good approximation (ex. a 6WD with corner omniwheels); sometimes not. Using an empirically measured wheelbase width is a good first step to correcting this model, as it corrects for the inherent slip experienced when turning in place.

However, this is still an over-simplification of the dynamics. In truth, the effective wheelbase width varies slightly with curvature and speed, and the instantaneous center of rotation may not even be along the virtual axle of the middle wheel (between the middle wheels for 4WD/8WD). There is a great deal of research that has been done in building models to characterize this. They are all quite complex. If you are interested in learning more, I suggest googling “modeling skid steer kinematics”.

What can we do about it? Three solutions are generally available:

  1. Build a different drivetrain :slight_smile: 254’s 6WD with corner omnis was selected in no small part due to the accuracy with which we can model its motion.

  2. Use other sensors for estimating robot pose. The most common manifestation of this in FRC would be using passive omni-wheels with encoders. This helps you know where the robot is (so combined with the right control system, you can correct for drift), but you still have the original problem of generating trajectories that get you to the right spot in the first place.

  3. Try to accurately model the kinematics/dynamics of your robot. This would involve surveying literature, selecting which models to apply, creating experiments to measure model parameters, etc. This is really impractical for FRC in my opinion.


#4

Our empirical wheelbase on an 8WD with two dropped center wheels was about 8" larger than the physical width. We recently just removed the center-back set of wheels and swapped out the four corner wheels with omnis to essentially turn our robot into a 6WD. This was to combat side-to-side rocking that we got with the 4 center Colson wheels due to scrubbing. Works great.
We also went away from regular motion profiling to motion profiling using a Pidgeon for heading, to make the wheelbase width not as sensitive.


#5

TIL, thanks! This is the first I googled that set of terms, and boy is there a wealth of information out there. I’ve always found more-accurate models of this kind of thing super interesting. Just for reference, from the first google link:

Huh. I’ve got some learning to do for sure :).

No one ever said “fun” had to be practical!


#6

The robot seems to be tracking the trajectories pretty decently. For a simple curve, these are the graphs for target position vs actual position: https://imgur.com/a/ZqMwOSw

We’re using the built-in motion profile implementation on the TalonSRX. That means that we’re using PIDF, with PID being applied to position and FF applied to velocity. However, the I gain is 0, since we found it pretty difficult to tune the I gain without the robot running out of control.

We don’t use a gyroscope to keep orientation. We haven’t figured out how to modify the trajectory points with the gyroscope data after we’ve pushed it to the talon’s point buffer. How has your team accomplished this?


#7

I don’t have the graphs on me right now, but the target position vs actual position graphs follow each other pretty accurately. I’ll post those when I get access to them. If both sides are following the position targets accurately, then the robot should follow the center line of the path, but that’s not what happens.

If we set the path to turn 90 degrees in a curve to the left using the measured drivetrain width, it doesn’t turn 90 degrees. It maybe turns 50 or 60 degrees. However, when we increase the drivetrain width to 40 instead of 29, it turns 90 degrees correctly. However, the robot doesn’t follow the center of the path. Instead, the left side of the robot follows the left side of the path. If we turn right, the right side of the robot follows the right side of the path.

We are using the built-in motion profiling implementation on the TalonSRX, so that means we are using PIDF. PID is being applied to position, and FF for velocity. However, our I term is 0, since we found that having an i term caused the system to go out of control.


#8

Or swerve!

Sorry, I did not mean to derail the discussion. Carry on.


#9

I’m going to paste my response from the reddit thread of the same content:

( https://www.reddit.com/r/FRC/comments/8ztby8/inaccurate_motion_profiling_programming/ )

Usually this relates to either improper tuning, mechanical issues, sensor issues or control loop issues.

To get the emperical width, write a simple auto to reset your encoder, make your robot spin in a circle 10 times (using your gyroscope as feedback), and take the distance travelled by each side of the drivetrain as reported by the encoders exactly when you reach 10 rotations. Average the readings and use the formula C = 2PIr (in your case, r = C/(20*PI) ) to get the trackwidth ‘r’.

Next, diagnose your encoders. They might be misreporting values. Do some manual testing of this and make sure you’re getting consistent readings by just propping up your robot so it doesn’t touch the ground and turning the wheels manually.

Next, make sure your control loop is running as expected. Your loop should be running at the same speed as what you specified when generating the path. Make sure you’re running it in a timed loop (i.e. a Notifier, TimedRobot or some other solution).

Finally, sit down and tune your PDVA values. It’ll take some time, but it’s worth it. V should be the reciprocal of your maximum velocity, and A is dependent on your drivetrain (I’ve found ~ 3 (or 0.25 if you’re working in motor controller units) to work pretty well for the stock drivetrain). Tune P next, and leave D for last. I has no effect. If you’re inclined to tune V and A on empircal values, Oblarg (Eli) has a very good paper on chief delphi about how to do this, but it is quite a time and study investment.

If all else fails, make sure your robot is mechanically sound (close to 0 slop)