[jratcliff]

Originally Posted by Kevin Sevcik

First, about open sourcing your code. Kevin Watson has asked that his code not be redistributed, so be mindful of that.

For control algorithms, etc, the most important one to understand is PID control, though practically speaking most FRC mechanisms only need P or PD control. These whitepapers should prove helpful for that.

The (not-so) brief summary for PID control is that it works like your cruise control works. You pick a set point (cruising speed). The PIC compares this setpoint to feedback it gets from the real world (speedometer). If they don't agree, the PIC applies a control signal in the appropriate direction to correct. In a cruise control, if your actual speed is too slow, it hits the gas. Too fast, it lets off the gas. The algorithm simply multiplies the error by a constant gain and sets the output to this, and you have Proportional control. The remaining terms don't apply directly to cruise control, buuuut... If you were climbing a mountain/left the tire chains on/were dragging a boat anchor, then your car would consistently have an error, since you have to apply SOME gas to over come this, and when you hit your set point, you're applying 0 gas. So you integrate the error as time goes on, multiply by a gain, and add this to your P term. The longer you're missing your set point, the bigger this term, and the more you correct. Integral control. Finally, there's Derivative control. You monitor how fast the error is changing, multiply by a gain, and add. The purpose here is to slow down a rapidly correcting system so that it doesn't overshoot its target.

And all that is covered in more detail with better examples in those white papers. Encoders are opto-electrical devices that you can use to determine the position or speed of a shaft, so you can use them for the feedback. You can also use potentiometers, inductive or ultrasound sensors, photo-resistors, or whatever else is appropriate for what you're interested in controlling.

Finally, to end my last long winded post of the night, I'd highly recommend reading up on state-machines as mentioned in this presentation. It's a highly useful technique for autonomous programming. Especially with the hybrid mode this year.

Thanks for an incredibly helpful post! Most of what I would post on my website would likely fit my main theme as 'snippets'. I define a snippet as a single self contained piece of source code with no external dependencies which 'does something useful'. I still have snippets I wrote 25 years ago that I keep in my bag of tricks today.

It sounds like I have about six weeks of documentation to read at this point with only four weeks left to completion!! It's clear to me now that FIRST does not really expect any robotics teams to build a robot from ground zero in six weeks; the learning curve simply to read documentation is quite steep even for a professional in the industry much less a high school student.

I have to say that this is all very intimidating for a brand new team that is just getting off of the ground. It doesn't help when PBS is filming the entire thing the whole time!

Kevin, you don't have to convince me about state machines. AI programming is my absolute favorite code to work on in computer games. I use a combination of state machines with memory to create AI's that avoid 'brain lock'. The other thing I really care about when writing AI's is to have them always dealing with lots of problems simultaneously in parallel.

I use a combination of state machines, memory, modular systems, and interrupts to create AI's that behave in a very natural way. I typically break systems out into various components (path finding, vision processing, emotional state, goal oriented behavior, etc.) and run all of these systems simultaneously in parallel feeding back to an interrupt driven state machine which runs via a scripting language on a virtual machine. A state machine, coupled with memories to avoid 'brain lock' allows a system to be extremely reactive and adaptive to its environment.

However, as my friend John Miles (http://www.thegleam.com/ke5fx/) likes to remind me, I need to learn to walk first before I start getting too far ahead of myself. By the way, if you don't know who John Miles is, he is an engineer worth knowing...

I do have one question in response to some of the answers I have received in this thread.

Why does it make any difference if I'm programming for a VEX or FRC controller? They both effectively have the same PIC micro-controller and execute the same basic logic.

I mean, worst case scenario I link to a different script, what does it matter which controller I run the C code on?

Thanks,

John