Help, I'm a world class computer programming genius yet I'm totally lost.

[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.

[dtengineering]

I'd add more, but the important parts have already been covered... all within about two hours. Congratulations CD posters on doing an excellent job to help someone new to the field once again.

And if it is any comfort, it took me (programming since C64 days) a while to come up to speed, and our programming mentor (a professional software jockey) a couple weeks to make the switch from computers to robots. One of the great things about FIRST is that there is a lot for us old guys to learn, too!

Once you get the I/O figured out, there is a massive overlap in the skill set. Sounds like your on track to become an excllent mentor for this team!

Jason

[Mauri Laitinen]

I faced the same difficulty a few years ago when I started mentoring my daughter's team. I found that picking up a copy of "Programming and Customizing PICmicro Microcontrollers" by Myke Predko explained the odd acronyms and machine-specific identifiers.

While a lot of the book concentrates on basic architecture, you'll probably be more interested in the sections on timers and interrupts, including CCP. It beats trying to figure things out from datasheets. I picked up my copy at a Borders bookstore.

I'd also suggest looking at the MPLAB C18 User's Guide (available on microchip.com) especially the section on "ISO Divergences." It also discusses interrupt handling.

As everyone else has said, Kevin Watson's code is pretty much the definitive model for programming the robot controller.

The other place to help get up to speed is the white paper section of Chief Delphi and some of the kickoff seminars on the FIRST website.

Good luck.

[Lafleur]

This is a good reference to the odd PIC things along with the current datasheet on the 18F8722 that you can download from Microchip...

Applying PIC18 Microcontrollers: Architecture, Programming, and Interfacing using C and Assembly by Dr Barry B. Brey from DeVry University..

Takes you from knowing nothing to full development in Microchip "C". Very well organize and full of complete examples on I/O and Interrupts.

Recommend for both new and older programmers...

ISBN: 0-13-088546-0, over 500 pages and a bit pricey at $112

authors page: http://members.ee.net/brey/p10.htm

[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

[Kevin Sevcik]

John,

First, I'll apologize now for lying in my last post about it being my last long winded post of the night....

To answer your last question first, in the broadest sense, it doesn't matter too very much if you're programming on Vex or FRC. The fundamental structure of the code is rather similar. Superficially, the inputs to the Vex controller are more limited and only consist of those few PWM_in# variables that tell you the position of the radio controller's sticks. These are equivalent to the p#_x, p#_y, etc on the FRC. The Vex controller doesn't have any equivalent of p#_sw_top, etc. Similarly, the vex's pwm## variables are equivalent to the same on the FRC. The FRC also has the relay#_fwd/rev variables that don't have vex equivalents. Digital IOs, analog inputs, and the serial ports are all mostly equivalent. The lack of physical space on the Vex brain meant IFI had to multiplex the analog inputs with the digital IOs, but this is not the case on the FRC controller.

Finally, because the FRC system plugs into a computer controlled field, the FRC controller receives bits instructing it to enter Disabled mode or Autonomous mode. Both as as they imply. In Disabled, your receive valid input from the operator console, but all outputs of the robot are disabled by the master processor, save the digital and analog IOs. In Autonomous, outputs are enabled, but the robot is intended to be on its own, so all inputs received from the operator console are invalid. The final operating mode is Teleop, which is the default if not in the other two modes. Inputs and outputs are both valid in this mode.

Now, here's the good news. Those massive tomes about the PIC microprocessors? You honestly barely need to read them. Nearly all of the onboard peripherals on the user PIC are either taken up by IFI or routed to pins on the exterior of the robot controller the are buffered or otherwise rendered useless for most advanced functions. If you're really determined, you mostly need to read up on three things. Interrupts, Timers, and CCPs. In that order, preferably. If you're really pressed for time, Kevin Watson has a LOT of functionality already coded up and in highly bug-tested form. If you're feeling more adventurous, I would look into Kevin's C18 3.10 version code or the restructured C18 2.4 code mentioned in this thread. This simple bit of restructuring makes the program flow much more intuitive and easier to follow.

That said, a large percentage of robots out there get by with little more than the "joystick 1 makes this motor go, button 3 makes this light blink" kind of code you mentioned earlier. After getting that far, I'd make it your primary goal to get some encoders on your robot's wheels/drive motors and attempt to implement a PID control on your drive speed. Robot drivetrains are notoriously poorly balanced and it can be easy to spot teams without PID control, as the robot will make a very graceful, large diameter arc whilst attempting to drive straight across the field. If you get that far, implementing a useful autonomous mode is fairly easy. You can use the encoder to measure the distance your robot has traveled use that to transition a state-machine design to get your robot driving down the field and making a left turn or whatever it seems appropriate to do.

So, like I said, you don't strictly need all the extra knowledge in those tomes. It CAN come in handy, of course. We used such esoteric knowledge one year to count the pulses on an encoder at rates much higher than it would be feasible to count them using interrupts. But by and large, you mostly need the info in all the IFI guides and manuals and the lack of time to make using Kevin Watson's code seem like a great idea.

[kaszeta]

Originally Posted by jratcliff

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.

It is daunting for a new team, but it's also important not to lose focus. IFI and Kevin Watson have both provided code that essentially distills programming the robot into having to supply a handful of functions, with a fairly well-defined set of input and output variables. If you start simple and build your way up, it's pretty easy to get at least a basic robot implemented (our first year with the new C system, 2004, we managed to assemble a full controller with PID controls, shaft encoders, and a realtime clock, and that was with one mentor (myself) with decent programming experience and three students who had only done visual BASIC programming).

The other thing to remember is that there are a lot of good resources out there for new teams to use. You're visiting one of the better ones (ChiefDelphi). Look at the whitepapers. Read the forums. Ask questions. We're here to help you out. There are few problems you can run into where someone here can't help you out, and quickly.