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

jratcliff

12-01-2008, 23:10

Hey guys, I'm looking for help in getting started on things here. My son is a Freshman in high school and is beginning first robotics this year. His team doesn't really have any programming expertise to speak of and it looks like I have been drafted to help out.

I have been drafted because I am an expert professional computer programmer. I have been programming computers in assembly language, C and C++ for about 30 years. One of the first computers I programmed was an Altair, where you had to actually program the computer by setting each instruction in binary via a set of switches and pressing a button. Output was a set of LED lights.

So, color me surprised when in 2008 I find that high school kids are still programming low-level embedded systems as 'beginner projects'.

I have written a couple of best selling computer games for Electronic Arts, shipped games on numerous platforms and microprocessors, and more recently was the lead engine programmer for the massively multi player online game 'Planetside' for Sony Online Entertainment.

So, of course, I am posting a message in this forum, generally to a bunch of teenagers, asking, please, for some help.

Now, surely I don't need any help programming, that I know all about. What I want to know, is where in the heck is the documentation for the very, very, hardware specific features of programming these kits for the FRC competition?

This week I purchased a VEX Robotics kit and my son, Alex, put the whole thing together. Today we installed MPLAB and experimented with compiling and running some sample code.

This raised a huge number of questions. When you read the sample code provided it is filled with 'comments' that make references to obscure acronyms which I cannot find documented anywhere.

I currently have the MPLAB compiler, assembler, and linker. I can compile, link, and debug code both on the simulator and the robot controller itself. I have the MPLAB C documentation which, for the record, is quite excellent. I purchased this week a number of books about programming PIC microcontrollers and I am familiarizing myself with them.

Still, I have a number of questions. As I read source code, documentaiton, and messages here on the forum it appears to presume a massive amount of knowledge about acroynyms that I can't find documented anywhere. When beginners post questions on the forum they are generally referred to reference material on the C programming language. That's all well and good, but where is the reference material on the arcane oddities of getting the transmitter/receiver to talk to the microchip and the microchip to control inputs, outputs, and motors?

Let me give you a specific example. In the sample source code provided with the VEX as a 'learning tool' for new programmers you can find the following section of code:

/*
Example: The following would generate a 40KHz PWM with a 50% duty cycle
on the CCP2 pin (PWM OUT 1):
*/

/**
Setup_Who_Controls_Pwms(USER,USER,MASTER,MASTER,MA STER,MASTER,MASTER,MASTER);
CCP2CON = 0x3C;
PR2 = 0xF9;
CCPR2L = 0x7F;
T2CON = 0;
T2CONbits.TMR2ON = 1;
Setup_PWM_Output_Type(USER_CCP,IFI_PWM,IFI_PWM,IFI _PWM);
**/

This is, of course, remarkably non-useful to the new programmer. It raises a long series of important questions. In addition to wondering what the heck a 'PWM' is, and what it's good for, we have a lot of other questions.

(1) Where is the source code to the logic that runs when 'MASTER' is set to true? Is this, perhaps, in firmware and we don't have the source?
(2) What is 'CCP2CON' and why are we setting it to 0x3C? (No documentation)
(3) What is 'PR2' and why are we setting it to 0xF9?
(4) What is CCPR2L and why are we setting it to '0x7F'?
(5) What is 'TTCON' and why are we setting it to 0?
(6) What is 'T2CONbits.TMR2ON' and why are we setting it to zero?

Apparently, even in sample code for teenage programmers new to the FRC competition we are to assume they know what 'PWM', 'TTON', "CCPR2', and 'PR2' mean!???

Where is the missing piece of documentation in all of this?

I do have some very specific questions:

(1) Can I run the same code I compile and link with my VEX controller on the teams FRC controller?
(2) Kevin, of kevin.org, provides some amazing looking sample framework code. Can I run this on a VEX or is it for FRC only? Is there enough in Kevin's framework to run a basic robot on a frame, or does it still require a lot of code?
(3) Where can I find documentation about all of the device specific acronyms, what they mean, and how are they used?

For example, where is an explanation of (A) how to read all of the incoming signals from the remote control and (B) send output signals to all of the motors? Are these the same or different between the FRC controller and the VEX controller?

I feel like, after having read enormous amounts of documentation, reviewed a lot of source code, and gone over numerous reference books on how to program the PIC microcontroller, I still don't know how to make a motor turn when somebody moves a joystick button on the controller.

Just what am I missing??

Thanks,

John and Alex

robogeek753

12-01-2008, 23:31

While I have never programmed a VEX Robot, I may be able to help a little bit.

0.) PWM is simply a output, usually to a motor's Victor speed controller.

To the rest of them, they look pretty VEX specific to me, I've never seen them on a FRC Robot (though I was looking at code someone else wrote, may be different at lower levels). Thus, to answer another question, you will probably have one heck of a time switching you code from VEX to FRC. (Look at the EasyC program and you have to change the entire format for FRC vs. VEX). p1_y indicates the joystick programmed into the first joystick port on our OI's Y axis value, this may help in setting up an FRC robot moving a bit.

Again, all the code I've looked at was written by someone else, so I don't know if they did any special setup to make it work so nice the way it did; but I am glad to offer any knowledge I can.

P.S. Welcome to the FRC and/or FTC!

P.P.S. If the code is confusing, try EasyC. Your team should have a free license for it, and it is actually a relatively powerful program (still trying to figure out how to use the text editor though...)

Nathans

12-01-2008, 23:33

I've never personally programmed Vex, but I'm told that it's pretty much the same as the FRC controller, so they might be interchangeable.

As for documentation, Kevin Watson includes pretty extensive readmes with all of the code he writes (the C18 3.0+ beta not yet included), as well as pretty extensive documentation for C18 and the RC. All of this can be found on his code repository (kevin.org/frc).

If you have specific questions about his code, he patrols these forums pretty frequently. You can either wait for a response here (I wouldn't be surprised if he did), post in one of his threads or email him. One way or another, I'm sure you'll get an answer.

As for how close the default code gets you to a working robot, you can get basic drive code in a couple of lines, e.g.

pwm01 = p1_y
pwm02 = ~p2_y

This assumes that your motors are hooked up to pwm outs 1 and 2, your joysticks are plugged into ports 1 and 2, and that whichever motor needs to be flipped due to position is in pwm out 2. Hopefully Kevin's documentation or programmers better at this than me can shed some mroe light on this for you.

mluckham

12-01-2008, 23:36

Excellent post - I was where you are now, 3 years ago.

You may find this document at IFI Robotics interesting Control System Overview (http://www.ifirobotics.com/docs/legacy/control-system-overview-2004-01-07.pdf).

Over at Microchip you will find detailed (!) programming reference materials for the PIC PIC18F8722 resources (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010327).

If you don't want to climb the detailed learning curve of itsy-bitsy details, I suggest looking at Easy/C (there is a 30-day eval) and the accompanying WPILIB library.

mluckham

12-01-2008, 23:44

Also, the "default code" that comes from IFI contains a few lines of code that copy values from the joystick ports (connected to the Operator Interface) to the PWM outputs. PWM outputs are wired to Victor speed controllers, and these to the motors.

In user_routines.c is the "Default_Routine()" function where most people do their programming. The following lines copy joystick values to the PWM outputs. 127 is the 'neutral' or 'stop' value for the Victor speed controllers ... sending the PWM a 0 value would operate the attached motor at full speed, sending 254 would operated at full speed in the opposite direction.

p1_x = 255 - p1_y;
p1_y = 255 - pwm05;

pwm13 = pwm14 = Limit_Mix(2000 + p1_y + p1_x - 127);
pwm15 = pwm16 = Limit_Mix(2000 + p1_y - p1_x + 127);

In ifi_aliases.h you find the definitions for the p1_x, p1_y, etc, etc defined-constants:

#define p1_y rxdata.oi_analog01
#define p2_y rxdata.oi_analog02
#define p3_y rxdata.oi_analog03
#define p4_y rxdata.oi_analog04
#define p1_x rxdata.oi_analog05
#define p2_x rxdata.oi_analog06
#define p3_x rxdata.oi_analog07
#define p4_x rxdata.oi_analog08
#define p1_wheel rxdata.oi_analog09
#define p2_wheel rxdata.oi_analog10
#define p3_wheel rxdata.oi_analog11
#define p4_wheel rxdata.oi_analog12
#define p1_aux rxdata.oi_analog13
#define p2_aux rxdata.oi_analog14
#define p3_aux rxdata.oi_analog15
#define p4_aux rxdata.oi_analog16

Jon Stratis

12-01-2008, 23:46

Basically, you're missing the inputs and outputs :) I had the same problem last year, in that none of the documentation seems to really help much with what someone of our talent would need to know. That being said, I can help.

I would recommend starting with Kevin's code (links here, but it sounds like you already found them: http://www.chiefdelphi.com/forums/showthread.php?t=60377) - it's easy to use and pretty simple. For a very basic start, make all your changes to the teleop.c file - that's the one that will "run" when you power up your robot for the first time in your garage. From there, you can branch out to the rest of the code.

Now, for the rest of it. Go grab your RC (the board that goes in the robot), the OI (the board that goes with the operator), a joystick, and open up ifi_frc.h from Kevin's code. In that header file is pretty much all of the inputs and outputs you'll need, and everything is mapped to easy to remember names.

So, scrolling down the list, you'll find a bunch of p1_, p2_, p3_ and p4_ variables. All of these map, conveniently enough, to the 4 joystick ports on the OI. the analog ones (x, y, wheel, and aux) all have input values of 0-255 - using x as an example, 0 would be when you have the joystick all the way to the left, 127 is in the middle, and 255 is all the way to the right. Next, you see the digital inputs (trig, top, aux1, aux2) - these are your buttons, and are 0 normally, 1 if the button is depressed.

So, now you should have all of your inputs!

On the RC, you'll see a bunch of pins around the outside - PWM, digital, analog, and the relays are the main ones to worry about. Moving further down the ifi_frc.h file, you'll first see the digital mappings. the digital_io_ variables are used to tell if it's an input or output pin - just set them to INPUT or OUTPUT. from there, you can use rc_dig_in and rc_dig_out to get or set values (0 or 1).

Next in the file are the pwm ports, conveniently with variables starting with pwm. These are analog ports, and are used to control things like your drive motors. Set them to any value 0-255. For a drive motor, a value of 0 would be full speed reverse, 255 full speed forward, and 127 stop (depending on the load on the motors, you won't get any change for a range of values around 127).

Next are the relay ports (relayX_fwd and relayX_rev). These ones are typically used to power something like pneumatics. In a typical setup, you would want one of them set to 1, the other to 0, but that is really setup and use case dependent.

Next are the analog inputs, rc_ana_in. Being analog, these naturally have values rangings from 0-255, just like all the other ones discussed previously.

That pretty much covers the basics. If you want to test it, a real simple setup could just be a joystick into port 1, the tether cable between the two boards, and hook up a drive motor to pwm01 (through a victor!), and use the following code in the teleop.c file, in the Teleop(void) function:

pwm01 = p1_x;

Compile your code and upload the hex file using the ifiLoader. then power up and move the joystick - you'll like the results!

jratcliff

12-01-2008, 23:54

Thanks for the replies. The main reason I am using the VEX is so that I can experiment programming a fully running robot at home while the high-school team still has a big pile of parts on the floor.

Yes, Kevin's framework looks quite impressive!

My questions are this:

(1) Will Kevin's code run on a VEX robot? (I can answer this myself in the morning just by compiling and running it of course.)

(2) Does his default framework have, out of the box, everything you need to drive a basic frame robot around or do you have to write all of that yourself?

As I said in my first message programming, C, or MPLAB, are not the issue. I'm just trying to understand, in code, how you get from point-A to point-B to make the robot respond to inputs and outputs across the board. I found a big missing hole in the sample code provided on the VEX so I quickly got stuck there.

I will read the documentation that is included in the links.

Thanks,

John & Alex

mluckham

12-01-2008, 23:56

Another bit of information ... the PIC microcontroller and runtime environment used in FIRST hasn't changed much in the past several years (since 2004? well, a couple of years ago they changed the PIC part to a different one with more memory, and last year they changed the radio, but both run the same code at the same 10 MHz speed). The rule seems to be "incremental changes" and "don't mess with success - it only causes problems".

So assuming they don't change in years to come, information gleaned is not totally wasted. But since when does technology stand still?

Doug Leppard

13-01-2008, 00:01

John and Alex,

I cut my teeth on the same things as you did. So I know where you are coming from.

As a team we use EasyC Pro. Some will say you must use MPLAB as our team has done years before. But last year we did EasyC Pro and it takes the pain out of programming and provides what you need. Has an environment that allows kids to program. We programmed the VEX machines to work out the problems and then moved the code and concepts to the big robots.

Our team did well last year, voted in CD having best autonomous mode and made it to Einstein (if you are new that means we went to the Atlanta Championships and were one of the final 12 robots in the competition). I only say that because some look down on EasyC Pro but it lets us proto type quickly and we got results. It has a lot of built in stuff, like encoders etc and other routines that you don’t have to worry about doing and just do the core that you need to do for your team.

I would definitely look into it.

Otaku

13-01-2008, 00:09

Thanks for the replies. The main reason I am using the VEX is so that I can experiment programming a fully running robot at home while the high-school team still has a big pile of parts on the floor.

Always a good idea. You don't want to find out that the code doesn't work a few days before ship. That's never good.

I would say more, but my interests are in turning knobs and filing stuff =p sorry.

If you're the J. Ratcliff, programmer I happen to be thinking of:

My dad happens to still have his copies of 668 Attack Sub and SSN-21 Seawolf as backups on his PC, and I have MW2 in my small games collection (as well as all the other MW games, I freakin' love mechs)

(Oh, and if you hear that the team needs help with mechanical stuff, encourage somebody to register and send me a PM, I'll help them out if they want, this goes for anybody btw)

The Lucas

13-01-2008, 00:12

Quickly

(1) Will Kevin's code run on a VEX robot? (I can answer this myself in the morning just by compiling and running it of course.)
No, they are intended for FRC Robot Controllers not the VEX Controller. Most (if not all) FTC teams program in EasyC. I don't program the VEX controller myself, but I imagine most of Kevin's code examples could be easily ported by changing the controller specific setup.

(2) Does his default framework have, out of the box, everything you need to drive a basic frame robot around or do you have to write all of that yourself?

Yes, they do have a drive routines. Although, his code examples are focused more on the advanced features of the RC rather than simple drive (which is in the default code from IFI (http://ifirobotics.com/rc.shtml))

Kevin Sevcik

13-01-2008, 01:04

A lot of the basics have been covered by my colleagues here, so I'll just throw out some links and try to answer a few of your specific questions. First, you can look through the following pages for several presentations about programming and the control system in general:
[/URL]
(http://first.wpi.edu/Workshops/index.html)
[URL="http://www.usfirst.org/community/frc/content.aspx?id=482"]

Make no mistake, you will need at least a cursory knowledge of the rest of the control system to program effectively. At the very least so you'll know differences in function and purpose of the speed controllers vs. relays, etc. And you'll also be better able to tell if your program is doing something wrong or if one of the mechanical students has unkindly dumping a load of metal shavings into your the electronics.

That said, on to some of your more specific questions:
The Master source code isn't available for various reasons. I've considered doing disassembly on it out of sheer curiosity, but my brief examination of the binary files we're given to load seem to show jumps to memory areas not included in the dumps we load, so I suspect it'd be fruitless anyways. The good news is that you need to know very very little about that to program successfully. In fact, it is enough to mere know that you receive a data packet from the master every 24ms and that you HAVE to send a packet back for each of those or a watchdog on the master times out and your robot dies. The packets themselves are structs defined in one of the .h files.

All those acronyms and their uses are defined in great and painstaking detail in the PIC18F8722 datasheet and the PIC18 reference document. Luckily, you don't need to know a thing about those particular ones to have a successful robot.

Code written for in the standard Vex template would not even be source compatible with the standard FRC code. The two systems use different communication protocols between the master and user processor, primarily because of the vastly different IO peripherals and the different controllers. The variable names and aliases are also different for these reasons. You would certainly be able to replicate the algorithms between the systems, but copying code from one to another wouldn't work unless you defined some of your own aliases to map the Vex-specific variable names to FRC specific ones.

Finally, since you're an old hand at assembly and code optimization on older, slower processors, a word of warning. If you're thinking of using Fixed Point/Q-Math to speed up calculations on the PIC, be warned that bitwise right shifts are always unsigned, so if you're trying to shift signed variable, you'll either need to offset them into positive numbers or simply divide by the appropriate power of two. I imagine others on here think it odd that I often mention this, but hunting down this particular bug in some code one year was incredibly frustrating.

jratcliff

13-01-2008, 01:14

If you're the J. Ratcliff, programmer I happen to be thinking of:

My dad happens to still have his copies of 668 Attack Sub and SSN-21 Seawolf as backups on his PC, and I have MW2 in my small games collection (as well as all the other MW games, I freakin' love mechs)

Yep, that's me. Sorry to the Easy C fans but I'm definitely thrilled with MPLAB and will be using it as my primary development platform. I'm really looking forward to having fun with this in years to come. However, in the short term, our team needs to get something up and running quickly and I have no external resources to draw upon other than this forum. I'll try to contact some people in the area who have past experience next week.

To carry the conversation here further, I might ask this. Soon enough I'm going to get the code working to control the motors and such yet I imagine that the programming for robots is a bit more sophisticated than simply 'move joystick send output to motor'? How sophisticated does the code get to deal simply with motion control on the robot? I saw reference to Kevin's code regarding 'encoders', which I can imagine has uses for motion control.

What kinds of techniques and algorithms are used purely to make the 'driving around' aspect of a robot more sophisticated?

Also, I do have a programming website. (http://www.codesuppository.blogspot.com/)

It has no FRC code on it (yet) but I will be making all of my development open-source as I become more familiar with the process.

John

Kevin Sevcik

13-01-2008, 01:36

dtengineering

13-01-2008, 02:02

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

SomeoneKnows

13-01-2008, 02:10

Thanks for the replies. The main reason I am using the VEX is so that I can experiment programming a fully running robot at home while the high-school team still has a big pile of parts on the floor.

Yes much of the default code for FRC is usable with the Vex but there are a few differences. The Vex makes a great training platform. Are you using the Vex code found at this link http://www.vexlabs.com/vex-competition-programming.shtml for the Autonomous Files downloads?

(2) Does his default framework have, out of the box, everything you need to drive a basic frame robot around or do you have to write all of that yourself?

Yes, the default code will allow you to use the controller to run under radio control but you'll want to make modifications for behavior using the joysticks and any autonomous programming.

Where is the missing piece of documentation in all of this?

CCP2CON = 0x3C;
PR2 = 0xF9;
CCPR2L = 0x7F;
T2CON = 0;
T2CONbits.TMR2ON = 1;

I found definitions to these variables in the header file: ifi_picdefs.h from a download off the VexLabs web site. The file was dated 1/14/2004. They were defined as extern so may be part of the master code which is undisclosed.

The only place I'm finding references to this is from FRC code that has been commented out with the explaination that it would generate a 40KHz PWM with a 50% duty cycle...

The documentation for FIRST MPLAB programming is scattered around the Internet. Be sure to check the FIRST web site's Documents and Updates Section http://www.usfirst.org/community/frc/content.aspx?id=452 in Section 8 check the Additional Technical Resources link.

Check on the IFI Robotics web site under the Operator Interface documentation for tidbits on variables used http://www.ifirobotics.com/oi.shtml and the FRC Robot Controller page for documentation, FRC source code and supporting programs http://www.ifirobotics.com/rc.shtml.

I already mentioned the Vex Labs web site for Vex related versions.

Since you've found Chief Delphi you should check the white papers some have valuable programming information.

One last reference you may want to look at is the Microchip datasheets for the Vex's PIC18F8520 and the FRC controller's PIC 18F8722. If I have trouble finding the datasheets from official FIRST sources I get on www.digikey.com and enter the processor model number, select a processor, select the Technical/Catalog Information link to get a listing of the processors to find the datasheets. At 448 pages the PIC 18F8722 datasheet is not light reading.

I noticed you list the St. Louis area for your location, you might want to attend the local robotics club's monthly meeting next Saturday. They usually have members involved with FIRST. Their information is at www.robomo.com.

Starting to learn MPLAB programming within the 6 week build period is not an ideal situation, I learned that a couple of years ago. Having such a late start I would suggest that you give the EasyC Pro a chance. I'm not fond of their licensing scheme handicapping our programmers so I suggest our team members try programming with WPILib which is a library accessed within the MPLAB environment. Since EasyC seems to be using the WPILib you get the same functionality without the drag and drop GUI.

Yep, that's me. Sorry to the Easy C fans but I'm definitely thrilled with MPLAB and will be using it as my primary development platform.

Its great you have a Vex and are excited about participating, me too. But, as a mentor I should caution you that FIRST is not about you its about the students. They need to be able to program on a level that they can understand. Kevin Watson's code helps make that possible for some but the WPILib and EasyC are the best fit for other students.

Vince

jratcliff

13-01-2008, 02:27

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 (http://www.chiefdelphi.com/media/search/results/69501) 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 (http://www.chiefdelphi.com/media/papers/1742) 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

13-01-2008, 03:20

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 (http://www.chiefdelphi.com/forums/showthread.php?threadid=60377). 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.

pafwl

13-01-2008, 05:20

I have been doing this for 11 years now. I have given seminars on programming. You do not need to go to great detail for this. When you have time read Kevin's stuff at your lesure but for now you can put it to good use. I have several presentations you can use and as you have a background in C most of the gooey details should be pretty easy to master. You can get these at www.frc272.com.Ideas.

Good luck

pafwl

13-01-2008, 05:22

Sorry for messing up the URL in my last post. The presentations are at www.frc272.com/Ideas (Capital I in Ideas)

Sorry, fat fingers...

pafwl

13-01-2008, 05:33

PWM
Pulse Width Modulated output.(byte) Range 0-255, mid range =127. Joystick output. This applies to Speed controller via a control cable (White, red, black). This tells Speed controller how much voltage and polarity. (forward or reverse). You assign joystick value to pwm output.

pwm01 = p3_y; // left driver joystick

Relay
Separate module connected via control cable to Spike Relay controller.
Has two variables _fwd _rev. When controlling motor it will apply full power in foward or reverse.
relay1_fwd = 1;
relay1_rev = 0;

To turn it all off ...
relay1_fwd = 0;
relay1_rev = 0;

Once you compile your code you must download it to micro. Go ti IFI for loader and instructions. Ther eis a default code base that helps get you started.

ebarker

13-01-2008, 08:48

very short winded answer.

open default project;
learn user_routines.c - used for default tele operation
learn user_routines_fast.c - used for hybrid/auton operation

download several kevin.org projects, like adc and encoder
carefully READ the readme.txt in these projects. they are precise and step by step.

use something like WINDIFF and examine the differences between the kevin projects and the default project. There you will see how he incrementally added features to the default project.

I use TREECOMP and WINDIFF to do deltas on the projects. There are other tools that do the same.

This is about the fastest quickstart I can think of for an experienced programmer. I would do all of that before jumping into processor datasheets and stuff. There is a LOT of framework that is already done. All you have to do is add your algorithms and go.

jtdowney

13-01-2008, 09:22

seanwitte

13-01-2008, 11:52

Part of the acronym soup for this group is PID. It's a shorted version of proportional-integral-differential control. The idea is to use a sensor to measure an actual output, compare it to the commanded output, and adjust until they converge. I think you can get by with a proportional term only the most of the time. There are lots of samples on these forums.

You can also use the technique to move from "relative" to "absolute" position. The basic example is a servo, which moves to a fixed position based on the input command. Instead of saying "go forward" or "go backwards" you call tell it to "go to position X".

The sensors commonly used are:

1) Gyro - analog sensor measures angular velocity. By sampling at a fixed interval integrating the output you can convert the value to a relative angle (think compass).

2) Encoder - device that measures rotational distance by being physically coupled to the thing you want to measure. As the shaft rotates it outputs a series of "ticks". They have a fixed number of "ticks" per rotation. By counting the ticks you can measure distance, and by accruing the distance over time you can measure speed. A quardature encoder allows you to determine both distance AND direction.

3) Potentiometer (pot) - variable resistor that outputs an analog value relative to the position of the shaft. This is useful for measuring a joint with a fixed arc (like an arm). For the arm application you can compare the output of the pot to the commanded value and drive the motor until the two values match.

Using this stuff you can write code to make your robot drive the way you want. For a simple tank-style robot I like to break it down into two commands: forward and rotation. Using a gyro or encoders you can more closely relate your forward/rotation commands to the actual performance of the system.

Good luck!

The Lucas

13-01-2008, 12:16

Another important resource for specific hardware info is the IFI FAQ Forum
OI FAQs (http://www.ifirobotics.com/forum/viewforum.php?f=5)
RC FAQs (http://www.ifirobotics.com/forum/viewforum.php?f=6)
Victor Speed controller FAQs (http://www.ifirobotics.com/forum/viewforum.php?f=13)

In my opinion the most important of which is the Outputs Steps FAQ (http://www.ifirobotics.com/forum/viewtopic.php?t=317).

Steve_Alaniz

13-01-2008, 13:08

HAH! NOW aren't you sorry you didn't listen to your mother when she told you to stop coding, get off that computer and ...build a Circuit! (Sorry, I'm mainly a Tech Type...)
One thing I'm not sure anyone mentioned was the Dashboard Monitor.
The robot may be a pile of parts but if you can tether the Robot controller, power up the Operator Interface and using the Dashboard Program, download and At least see the effects on the PWM and buttons.
The with minimal hardware just power a relay or use a switch to see the inputs. Things like that.
You could do some simple programming while the robot is being build instead of waiting.
Hope this was a useful suggestion.

Good luck

Steve

Mauri Laitinen

13-01-2008, 15:57

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.

Steve_Alaniz

13-01-2008, 16:17

OOPS! I Meant to say... Power Up the Robot controller... the Operator Interface will get it's power from the Robot controller... My Bad.

Steve

One thing I'm not sure anyone mentioned was the Dashboard Monitor.
The robot may be a pile of parts but if you can tether the Robot controller, power up the Operator Interface and using the Dashboard Program, download and At least see the effects on the PWM and buttons.

jratcliff

13-01-2008, 17:02

Thanks all for the excellent advice. I have been reading documentation today and I think I have a handle on the flow of control now.

I did run into one weird problem, I wonder if anyone else is having. I tried downloading the latest version of the MPLAB-IDE from the microchip website and every time I download any version I get CRC errors when I try to unzip the file. Has anyone else experienced this?

To answer a few points that were raised in the thread.

(1) I am mentoring a total of six students on our FRC team in programming. I spent four hours giving them a one on one training course on Saturday; these were all Freshmen with little to no programming experience with the exception of my son.

(2) My son is really interested in taking a leadship position on the team. He has been programming for quite some time and is really excited about contributing not just this year, but in years to come. My personal goal is to give him enough experience working with the VEX robot at home that he can be much more involved on the FRC project at school. The robotics club meets frequently but with my work schedule the only time I can make available is on Saturday.

(3) The reason I am focusing on MPLAB and C, rather than Easy C, is because that is easier for me personally at this time. I'm sure the youth will have opportunities to be exposed to the Easy C paradigm at future events throughout the year. However, in the short term, it is much easier for me to just program in native C code since that is a high iteration cycle path. Yesterday I felt a bit lost in all of the acronyms but a morning of reading yet more documentation is going a long way towards getting me up to speed.

Thanks all for the help getting started, it is my hope that I will be of assistance to the general FRC community in years to come and I certainly want to help mentor students in the St. Louis area after this season has completed.

Thanks,

John & Alex

Jake M

13-01-2008, 17:31

It is true that the programming system is far too extensive to learn within six weeks. For experienced teams, that's not a problem, because in the past four years, the only changes that have been made were tweaking and debugging. For new teams, that's a different story. The only advice I can really offer is that of all the info you'll find in the documentation, you'll only ever use maybe 10% of it. IFI does take care of a LOT of stuff for you, so you don't really have to worry about it.

I've read a good deal of the documentation myself, little by little over the years, so I have a fairly good idea of what the controller is capable of, but I've never read them too far in-depth. I'd recommend the same to you, at least until the main season's over. As much as possible, use the default stuff IFI provides and utilize resources like the IFI Default Code Manual, Kevin Watson's stuff (as if that hasn't been said enough already), and particularly this site. There's always someone here knolwedgable and willing enough to answer questions, or at least show you where to find the solution. Plus, odds are someone's already asked most of your questions before.

And I agree with you on the EasyC point. When they introduced EasyC after my first two years of just straight C, I gave it a shot and found myself confused to no end. I eventually worked out a few basics, but found that it was just so much easier to use straight C, and in the end, the code produced was smaller and more efficient. Besides, C isn't the hard part of programming the FRC or FVC controller. The hard part, like you said, is integrating what you know with the hardware specifics of the PIC controller.

ShotgunNinja

13-01-2008, 18:01

...I have written a couple of best selling computer games for Electronic Arts, shipped games on numerous platforms and microprocessors, and more recently was the lead engine programmer for the massively multi player online game 'Planetside' for Sony Online Entertainment...

Sorry for getting off-topic for a sec, but A PROFESSIONAL GAME PROGRAMMER, OH MY GOD. That is my LIFELONG DREAM.

You said you've worked for Electronic Arts? What's it like, as a game programmer? I've done some fiddling around with the Source Engine code, and I am trying to get a game project off the ground. Any tips? Things to watch out for? Reasons why Wisconsin is not a good place for game programmers?

Steve_Alaniz

13-01-2008, 21:11

I went to the Microchip site and downloaded the zip file with MPLAB 8.01. No errors. I tried installing it. Also no errors and the application launched just fine. If you're getting CRC errors, I wouldn't use it. You should have gotten a Disc in the FIRST kit of parts and I'd advise finding that instead of downloading from the Microchip site. ALSO, in previous years, we were warned to only use MPLAB ver 7.20 and C18 Compiler ver 2.40. Not sure if that still applies.
Anyone else know?
Anyway, I'd really recommend using the kit of parts disc since it will have the correct version and you shouldn't have the CRC problem using that.

I looked at Easy C. last year... I agree with you. I think a program like easy C is needed, but right now, Easy C could stand a little tweaking. Just my opinion.

Steve

Thanks all for the excellent advice. I have been reading documentation today and I think I have a handle on the flow of control now.

I did run into one weird problem, I wonder if anyone else is having. I tried downloading the latest version of the MPLAB-IDE from the microchip website and every time I download any version I get CRC errors when I try to unzip the file. Has anyone else experienced this?

To answer a few points that were raised in the thread.

(1) I am mentoring a total of six students on our FRC team in programming. I spent four hours giving them a one on one training course on Saturday; these were all Freshmen with little to no programming experience with the exception of my son.

(2) My son is really interested in taking a leadship position on the team. He has been programming for quite some time and is really excited about contributing not just this year, but in years to come. My personal goal is to give him enough experience working with the VEX robot at home that he can be much more involved on the FRC project at school. The robotics club meets frequently but with my work schedule the only time I can make available is on Saturday.

(3) The reason I am focusing on MPLAB and C, rather than Easy C, is because that is easier for me personally at this time. I'm sure the youth will have opportunities to be exposed to the Easy C paradigm at future events throughout the year. However, in the short term, it is much easier for me to just program in native C code since that is a high iteration cycle path. Yesterday I felt a bit lost in all of the acronyms but a morning of reading yet more documentation is going a long way towards getting me up to speed.

Thanks all for the help getting started, it is my hope that I will be of assistance to the general FRC community in years to come and I certainly want to help mentor students in the St. Louis area after this season has completed.

Thanks,

John & Alex

Lafleur

14-01-2008, 09:37

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

kaszeta

14-01-2008, 10:13

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.

Kevin Sevcik

14-01-2008, 10:25

You should have gotten a Disc in the FIRST kit of parts and I'd advise finding that instead of downloading from the Microchip site. ALSO, in previous years, we were warned to only use MPLAB ver 7.20 and C18 Compiler ver 2.40. Not sure if that still applies.
Anyone else know?
Anyway, I'd really recommend using the kit of parts disc since it will have the correct version and you shouldn't have the CRC problem using that.
Yes we're still restricted to using MPLAB 7.20 and C18 2.4, unless you're using Kevin Watson's Beta C18 3.0+ code, which I'm not sure I'd recommend to a first time FRC programmer, as it might still have bugs and the C18 3.10 compiler is high conservative about interrupt handlers and could easily bog down your code if you're not careful. So yes, I would strongly recommend just installing the version of MPLAB off the CD in the kit. You'll need those specific versions anyways if you want to work with Vex, as Kevin W. hasn't updated the Vex starter code to be 3.10 compatible yet.

jratcliff

14-01-2008, 19:34

Yes we're still restricted to using MPLAB 7.20 and C18 2.4, unless you're using Kevin Watson's Beta C18 3.0+ code, which I'm not sure I'd recommend to a first time FRC programmer, as it might still have bugs and the C18 3.10 compiler is high conservative about interrupt handlers and could easily bog down your code if you're not careful. So yes, I would strongly recommend just installing the version of MPLAB off the CD in the kit. You'll need those specific versions anyways if you want to work with Vex, as Kevin W. hasn't updated the Vex starter code to be 3.10 compatible yet.

The CRC thing must have been a problem with my computer at home. I really would like to use Kevin's latest code framework, primarily because it is so well documented and has some improved functionality for sending PWC (?) commands. His code doesn't compile on the MPLAB that came with the robot kit that I have though.

If I don't use the version the beta version he has posted, what version am I supposed to be using? Can someone give me a link?

Right now I am up to speed programming the VEX using the sample code that comes with it. Is there completely different sample code to be used as a starting framework for the FRC controller? How can I experiment between the two systems interchangeably?

We don't have anything at school up and running to let me test code on the FRC so for the moment I am limited to the VEX system.

Thanks,

John