OCCRA
Go to Post math and physics save a lot of money!!! Pay attention in school - this is why your teachers are torturing you with this stuff. - Chris Hibner [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 07-18-2018, 02:12 AM
coolioasjulio coolioasjulio is offline
Registered User
FRC #0492 (Titan Robotics)
Team Role: Programmer
 
Join Date: Apr 2018
Rookie Year: 2017
Location: Bellevue
Posts: 3
coolioasjulio is an unknown quantity at this point
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?
Reply With Quote
  #2   Spotlight this post!  
Unread 07-18-2018, 06:33 AM
gerthworm's Avatar
gerthworm gerthworm is offline
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: 665
gerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond repute
Re: Inaccurate Motion Profiling

Quote:
Originally Posted by coolioasjulio View Post
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 View Post
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.
Reply With Quote
  #3   Spotlight this post!  
Unread 07-18-2018, 10:04 AM
Jared Russell's Avatar
Jared Russell Jared Russell is offline
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,550
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
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 View Post
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.
Reply With Quote
  #4   Spotlight this post!  
Unread 07-18-2018, 11:19 AM
asid61's Avatar
asid61 asid61 is online now
Design Simple
AKA: Anand Rajamani
FRC #1072 (Harker Robotics)
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Cupertino, CA
Posts: 3,056
asid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond reputeasid61 has a reputation beyond repute
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)

Reply With Quote
  #5   Spotlight this post!  
Unread 07-18-2018, 11:42 AM
gerthworm's Avatar
gerthworm gerthworm is offline
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: 665
gerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond reputegerthworm has a reputation beyond repute
Re: Inaccurate Motion Profiling

Quote:
Originally Posted by Jared Russell View Post


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 11:45 AM.
Reply With Quote
  #6   Spotlight this post!  
Unread 07-18-2018, 02:41 PM
coolioasjulio coolioasjulio is offline
Registered User
FRC #0492 (Titan Robotics)
Team Role: Programmer
 
Join Date: Apr 2018
Rookie Year: 2017
Location: Bellevue
Posts: 3
coolioasjulio is an unknown quantity at this point
Re: Inaccurate Motion Profiling

Quote:
Originally Posted by Jared Russell View Post
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 View Post
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 View Post
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?
Reply With Quote
  #7   Spotlight this post!  
Unread 07-18-2018, 11:33 PM
coolioasjulio coolioasjulio is offline
Registered User
FRC #0492 (Titan Robotics)
Team Role: Programmer
 
Join Date: Apr 2018
Rookie Year: 2017
Location: Bellevue
Posts: 3
coolioasjulio is an unknown quantity at this point
Re: Inaccurate Motion Profiling

Quote:
Originally Posted by Jared Russell View Post
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 View Post
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 View Post
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.
Reply With Quote
  #8   Spotlight this post!  
Unread 07-20-2018, 07:36 PM
wgorgen's Avatar
wgorgen wgorgen is offline
Registered User
FRC #1533 (Triple Strange)
Team Role: Mentor
 
Join Date: Apr 2018
Rookie Year: 2014
Location: Greensboro, NC, USA
Posts: 134
wgorgen is a splendid one to beholdwgorgen is a splendid one to beholdwgorgen is a splendid one to beholdwgorgen is a splendid one to beholdwgorgen is a splendid one to beholdwgorgen is a splendid one to beholdwgorgen is a splendid one to behold
Re: Inaccurate Motion Profiling

Quote:
Originally Posted by Jared Russell View Post
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.
__________________
Reply With Quote
  #9   Spotlight this post!  
Unread 07-20-2018, 07:53 PM
Jaci's Avatar
Jaci Jaci is offline
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: 616
Jaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond reputeJaci has a reputation beyond repute
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
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

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


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

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


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi