...many different kinds of students join our team. Some only have an interest in media, or others in cheering. What is important is that they are having fun while working in an engineering environment. - Bharat Nain [more]
 Chief Delphi > CAN Jaguar Speed Control Only Reaches 50% of Setpoint
 CD-Media CD-Spy
 portal register members calendar search Today's Posts Mark Forums Read FAQ rules

#61
02-01-2011, 07:13 PM
 techhelpbb Registered User FRC #0011 (MORT - Team 11) Team Role: Mentor Join Date: Nov 2010 Rookie Year: 1997 Location: New Jersey Posts: 1,809
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Thank you all and to further clarify how we got to this point:

http://www.atp.ruhr-uni-bochum.de/rt...ol/node61.html

The standard form of the equation as it is called here:

WikiPedia Alternative nomenclature and PID forms

Is what I'm used to working with, has more direct physical relationship to the consequences of the physical operation of the loop (that's why it's used so often in the industry, that and it probably was easier to understand when it's analog and not subject to the constraints of computer mathematics...hence my servo controllers and LabView...and that is why I'm used to thinking about the consequence of what these values mean and why they are commonly referred to as tuning parameters).

It's possible to have measurable time in this form. After all these parameters are based on time which is linear. Of course gains do not have units.

In the alternative ideal form you've used (and obviously you can go back and forth), is less intuitive in a physical implication sense, but more mathematically friendly. I'm absolutely positive there are timing implications for this form that are the consequences of physical limits, but now that I see how to go back and forth I can see more clearly what you mean when you say you can set your Ti and your Td (that seems quite nebulous in meaning to me).

I was trying to extract Ti and Td backwards using measurements from a practical implementation of the system to a point. Not trying to determine where the limits of the Kp, Ki and Kd parameters are the other way around. Obviously there is a specific relationship there and that was basically what I wanted.

It was this difference that was making us 'talk past' one another. I'm trying to apply my practical experience tuning industrial PID loops within the context I'm provided information usually, and the Jaguar obviously implements this is the way that is most friendly to it's programming. Since we got to this point by going after the code for the Jaguar, it created a gap between what I was expecting within the practical constraints and where that mathematical form can go (you can plug whatever you want in with the math but I was trying to get a grip on what the real world would limit it to and the other form of this equation makes that easier for me to visualize). After all, the real world is the reason we can't just absolutely resolve this matter in the first place and just a deliver a PID loop with a perfect tune every time.

There's nothing wrong with that. It's just a different way of looking at it.
I can now see how to get to the various points I am would like to be at.

Last edited by techhelpbb : 02-01-2011 at 08:17 PM.
#62
02-01-2011, 09:13 PM
 meakerb Mentor FRC #3786 Team Role: Mentor Join Date: Jan 2010 Rookie Year: 2009 Location: Washington Posts: 13
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

After slogging through the 5 pages of this thread, I've come to one conclusion: I'm not going to use the PID control within the Jaguar.

The original post posed the issue of how do students (and others who do not have the mathematical background of most of the posters) tune their PID controller. After 5 pages of discussion (and arguing over the mathematics and other minutia) I don't think there is any consensus here, which leaves two alternatives: trial-and-error, or just don't use the PID control.

Unless someone here can convince me otherwise, I will opt for the latter.

Mentor, team 3221
#63
02-01-2011, 09:30 PM
 techhelpbb Registered User FRC #0011 (MORT - Team 11) Team Role: Mentor Join Date: Nov 2010 Rookie Year: 1997 Location: New Jersey Posts: 1,809
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
 Originally Posted by meakerb After slogging through the 5 pages of this thread, I've come to one conclusion: I'm not going to use the PID control within the Jaguar. The original post posed the issue of how do students (and others who do not have the mathematical background of most of the posters) tune their PID controller. After 5 pages of discussion (and arguing over the mathematics and other minutia) I don't think there is any consensus here, which leaves two alternatives: trial-and-error, or just don't use the PID control. Unless someone here can convince me otherwise, I will opt for the latter. Mentor, team 3221
The only problem I ever had with the approach they were using was that I felt I couldn't reconcile my experience at each stage of the system (from the software to the electronics to the mechanics) with the results I'd get from what we have.

The approach they gave will work. It's a tested model. It just bothered me we had to push the limits of the mechanical system, which sort of ignores the electronic system which itself has limits.

There are good...technical reasons...that we all skated over when we talked about this and that make it hard for most people with basic tools to test the electronic limits especially with a brush DC motor.

I am absolutely going to test a few things from this topic and confirm that that I am correct about them. I will do so promptly and...I hope...I can try to produce something that is accessible at the level of people without a Masters or PhD control theory. For the most part: for velocity loops the presented pattern of tuning that works best was described and for position loops it was also described.

I want to clarify after all that I don't believe the TI Jaguar algorithm is wrong...it's precisely correct. There are MANY ways to implement PID in the industrial world. Some target specific applications, some target specific set points. It doesn't help that the terminology is often different for the same things. It doesn't help that certain approaches to the sort of thing often render what should be obvious patterns hidden under a pile of math into things people might not grasp in a timely manner.

I do not for the most part, disagree with the vast majority of this topic. It is unfortunately the sort of thing that can happen when people from diverse backgrounds try to grasp the details of something this complicated.

I know I'm not the first person to be confused by this during the course of a FIRST competition because I've had conversations like this with other mentors at competition.

I worry, most of all, that when 'strange things' happen and people skate over accessible understanding of it 'for what works' we shrug our shoulders and forget that we have students here that are learning. Just because the calculus books say one thing, the physics books another, it's quite probable they are only looking at the physical results and they are too easily not ideal like this quickly enough that the students feel they can really grasp it.

I never want to put anyone off. On the contrary, this is a very complicated topic that spans huge books, and I merely want to make sure that somewhere there is a properly condensed solution for basic problems that make accessible sense.

For the most part, what I've learned from this topic technically shouldn't discourage the use of the Jaguar or the PID functions. Though a nice...abridged version...might make a whole lot of people more comfortable which was sort of my concern from the beginning. I mean it's taken several students a bit of effort to figure out just how to get the encoders working on the Jaguars so they read properly, that some of the encoders had A and B wrong. That when the master link on our kit of parts robot eventually dragged it kicked the PID loop they were trying to tune unexpectedly at even intervals of minutes (just how long it took to come around the chain and catch). I don't really envy them feeling like they are tweaking something aimlessly just to get down to this point that they are tuning with the BDC-COMM and when we finish here we still have to be sure that Java actually does what it's supposed to. Especially when if you read other topics from the past up in these forums there were issues with some of these functions that are no longer relevant as the current firmware fixes them. I'm confident we can get this working. I just don't want to even think about trying to do it...oh say 1 day before we ship the robot.

Last edited by techhelpbb : 02-02-2011 at 02:42 PM.
#64
02-02-2011, 08:33 AM
 drakesword Registered User AKA: Bryant FRC #0346 (Robohawks) Team Role: Mentor Join Date: Jan 2006 Rookie Year: 2004 Location: USA Posts: 200
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
 Originally Posted by meakerb After slogging through the 5 pages of this thread, I've come to one conclusion: I'm not going to use the PID control within the Jaguar.

Tune the PID so it is responsive and quiet even if it mean it only reaches 50% setpoint.

Option A: Double your setpoint and hope for the best.

Option B: Calculate % error and increase your setpoint by that amount.

For 95% of the robots on the field Option A will work perfectly.

Quote:
 Originally Posted by meakerb The original post posed the issue of how do students (and others who do not have the mathematical background of most of the posters) tune their PID controller. After 5 pages of discussion (and arguing over the mathematics and other minutia) I don't think there is any consensus here, which leaves two alternatives: trial-and-error, or just don't use the PID control. Unless someone here can convince me otherwise, I will opt for the latter. Mentor, team 3221
If you do not want to use PID on the jaguar you can consider the PID in the API.
#65
02-02-2011, 11:43 AM
 techhelpbb Registered User FRC #0011 (MORT - Team 11) Team Role: Mentor Join Date: Nov 2010 Rookie Year: 1997 Location: New Jersey Posts: 1,809
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
 Originally Posted by drakesword As I had previously stated. Tune the PID so it is responsive and quiet even if it mean it only reaches 50% setpoint. Option A: Double your setpoint and hope for the best. Option B: Calculate % error and increase your setpoint by that amount. For 95% of the robots on the field Option A will work perfectly. If you do not want to use PID on the jaguar you can consider the PID in the API.
I just want to clarify.

You are making that suggestion so they can use the P loop only for a set point of velocity (meaning your I gain (Ki) and D gain (Kd) remain at 0) and you're compensating for the offset (droop) the P loop will experience like that by increasing the set point. This is what it appears when I read this.

I won't deny that this works. In a physical sense what you propose really will work (to a point). But as was suggested tuning I gain (Ki) would probably be a better idea when the set point is velocity. Again...things are different when the set point is a position. There are patterns to how that PID equation they implemented will react. The patterns might be a little more visually understandable in the most common standard mathematical form of the PID transfer function like LabView uses, but they are equivalent in a purely mathematical sense.

It's even entirely possible as others have suggested that you might be able to make this work with just an I loop (that would be P gain (Kp) and D gain (Kd) remaining at 0). Not sure about this however, I have to consider that a while.

To clear up some of the alternate names for the same values used in these 5 pages:

Kp = P gain = P constant (the value of P in BDC-COMM)
Ki = I gain = I constant (the value of I in BDC-COMM)
Kd = D gain = D constant (the value of D in BDC-COMM)

These have no units as they are gains.

Common industrial tuning parameters for PID loops:

Ti = integral time = repeat time = reset time = reset rate
(usually measured in repeats (resets) per minutes (or seconds) or the inverse)

Td = derivative time = rate = pre-act
(usually measured in minutes or seconds)

Ki=Kp/Ti, Kd=Kp*Td

Last edited by techhelpbb : 02-02-2011 at 03:59 PM.
#66
02-02-2011, 12:02 PM
 techhelpbb Registered User FRC #0011 (MORT - Team 11) Team Role: Mentor Join Date: Nov 2010 Rookie Year: 1997 Location: New Jersey Posts: 1,809
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
 Originally Posted by AustinSchuh If you pattern match, this I controller for velocity control has the same form as the P controller when doing position control. This says that the I term in the Jaguar's velocity loop acts like the P term in the Jaguar's position loop. A similar analysis will show that the P term in the Jaguar's velocity loop acts like the D term in the Jaguar's position loop.
As a courtesy because this is correct and because it's been long buried.
I gain (Ki) is an important key factor for a velocity set point in the Jaguar.

The I gain (Ki) really shouldn't be ignored for this purpose. Even though the most basic step by step instructions might lead one to believe that P gain (Kp) should be tuned and it will achieve a certain result (perhaps one might even think from some presentations the result you intend by just using the P gain (Kp) alone), if you read those documents carefully with the mathematical background you'll see they are often tuning to a position set point and we are talking about a velocity set point.

Right tool for the right job.
Again, my thanks for the time and patience on this matter to everyone involved.

Last edited by techhelpbb : 02-02-2011 at 04:01 PM.
#67
02-02-2011, 07:23 PM
 Greg McKaskle Registered User FRC #2468 (Team NI & Appreciate) Join Date: Apr 2008 Rookie Year: 2008 Location: Austin, TX Posts: 4,861
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Along the way, this thread briefly commented on considerations for doing PID on the cRIO and spent a considerable amount of time investigating PID implementation on the Jaguar.

To add a bit of additional info on the cRIO option, keep in mind that the default loops running on the cRIO are at standard priority. If the CPU isn't highly loaded, and no large processing tasks are running, the timing of the loops will likely be fine. The somewhat simple frameworks that don't use priorities trade timing determinism for simpler code and fewer new concepts.

If you are trying to have tight timing constraints and you have large processing tasks such as vision, you should investigate taking advantage of the OS and development tools for added determinism. I'm talking about priorities, timed loops, and related realtime features. It will introduce new concepts, but will restore your code's ability to meet deadlines.

There are a number of elements to consider when choosing how to do control, and the good news is that using the Jaguar to do truly dedicated control is a great enhancement to the control system. Meanwhile, the ability to view plots of the inputs, output, and setpoint, and to be able to normalize or fixup angle wraps are areas where the cRIO may be a better choice.

While portions of this thread were somewhat painful to read through and difficult to understand, in the end I hope that teams and mentors learn how to relate the different approaches and help teams choose between control choices.

#68
02-03-2011, 11:12 AM
 techhelpbb Registered User FRC #0011 (MORT - Team 11) Team Role: Mentor Join Date: Nov 2010 Rookie Year: 1997 Location: New Jersey Posts: 1,809
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

I just want to follow up a concern from another mentor about PID loop tuning in here.

Above drakesword said that you can drive 95% of the robots at the competition using the tuning method he outlines.

What he is describing in that post 'just works'. It's hard to argue with that tangible outcome. Problem is it's actually quite possible that what he is describing could 'just work' while there are other problems in your robot. That means it might be a good second choice if you can't get it to do what it should and can't figure out how to fix it.

What I was told by someone was that they can never tune the I portion or D portion of their PID loops in LabView or the Jaguar for a velocity set point.

When you try to tune the I portion or the D portion of the PID loop with a set point of velocity, especially if you use the observation of oscillation method presented by others and echoed by myself above. It is vital that 2 criteria are met in your robot:

1. The system you are tuning >MUST< be operating smoothly. The battery should have a reasonable charge. The electrical connections should be stable. The electrical connections should be correct. The speed controls should be properly cooled. The motors should be mounted well. The motors should be operating freely and they should be tested. The gear boxes should not have chipped teeth and should run smoothly. Belts shouldn't be slipping, sprockets shouldn't be skipping. Chains shouldn't be snagging. Wheels should be smooth running (even if the wheel surfaces are a bit uneven). The frame of your robot that was straight when you started before should be within specifications to keep the rest running smoothly. Just a hint, think carefully about that pneumatic shifter on your gear box and the effect it'll have on your PID loop.

2. Hopefully you are not using a simple PID loop where you can't use it. There are more complicated control loops that exist. Other forms of the PID loop. Obviously the Jaguar doesn't give you much choice in this matter. If you realize you can't use the Jaguar's ideal discrete timed PID loop you could (and we've done it) implement whatever you like (or can) in the cRIO. It appears you can still read the encoders attached to the Jaguars if you zero out all the terms of their PID loop and seed it with some really small values (at least it seems that way for us in Java). You might even be able to get the cRIO to run a special case PID loop and use the sensors on the Jaguars if you need the extra I/O.

Unfortunately when you observe for things like oscillation with visual and audio observation you can make mistakes in tuning. This method of tuning is deceptively simple. You might hear a noise in this tuning method and assume you've reached the first sign of oscillation. Problem is that noise might really be caused by some simple electrical or mechanical issue and if you eliminated that issue...then this tuning of the I portion for the velocity set point would actually work. Hard to do this sort of thing in a large noisy room with limited time and tools. If you really want to make this work...and you're having trouble doing it...try it when you can patiently tinker with it don't just discount it.

Simple rules are nice. In industrial settings. We'd take measurements of values. Put them into the proper context in the standard PID form. If we had to get them to the Ki or Kd values the Jaguar needs, we'd assume the linear relationship and convert then compensate for some real world issues. This adds math and more measured observations. It should make for a more precise tuning for the loop. However, in doing that math you might discover that your measurements would show you that your system can't use such a simple PID loop. Tuning for the oscillation as has been described is simple to explain. However, you might never do the sort of measured observation of the system that would clearly demonstrate you shouldn't be using such a simple PID loop to control it, you could only find that out after a long process of elimination and possibly lots of oscillation with the simple method as proposed. It's a trade off: what we have time for, what we have tools for, what we have the available understanding to obtain. The math is sound. The concept does work. There is nothing wrong with the Jaguar design as such. It's just complicated and needs careful patient commitment to make this work as it should.

Good luck to everyone, and again, thank you all for your patience and time.

Last edited by techhelpbb : 02-03-2011 at 01:19 PM.
#69
02-03-2011, 09:51 PM
 kamocat Test Engineer AKA: Marshal Horn FRC #3213 (Thunder Tech) Team Role: Mentor Join Date: May 2008 Rookie Year: 2008 Location: Tacoma Posts: 894
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Here is an example of a situation where PID does not correctly describe the error you will encounter:

Holding an unbalanced arm in position (against gravity).

In this, the force required compared to the angle of the arm is a sine function. With PID, then, you're likely to have uncontrollable oscillations near 0 and 180 degrees, or insufficient force near 90 degrees.

My team's robot does indeed have a mechanism similar to this. I plan to try PID and see how well it works. If it's not adequate, then we'll find another way.
__________________
-- Marshal Horn
#70
02-18-2011, 02:36 PM
 Nikhil Bajaj MATLAB Fan FRC #0461 (Westside Boiler Invasion) Team Role: Mentor Join Date: Feb 2003 Rookie Year: 2002 Location: West Lafayette, Indiana Posts: 101
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

A question to those of you who have seen the code and looked in depth at the Jaguar implementation of the PID...is there windup limitation on the integrator? I can't find anything that says that there is--if there isn't I would personally feel concerned about running certain systems (those that would have a tendency to get into situations where they are under-actuated) with the Jaguar/CAN/PID combination.
#71
02-18-2011, 03:08 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 9,126
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
 Originally Posted by Joe Ross That's the WPILib source code, not the jaguar source code.
Good catch Joe. That's what I get for posting while talking on the phone.

I'll delete the post.

Looks like the Jag PID limits integrator wind-up:

Code:
```    //
// Update the error integrator.
//
if((psState->lIntegrator & 0x80000000) == (lError & 0x80000000))
{
//
// Add the error to the integrator.
//
psState->lIntegrator += lError;

//
// Since the sign of the integrator and error matched before the above
// addition, if the signs no longer match it is because the integrator
// rolled over.  In this case, saturate appropriately.
//
if((lError < 0) && (psState->lIntegrator > 0))
{
psState->lIntegrator = psState->lIntegMin;
}
if((lError > 0) && (psState->lIntegrator < 0))
{
psState->lIntegrator = psState->lIntegMax;
}
}
else
{
//
// Add the error to the integrator.
//
psState->lIntegrator += lError;
}

//
// Saturate the integrator if necessary.
//
if(psState->lIntegrator > psState->lIntegMax)
{
psState->lIntegrator = psState->lIntegMax;
}
if(psState->lIntegrator < psState->lIntegMin)
{
psState->lIntegrator = psState->lIntegMin;
}```

Last edited by Ether : 02-18-2011 at 03:21 PM.
#72
02-18-2011, 04:54 PM
 Nikhil Bajaj MATLAB Fan FRC #0461 (Westside Boiler Invasion) Team Role: Mentor Join Date: Feb 2003 Rookie Year: 2002 Location: West Lafayette, Indiana Posts: 101
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Thanks, Ether. That helps...I guess I will have to play around with the CAN stuff further in order to figure out how to set that value.

Another feature I like to include sometimes when I program a PID loop for myself is that I don't add anything to the integrator if the system is saturating (not just keeping it from winding up too much, but just not adding into the integral term if it won't help anything).

So, if P and D are maxing out the actuator (pegging it at 12V) then there doesn't seem like there's much point in adding to the integrated term. This is certainly not a "classical PID", but limiting integrator windup, and having a saturated system is also not "classical PID".

It also appears that there isn't a way to use a D term with a built-in low pass filter. I know LabView and Simulink both have this, but the Jaguar doesn't, else we'd have a place to put the time constant for that.
#73
02-19-2011, 10:14 AM
 kamocat Test Engineer AKA: Marshal Horn FRC #3213 (Thunder Tech) Team Role: Mentor Join Date: May 2008 Rookie Year: 2008 Location: Tacoma Posts: 894
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Nikhil,
Are you saying that the standard form and ideal form of PID will actually perform differently?
__________________
-- Marshal Horn
#74
02-19-2011, 01:09 PM
 Nikhil Bajaj MATLAB Fan FRC #0461 (Westside Boiler Invasion) Team Role: Mentor Join Date: Feb 2003 Rookie Year: 2002 Location: West Lafayette, Indiana Posts: 101
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

I'm going to write post in language that I think will widen the audience a bit so that hopefully other people who aren't super-knowledgable about controls can understand. If I come across as condescending to those who know a lot about this stuff (which is clearly most people in the thread), I don't mean to be!

As defined in the Wikipedia article on PID Controllers referred to earlier, no, the standard and ideal forms will not perform differently. They are mathematically equivalent, with the standard form being more intuitive from a physical and tuning perspective, and the ideal form being a bit nicer for analysis and if you are going to do gain selection via methods like direct pole-placement (if you don't know what that is, don't worry about it too much if you're just concerned with getting your robot working. Just tune your PID, it'll work well with Ziegler-Nichols or some other tuning method).

But those forms are just dumb algorithms. PID isn't a be-all, end-all control method. When the PID controller decides on what the next output should be, it doesn't know about actuator saturation and the implications thereof.

It only knows "I've got to multiply my error by this, multiply the integral of my error by this, and multiply the derivative of my error by this, add them up, and that's my output." If you saturate your controller, it neither knows nor cares. It still thinks the integral term should be winding up, and doesn't care how much it does.

If you write code that changes that, then you have a controller that is no longer a PID controller, it is some extension of a PID controller that is better suited for systems that will commonly saturate their actuation authority. Adding something to limit windup, or preventing any summation into the integral when the proportional term or derivative terms are saturation, are non-linear additions to the ideal/standard PID controller that reflect our understanding of the reality of the system. Those additions are what can significantly change performance, and we add them because in the systems we're working with, we think it will change performance for the better.

Taking saturation into account in the ways I've described, for example, will often help significantly with overshoot without impacting settling time, etc. as much as just fiddling with your P, I, and D gains would.

The other addition I mentioned in my previous post is one that affects the derivative term. Because taking a derivative tends to exacerbate high-frequency noise, a common addition to PID controllers is to include what is called a low-pass filter on the derivative (which is a way of basically decreasing the effect of very fast changes in a value over time, like noise, and keeping the low-frequency, slower changes in the value over time, like what the physical system is doing). This can improve the performance of derivative-related terms in noisy systems. Probably not a huge deal when you are using incremental or absolute encoders, but it can be miraculously helpful if you are using the analog signal from a gyro or potentiometer. The low pass filter is typically linear, so this isn't as complicated of an addition in terms of modeling the effects.

We know the systems we work with better than the dumb PID algorithm does, and any help we can give it, the better. Plus, today we have tools like LabView and Simulink, etc., that make it relatively easy to simulate the effects of doing non-linear additions to the controller.

Yeesh, long post. I hope it was helpful in explaining what I meant.

Last edited by Nikhil Bajaj : 02-19-2011 at 01:14 PM. Reason: grammar :(
#75
02-19-2011, 03:04 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 9,126
Re: Jaguar Speed Control Only Reaches 50% of Setpoint

Quote:
 Originally Posted by Nikhil Bajaj I'm going to write post in language that I think will widen the audience a bit so that hopefully other people who aren't super-knowledgable about controls can understand. If I come across as condescending to those who know a lot about this stuff (which is clearly most people in the thread), I don't mean to be!
Not to worry. Excellent post.

 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:30 AM.

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

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