If your goal is to win matches... Pick the most capable candidate. If your goal is to change lives... Sometimes you pick those that need the most change. - IKE [more]
 Chief Delphi Inaccurate Motion Profiling
 portal register members calendar search Today's Posts Mark Forums Read FAQ rules

#1
07-18-2018, 03:12 AM
 coolioasjulio Registered User FRC #0492 (Titan Robotics) Team Role: Programmer Join Date: Apr 2018 Rookie Year: 2017 Location: Bellevue Posts: 3
Inaccurate Motion Profiling

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
07-18-2018, 07:33 AM
 gerthworm Making the 1's and 0's FRC #1736 (Robot Casserole) Team Role: Mentor Join Date: Jan 2015 Rookie Year: 2015 Location: Peoria, IL Posts: 744
Re: Inaccurate Motion Profiling

Quote:
 Originally Posted by coolioasjulio However, when we use the measured drive base width, the robot consistently under-turns.
Can you explain what "under-turns" means in the context of how wide your drivetrain is?

Quote:
 Originally Posted by coolioasjulio 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.
"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
07-18-2018, 11:04 AM
 Jared Russell 4933T15 FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy) Team Role: Engineer Join Date: Nov 2002 Rookie Year: 2001 Location: San Francisco, CA Posts: 3,565
Re: Inaccurate Motion Profiling

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.

Quote:
 Originally Posted by gerthworm that sort of delta between empirical & theoretical you mentioned seems far too big.
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 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
07-18-2018, 12:19 PM
 asid61 Design Simple AKA: Anand Rajamani FRC #1072 (Harker Robotics) Team Role: Mentor Join Date: Jan 2014 Rookie Year: 2013 Location: Cupertino, CA Posts: 3,127
Re: Inaccurate Motion Profiling

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.
__________________
Team 1072 2017-present
Team 299 2017
Team 115 2013-2016 (student)

2018 Davis Finalists (w/ 6474 and 3880), 2018 Roebling Winners (w/ 3476, 1323, and 1778)

#5
07-18-2018, 12:42 PM
 gerthworm Making the 1's and 0's FRC #1736 (Robot Casserole) Team Role: Mentor Join Date: Jan 2015 Rookie Year: 2015 Location: Peoria, IL Posts: 744
Re: Inaccurate Motion Profiling

Quote:
 Originally Posted by Jared Russell Not at all, depending on the wheelbase.
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!

Last edited by gerthworm : 07-18-2018 at 12:45 PM.
#6
07-18-2018, 03:41 PM
 coolioasjulio Registered User FRC #0492 (Titan Robotics) Team Role: Programmer Join Date: Apr 2018 Rookie Year: 2017 Location: Bellevue Posts: 3
Re: Inaccurate Motion Profiling

Quote:
 Originally Posted by Jared Russell 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.
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

Quote:
 Originally Posted by gerthworm 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?
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.

Quote:
 Originally Posted by gerthworm 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.
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
07-19-2018, 12:33 AM
 coolioasjulio Registered User FRC #0492 (Titan Robotics) Team Role: Programmer Join Date: Apr 2018 Rookie Year: 2017 Location: Bellevue Posts: 3
Re: Inaccurate Motion Profiling

Quote:
 Originally Posted by Jared Russell 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.
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.

Quote:
 Originally Posted by gerthworm Can you explain what "under-turns" means in the context of how wide your drivetrain is?
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.

Quote:
 Originally Posted by gerthworm 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.
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
07-20-2018, 08:36 PM
 wgorgen Registered User FRC #1533 (Triple Strange) Team Role: Mentor Join Date: Apr 2018 Rookie Year: 2014 Location: Greensboro, NC, USA Posts: 149
Re: Inaccurate Motion Profiling

Quote:
 Originally Posted by Jared Russell 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 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.
Or swerve!

Sorry, I did not mean to derail the discussion. Carry on.
__________________
#9
07-20-2018, 08:53 PM
 Jaci http://imjac.in/ta/name AKA: Jaci R Brunning FRC #5333 (Can't C#) #5663 (Ground Control) | (OpenRIO, FRC West Aus) Team Role: Mentor Join Date: Jan 2015 Rookie Year: 2015 Location: Perth, Western Australia Posts: 633
Re: Inaccurate Motion Profiling

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

( https://www.reddit.com/r/FRC/comment...g_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)
__________________

Curtin FRC (5333+5663) : Head Mentor
WPILib : Developer

Website | Github
jaci.brunning@gmail.com

 Thread Tools Display Modes Rate This Thread Linear Mode Rate This Thread: 5 : Excellent 4 : Good 3 : Average 2 : Bad 1 : Terrible

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are On [IMG] code is On HTML code is Off
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Announcements     User Announcements FIRST     General Forum     Rumor Mill     Career     Robot Showcase Technical     Technical Discussion     Robotics Education and Curriculum     Motors     Electrical         CAN     Programming         NI LabVIEW         C/C++         Java         Python     Sensors     Control System     Pneumatics     Kit & Additional Hardware     CAD         Inventor         SolidWorks         Creo     IT / Communications         3D Animation and Competition         Website Design/Showcase         Videography and Photography         Computer Graphics Competition     Awards         Chairman's Award     Rules/Strategy         Scouting     Team Organization         Fundraising         Starting New Teams         Finding A Team         College Teams     Championship Event     Regional Competitions     District Events     Off-Season Events     Thanks and/or Congrats     FRC Game Design     OCCRA         OCCRA Q&A Other     Chit-Chat         Games/Trivia         Fantasy FIRST     Car Nack's Corner     College & University Education     Dean Kamen's Inventions     FIRST-related Organizations         The Blue Alliance     FIRST In the News...     FIRST Lego League     FIRST Tech Challenge     VEX     Televised Robotics     Math and Science     Robot in 3 Days (RI3D)     NASA Discussion ChiefDelphi.com Website     CD Forum Support     Extra Discussion

All times are GMT -5. The time now is 10:09 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.

 -- English (12 hour) -- English (24 hour) Contact Us - Chief Delphi - Rules - Archive - Top