We try to limit ourselves only by physics. As the first person on the planet to communicate over a quantum encrypted AOL instant messenger session, I try to ignore those limits as well. - EricVanWyk [more]
 Chief Delphi What is the Point of the Acceleration Feed-Forward?
 CD-Media CD-Spy
 portal register members calendar search Today's Posts Mark Forums Read FAQ rules

#1
09-05-2017, 07:27 PM
 xForceDee Registered User AKA: Bart Kerfeld FRC #4239 (Warpspeed) Team Role: Alumni Join Date: Dec 2012 Rookie Year: 2012 Location: Seattle Posts: 96
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.
#2
09-05-2017, 07:29 PM
 dardeshna 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: 150
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
 Originally Posted by xForceDee 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)

2018 (FRC #8 - Team Captain) Arizona North Regional, Silicon Valley Regional
2017 (FRC #8 - Build Captain) Ventura Regional Quarterfinalist, Entrepreneurship Award, and Creativity Award, Silicon Valley Regional Finalist, Entrepreneurship Award, and Wildcard, Roebling Division Semifinalist, Chezy Champs Quarterfinalist, Capital City Classic Semifinalist
2016 (FRC #8 - Safety Captain) Central Valley Regional Finalist and Wildcard, Silicon Valley Regional Quarterfinalist, Curie Division, CalGames Quarterfinalist and Entrepreneurship Award, Capital City Classic Quarterfinalist
2015 (FRC #8 - Student) Central Valley Regional Entrepreneurship Award, Silicon Valley Regional Entrepreneurship Award, Capital City Classic Semifinalist and Judges' Award
#3
09-05-2017, 07:35 PM
 Oblarg 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,811
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
 Originally Posted by xForceDee 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

FRC Drivetrain Characterization

Last edited by Oblarg : 09-05-2017 at 10:50 PM.
#4
09-05-2017, 10:32 PM
 GeeTwo Mentor AKA: Gus Michel II FRC #3946 (Tiger Robotics) Team Role: Mentor Join Date: Jan 2014 Rookie Year: 2013 Location: Slidell, LA Posts: 5,317
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.
#5
09-06-2017, 10:22 AM
 xForceDee Registered User AKA: Bart Kerfeld FRC #4239 (Warpspeed) Team Role: Alumni Join Date: Dec 2012 Rookie Year: 2012 Location: Seattle Posts: 96
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.
#6
09-06-2017, 10:44 AM
 Oblarg 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,811
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
 Originally Posted by xForceDee 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

FRC Drivetrain Characterization
#7
09-06-2017, 11:00 AM
 xForceDee Registered User AKA: Bart Kerfeld FRC #4239 (Warpspeed) Team Role: Alumni Join Date: Dec 2012 Rookie Year: 2012 Location: Seattle Posts: 96
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.
#8
09-06-2017, 11:07 AM
 brian5115 Registered User FRC #5115 (Knight Riders) Team Role: Leadership Join Date: Sep 2016 Rookie Year: 2015 Location: Maryland Posts: 57
Re: What is the Point of the Acceleration Feed-Forward?

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

Creator of RoboLog

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

2017:
District Event Winner - Central Maryland
#9
09-06-2017, 11:09 AM
 Oblarg 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,811
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
 Originally Posted by xForceDee 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

FRC Drivetrain Characterization
#10
09-06-2017, 11:30 AM
 xForceDee Registered User AKA: Bart Kerfeld FRC #4239 (Warpspeed) Team Role: Alumni Join Date: Dec 2012 Rookie Year: 2012 Location: Seattle Posts: 96
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.
#11
09-06-2017, 12:46 PM
 D.Allred Registered User FRC #4451 (Rat Rod Robotics) Team Role: Mentor Join Date: Jun 2009 Rookie Year: 2009 Location: Greenville, SC Posts: 282
Re: What is the Point of the Acceleration Feed-Forward?

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

David
#12
09-06-2017, 01:14 PM
 Oblarg 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,811
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
 Originally Posted by xForceDee 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 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

FRC Drivetrain Characterization
#13
09-07-2017, 01:02 AM
 Jared Russell Powered Up 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,383
Re: What is the Point of the Acceleration Feed-Forward?

Quote:
 Originally Posted by Oblarg 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).
#14
09-07-2017, 01:17 AM
 Oblarg 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,811
Re: What is the Point of the Acceleration Feed-Forward?

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

FRC Drivetrain Characterization

Last edited by Oblarg : 09-07-2017 at 12:09 PM.
#15
09-10-2017, 05:18 PM
 Oblarg 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,811
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

FRC Drivetrain Characterization

Last edited by Oblarg : 09-10-2017 at 07:56 PM.

 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         FIRST E-Mail Blast Archive     Rumor Mill     Career     Robot Showcase Technical     Technical Discussion     Robotics Education and Curriculum     Motors     Electrical         CAN     Programming         NI LabVIEW         C/C++         Java         Python     Control System         FRC Control System         Sensors     Pneumatics     Kit & Additional Hardware     CAD         Inventor         SolidWorks         Creo     IT / Communications         3D Animation and Competition         Website Design/Showcase         Videography and Photography         Computer Graphics     National Instruments LabVIEW and Data Acquisition         LabView and Data Acquisition Competition     Unsung FIRST Heroes     Awards         Chairman's Award     Rules/Strategy         Scouting         You Make The Call     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         OCCRA Programming Other     Chit-Chat         Games/Trivia             Fantasy FIRST     Car Nack's Corner     College & University Education     Dean Kamen's Inventions     FIRST-related Organizations         Western Region Robotics Forum         Southern California Regional Robotics Forum         The Blue Alliance             Video Archives     FIRST In the News...     FIRST Lego League         Lego Mindstorm Discussion     FIRST Tech Challenge     VEX         VEX Robotics Competition         VEX IQ     Televised Robotics     Math and Science         NASA Discussion ChiefDelphi.com Website     CD Forum Support     Extra Discussion

All times are GMT -5. The time now is 01:13 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