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

[mluckham]

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?

[jtdowney]

Originally Posted by mluckham

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?

It has been rumored this is the last year for the current architecture. Now what exactly will change is anyones guess.

[seanwitte]

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]

Another important resource for specific hardware info is the IFI FAQ Forum
OI FAQs
RC FAQs
Victor Speed controller FAQs

In my opinion the most important of which is the Outputs Steps FAQ.

[Steve_Alaniz]

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

[Steve_Alaniz]

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

Originally Posted by Steve_Alaniz

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]

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]

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.

[Steve_Alaniz]

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

Originally Posted by jratcliff

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

[Kevin Sevcik]

Originally Posted by Steve_Alaniz

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]

Originally Posted by Kevin Sevcik

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