OCCRA
Go to Post EVERYONE on the team is offered the same opportunities to be a team player, it is up to each person to step up and play the game. - MariaCastro [more]
Home
Go Back   Chief Delphi > Technical > Technical Discussion
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 09-05-2017, 07:27 PM
xForceDee's Avatar
xForceDee xForceDee is offline
Registered User
AKA: Bart Kerfeld
FRC #4239 (Warpspeed)
Team Role: College Student
 
Join Date: Dec 2012
Rookie Year: 2012
Location: Minnesota
Posts: 75
xForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to behold
What is the Point of the Acceleration Feed-Forward?

So I have been looking into basic motion profiling. I have watched this video a couple times an am a bit confused by the slide at 39:46.

It claims to be "Better" feedforward control because it also factors in acceleration.

Code:
SetMotorSpeed(Kv * setpoint.vel + Ka * setpoint.acc)
The first term (Kv * setpoint.vel) makes a lot of sense. Set the motor to run at your desired velocity based on your current time following the profile. I'm on board here.

My question is what does the acceleration term actually do? To me, it seems like it just throws things off.

Consider a trapezoidal profile. We have 3 states: accelerating, cruising and decelerating. During acceleration, Ka * setpoint.acc would increase motor speed to be higher than the desired velocity. During cruising, it would not contribute. During deceleration, it would decrease motor speed to be lower than the desired velocity. Doesn't this just mess things up?

Last edited by xForceDee : 09-06-2017 at 05:44 PM.
Reply With Quote
  #2   Spotlight this post!  
Unread 09-05-2017, 07:29 PM
dardeshna's Avatar
dardeshna dardeshna is offline
Team Captain
AKA: Devin Ardeshna
FRC #0008 (Paly Robotics | Team 8)
Team Role: Mechanical
 
Join Date: Dec 2015
Rookie Year: 2015
Location: Palo Alto
Posts: 105
dardeshna is a name known to alldardeshna is a name known to alldardeshna is a name known to alldardeshna is a name known to alldardeshna is a name known to alldardeshna is a name known to all
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by xForceDee View Post
So I have been looking into basic motion profiling. I have watched this video a couple times an am a bit confused by the slide at 39:46.

It claims to be "Better" feedforward control because it also factors in acceleration.

Code:
SetMotorSpeed(Kv * setpoint.vel + Ka * setpot.acc)
The first term (Kv * setpoint.vel) makes a lot of sense. Set the motor to run at your desired velocity based on your current time following the profile. I'm on board here.

My question is what does the acceleration term actually do? It seems like acceleration comes into play from setpoint.vel changing with time.

Consider a trapezoidal profile. We have 3 states: accelerating, cruising and decelerating. During acceleration, Ka * setpoint.acc would increase motor speed to be higher than the desired velocity. During cruising, it would not contribute. During deceleration, it would decrease motor speed to be lower than the desired velocity. Doesn't this just mess things up?
My understanding is that is it is extra "oomph" to make the robot more responsive when accelerating and to counter inertia when decelerating quickly.

Takes the load off of the PID loop a little bit, as the error when accelerating is almost always lag, and the error when decelerating is almost always due to inertia.
__________________
Devin Ardeshna
Team Captain (Paly Robotics FRC #8)


2017 Ventura Regional Quarterfinalist, Entrepreneurship Award, and Creativity Award, Silicon Valley Regional Finalist, Entrepreneurship Award, and Wildcard, Roebling Division Semifinalist
2016 Central Valley Regional Finalist and Wildcard, Silicon Valley Regional Quarterfinalist, Curie Division, CalGames Quarterfinalist and Entrepreneurship Award, Capital City Classic Quarterfinalist
2015 Central Valley Regional Entrepreneurship Award, Silicon Valley Regional Entrepreneurship Award, Capital City Classic Semifinalist and Judges' Award
Reply With Quote
  #3   Spotlight this post!  
Unread 09-05-2017, 07:35 PM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,500
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by xForceDee View Post
So I have been looking into basic motion profiling. I have watched this video a couple times an am a bit confused by the slide at 39:46.

It claims to be "Better" feedforward control because it also factors in acceleration.

Code:
SetMotorSpeed(Kv * setpoint.vel + Ka * setpot.acc)
The first term (Kv * setpoint.vel) makes a lot of sense. Set the motor to run at your desired velocity based on your current time following the profile. I'm on board here.

My question is what does the acceleration term actually do? To me, it seems like it just throws things off.

Consider a trapezoidal profile. We have 3 states: accelerating, cruising and decelerating. During acceleration, Ka * setpoint.acc would increase motor speed to be higher than the desired velocity. During cruising, it would not contribute. During deceleration, it would decrease motor speed to be lower than the desired velocity. Doesn't this just mess things up?
The point of any feedforward is to make a better "guess" at the actual control signal required to make your motor do what you want it to.

Without getting into the nitty-gritty control theory, basically: because the robot has inertia, accelerating takes more voltage than running at a constant speed. The acceleration feedforward term attempts to account for this, so that your feedback loop doesn't have to.

Edit: I apologize for having to re-write this entire section, but apparently my brain does not function after 10PM (which is when I originally added it) - hopefully no one was mislead for the couple hours during which it was wrong.

To gain some intuition for why this works, consider the way a brushed DC motor works: torque (which causes acceleration) is proportional to current. Current, as you might remember, is proportional to voltage (V=IR). Now the voltage across a DC motor can be broken into two parts: voltage due to internal resistance of the motor, and voltage due to "back-EMF." The former is, as noted, proportional to the current across the motor. The latter is proportional to the velocity of the motor. The applied voltage must equal the sum of the two. If we imagine that we have a frictionless motor, the torque required to maintain any speed is zero, and thus the voltage required to simply go at a given velocity is proportional to that velocity - we merely need to apply voltage equal to the back-EMF, which is proportional to velocity (in actuality, motors are obviously not frictionless, which is why the current draw at free speed is not zero). This is accounted for by our velocity feedforward. However, if we want the motor to accelerate, then we need to add some amount of voltage on top of that which compensates for the back-EMF, such that this additional voltage, when divided by the internal resistance of the motor (V/R = I), yields the correct current to generate the torque we need. This is what the acceleration feedforward estimates.
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016

Last edited by Oblarg : 09-05-2017 at 10:50 PM.
Reply With Quote
  #4   Spotlight this post!  
Unread 09-05-2017, 10:32 PM
GeeTwo's Avatar
GeeTwo GeeTwo is offline
Technical Director
AKA: Gus Michel II
FRC #3946 (Tiger Robotics)
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 4,550
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

This is really programming to the motor performance curve. Once the motor is spinning, it functions as a generator, creating an emf (voltage) which (in normal operation) is in the opposite direction of the applied voltage. The remaining voltage generates torque, which is used to counter friction and accelerate. I have gotten fair performance out of using this form of feed forward with no feedback with some non-competition systems in experimentation.

This isn't exactly how it is used here because it seems that the feed forward is using desired (setpoint) speed rather than measured speed, but the effects should be roughly the same.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.
Reply With Quote
  #5   Spotlight this post!  
Unread 09-06-2017, 10:22 AM
xForceDee's Avatar
xForceDee xForceDee is offline
Registered User
AKA: Bart Kerfeld
FRC #4239 (Warpspeed)
Team Role: College Student
 
Join Date: Dec 2012
Rookie Year: 2012
Location: Minnesota
Posts: 75
xForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to behold
Re: What is the Point of the Acceleration Feed-Forward?

Thanks for the responses everyone. Learned a bit about how brushed DC motors work from this which has been fun.

Now that I understand the motive for the acceleration term. I am curious to know good ways to go about finding Ka.

Kv = 1 / max_velocity
(where max_velocity is measured by running at your robot at max voltage until it stops accelerating makes sense to me)

This might lead one to suspect
Ka = 1 / max_acceleration

But the issue, as you pointed out, is that max_acceleration varies with the speed of the robot. That is to say, I can accelerate much faster at rest than I can when I am running a 90% velocity. How can I determine the max_acceleration for any given velocity? Perhaps I could run the robot at max voltage and track the velocity and acceleration at all points in time and the create a map from velocity to acceleration. Assuming no slippage (big assumption) this should give me the max_acceleration for any velocity. But then there is the whole deceleration thing. I can probably decelerate faster than I can accelerate. How can I track that? My head hurts. Can anyone shed some light on this?

I could also ignore the fact that max_acceleration changes with velocity and just pick the max_acceleration at rest (the maximum max_acceleration ) causing the acceleration term to under compensate. Then, the feedback controller would just pick up the slack. Have people found an approach like this to be sufficient for their FRC needs?

Last edited by xForceDee : 09-06-2017 at 10:25 AM.
Reply With Quote
  #6   Spotlight this post!  
Unread 09-06-2017, 10:44 AM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,500
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by xForceDee View Post
Thanks for the responses everyone. Learned a bit about how brushed DC motors work from this which has been fun.

Now that I understand the motive for the acceleration term. I am curious to know good ways to go about finding Ka.

Kv = 1 / max_velocity
(where max_velocity is measured by running at your robot at max voltage until it stops accelerating makes sense to me)

This might lead one to suspect
Ka = 1 / max_acceleration
This would be correct, if "max acceleration" corresponded to "the acceleration of the motor at rest when full voltage is applied," or, in simpler terms, the acceleration corresponding to the stall torque.

The reason you lose the ability to accelerate at higher speeds is that the back-EMF from the motor (i.e., the thing accounted for by your velocity feedforward) "saps" your available voltage. That is, if your motor is already spinning at half of max speed, then half of your available battery voltage is already being used to counteract the resulting back-EMF, and you only have the remaining half available to provide torque (and accelerate the robot) - thus, your available torque at 50% of free speed is 50% of stall torque. If you're running at max speed, well, you can't accelerate at all (at least in the direction of motion) because applying full battery voltage merely cancels the back-EMF.

But the "torque per voltage" never changes (the original wording of my post was unclear/wrong about this, which is why I had to modify it a whole bunch of times - late night posting ftl). That is determined by the internal resistance of the motor. So, increasing applied voltage by a fixed amount will always increase the torque by a corresponding amount.

On a related note, I really wish that the Talon SRXs would allow for acceleration feedforward in motion profiling mode.
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016
Reply With Quote
  #7   Spotlight this post!  
Unread 09-06-2017, 11:00 AM
xForceDee's Avatar
xForceDee xForceDee is offline
Registered User
AKA: Bart Kerfeld
FRC #4239 (Warpspeed)
Team Role: College Student
 
Join Date: Dec 2012
Rookie Year: 2012
Location: Minnesota
Posts: 75
xForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to behold
Re: What is the Point of the Acceleration Feed-Forward?

Because torque and my robots acceleration are proportional (correct me if I am wrong on this, but that makes sense to me), could I then use what your saying to calculate max_acceleration as a function of current_velocity as follows:

max_acceleration(current_velocity) = from_rest_max_acceleration * (current_velocity / max_velocity)

where from_rest_max_acceleration is the acceleration my robot has running at full voltage from rest. Again, assuming no slippage.

Last edited by xForceDee : 09-06-2017 at 11:05 AM.
Reply With Quote
  #8   Spotlight this post!  
Unread 09-06-2017, 11:07 AM
brian5115's Avatar
brian5115 brian5115 is offline
Registered User
FRC #5115 (Knight Riders)
Team Role: Leadership
 
Join Date: Sep 2016
Rookie Year: 2015
Location: Maryland
Posts: 28
brian5115 is an unknown quantity at this point
Re: What is the Point of the Acceleration Feed-Forward?

I have a followup question. How do you determine/tune Ka?
__________________


2016:
District Event Winner - Northern Maryland
Excellence in Engineering - Northern Maryland

2017:
District Event Winner - Central Maryland
Reply With Quote
  #9   Spotlight this post!  
Unread 09-06-2017, 11:09 AM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,500
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by xForceDee View Post
Because torque and my robots acceleration are proportional (correct me if I am wrong on this, but that makes sense to me), could I then use what your saying to calculate max_acceleration as a function of current_velocity as follows:

max_acceleration(current_velocity) = stall_torque_acceleration * (current_velocity / max_velocity)

where stall_torque_acceleration is the acceleration my robot has running at full voltage at rest. Again, assuming no slippage.
This is a correct calculation of "max acceleration" (at least in the direction of current motion), but as it happens you do not need to bother with it for figuring out the scaling of Ka, which depends only on the stall torque acceleration.

Remember the form of our feedforward:

Kv * setpoint.vel + Ka*setpoint.acc

If the motor is behaving as we expect it to (and we neglect frictional losses), the first term (Kv * setpoint.vel) will output the voltage required to counteract the back-EMF. The second term (Ka * setpoint.acc), we want to output the voltage required to yield a torque that will cause the robot to accelerate at setpoint.acc. Regardless of the speed we're moving, the voltage required to produce a given torque is the same, even though the "max torque" (or "max acceleration") is different, because the difference in "max torque" is only due to the decrease in the available battery voltage after taking into account the back-EMF.

So, regardless of the speed we're currently traveling, if we want to accelerate at 50% of max acceleration, we would need to add an additional 50% of the maximum battery voltage to our current output. The scaling of Ka is the same. Of course, if we're traveling over 50% of max speed, then this is not actually possible, because that would be greater than our "max acceleration" (as you have calculated it) at that speed - this is because we'd have less than 50% of max battery voltage available after subtracting off the back-EMF, however, not because a given increase in voltage would cause a smaller acceleration.
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016
Reply With Quote
  #10   Spotlight this post!  
Unread 09-06-2017, 11:30 AM
xForceDee's Avatar
xForceDee xForceDee is offline
Registered User
AKA: Bart Kerfeld
FRC #4239 (Warpspeed)
Team Role: College Student
 
Join Date: Dec 2012
Rookie Year: 2012
Location: Minnesota
Posts: 75
xForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to beholdxForceDee is a splendid one to behold
Re: What is the Point of the Acceleration Feed-Forward?

So if we want to follow a simple Trapezoidal Motion Profile, one where we accelerate at a constant rate, cruise, then decelerate at a constant rate, it is important to do the math to choose an <acceleration, cruise_velocity> pair that is physically achievable.

This check should be as simple as compute the max_acceleration(cruise_velocity) from the function I posted above (all other velocities in the profile are less than the cruise_velocity so this should result in the lowest max_acceleration). Compare this to the acceleration chosen in the profile. If the profile's acceleration is less than max_acceleration(cruise_velocity), then we should be able to follow the profile correctly. If not, we won't have enough voltage to continue accelerating at the same rate. Does that make sense?

Last edited by xForceDee : 09-06-2017 at 11:32 AM.
Reply With Quote
  #11   Spotlight this post!  
Unread 09-06-2017, 12:46 PM
D.Allred's Avatar
D.Allred D.Allred is offline
Registered User
FRC #4451 (Rat Rod Robotics)
Team Role: Mentor
 
Join Date: Jun 2009
Rookie Year: 2009
Location: Greenville, SC
Posts: 257
D.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond reputeD.Allred has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by xForceDee View Post
So if we want to follow a simple Trapezoidal Motion Profile, one where we accelerate at a constant rate, cruise, then decelerate at a constant rate, it is important to do the math to choose an <acceleration, cruise_velocity> pair that is physically achievable.

This check should be as simple as compute the max_acceleration(cruise_velocity) from the function I posted above (all other velocities in the profile are less than the cruise_velocity so this should result in the lowest max_acceleration). Compare this to the acceleration chosen in the profile. If the profile's acceleration is less than max_acceleration(cruise_velocity), then we should be able to follow the profile correctly. If not, we won't have enough voltage to continue accelerating at the same rate. Does that make sense?
Yes. But I usually run another check of approximate Kv and Ka gains before tuning profile with the robot. Kv * desired velocity + Ka * constant acceleration rate should be less than full throttle. You need room for Kd * distance error to work when the feedback loop is added.

Using Kv of 1/max velocity is a good place to start. So if you are trying to cruise at 70% of max velocity, then the output to the motor during the cruise section of the curve will be 0.7. You only have 0.3 throttle to add the acceleration component plus any error correction for distance.

Bottom line, your cruise velocity picked will set the ceiling on your other terms. Make sure you understand your real robot characteristics instead of basing cruise and acceleration on theoretical calculations.

Good luck with your experiments!

David
Reply With Quote
  #12   Spotlight this post!  
Unread 09-06-2017, 01:14 PM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,500
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by xForceDee View Post
So if we want to follow a simple Trapezoidal Motion Profile, one where we accelerate at a constant rate, cruise, then decelerate at a constant rate, it is important to do the math to choose an <acceleration, cruise_velocity> pair that is physically achievable.

This check should be as simple as compute the max_acceleration(cruise_velocity) from the function I posted above (all other velocities in the profile are less than the cruise_velocity so this should result in the lowest max_acceleration). Compare this to the acceleration chosen in the profile. If the profile's acceleration is less than max_acceleration(cruise_velocity), then we should be able to follow the profile correctly. If not, we won't have enough voltage to continue accelerating at the same rate. Does that make sense?
As noted by the poster above, this is correct. Note, however, that "max acceleration" as you calculated it is only valid in the direction of current motion. If you are moving at max speed and wish to decelerate, then you actually have a "max acceleration" of twice the acceleration corresponding to stall torque, because the back-EMF would actually add to the applied voltage.
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016
Reply With Quote
  #13   Spotlight this post!  
Unread 09-07-2017, 01:02 AM
Jared Russell's Avatar
Jared Russell Jared Russell is offline
in hibernation
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,278
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: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by Oblarg View Post
On a related note, I really wish that the Talon SRXs would allow for acceleration feedforward in motion profiling mode.
They do

(In profile mode, but not in motion magic mode). In profile mode, the "velocity" you supply with each trajectory point is just multiplied by the feedforward gain and added to the output; there is no requirement that the velocities integrate correctly to obtain the position of the next point. So you can tune your feedforward velocity gain as usual, then pass in a velocity setpoint that is actually (desired_velocity + desired_acceleration * ka / kv).
Reply With Quote
  #14   Spotlight this post!  
Unread 09-07-2017, 01:17 AM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,500
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
Originally Posted by Jared Russell View Post
They do

(In profile mode, but not in motion magic mode). In profile mode, the "velocity" you supply with each trajectory point is just multiplied by the feedforward gain and added to the output; there is no requirement that the velocities integrate correctly to obtain the position of the next point. So you can tune your feedforward velocity gain as usual, then pass in a velocity setpoint that is actually (desired_velocity + desired_acceleration * ka / kv).
Well, that's quite a clever little hack, and should be easy for us to implement. Thanks!

Edit: Out of curiosity, I was wondering if you could share your experience with Ka tuning - in particular, how close would you say the theoretical "guess" of (total stall torque of the two main drive shafts)*(wheel radius)/(robot mass), perhaps adjusted by some fudge factor for efficiency (80%?), tends to be to the actual "max acceleration" value? What technique do you recommend using for empirical measurement, if theoretical values prove inadequate?
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016

Last edited by Oblarg : 09-07-2017 at 12:09 PM.
Reply With Quote
  #15   Spotlight this post!  
Unread 09-10-2017, 05:18 PM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,500
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: What is the Point of the Acceleration Feed-Forward?

So, this weekend we implemented acceleration feedforward for our motion-profiling, using the workaround suggested.

We initially guessed at a value for Ka by calculating the "maximum" acceleration at stall-torque assuming no wheel slip and a perfect voltage source, multiplied by .8 to account for frictional losses.

For our practice bot, this came out to approximately 100 feet per second squared (~110lb robot, 6 CIMs, 6.1:1 gearing, 2'' wheel radius).

(Our "fudged" velocity values were then calculated as desired velocity + desired acceleration * maximum velocity / maximum acceleration, which is equivalent to the formula provided by Jared Russel if Kv = 1/max velocity and Ka = 1/max acceleration).

This number seems ridiculously large in terms of realistic robot accelerations, and it is - the assumptions of "no wheel slip" and "perfect voltage source" are lousy assumptions that do not hold in all situations.

That said, we are careful to limit our max acceleration to a value below that which would slip the wheels, and we use the "nominal closed loop voltage" option on the Talon SRXs to account for dropping battery voltage, which should account for the latter (so long as we do not actually command un-achievable accelerations).

So, we were marginally confident that our calculated "theoretical" value would be somewhat close to the "actual" value.

As it happens, this was not the case - we found that the "maximum acceleration" that yielded a reasonable Ka was around 15 feet per second squared - far lower than the theoretically-calculated value of 100.

Perhaps someone with experience in this could shed some insight into why this is the case? I'm at a loss for why there's such a huge discrepancy between the calculated value and the value that actually works in practice, especially since we are using the Talon's nominal battery voltage compensation.
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016

Last edited by Oblarg : 09-10-2017 at 07:56 PM.
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 11:33 AM.

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


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