View Single Post
  #6   Spotlight this post!  
Unread 13-01-2008, 03:20
Kevin Sevcik's Avatar
Kevin Sevcik Kevin Sevcik is offline
(Insert witty comment here)
FRC #0057 (The Leopards)
Team Role: Mentor
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Houston, Texas
Posts: 3,685
Kevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond reputeKevin Sevcik has a reputation beyond repute
Send a message via AIM to Kevin Sevcik Send a message via Yahoo to Kevin Sevcik
Re: Help, I'm a world class computer programming genius yet I'm totally lost.

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.
__________________
The difficult we do today; the impossible we do tomorrow. Miracles by appointment only.

Lone Star Regional Troubleshooter