New C18 3.0+ Compatible FRC Code

[jleibs]

Ok, I have a question (more of a comment really), but I was hoping someone could either verify my understanding, or explain what I'm missing.

It seems the current gyro code as well as some things others have mentioned depend on putting processing code inside one of the Spin functions.

Generally speaking, the spin function will be executed at a very high rate (essentially only processor-limited). However, at roughly 38Hz, the spin function is going to get delayed by however long it takes to run your general execution code, e.g., Teleop(). If this code is simple and runs quickly, this isn't likely to be too much of a problem.

However, there is still going to be some delay associated with this code, let's call it T_d. Now, the frequency, 1/T_d is going to be important because it's actually the maximum frequency we can count on our spin function to run at over any arbitrary time interval.

Right now it looks like we are processing our Gyro at 50Hz? (800Hz / 16 samples per update). This means we need to make sure that T_d < 20ms or else we will occasionally miss gyro samples.

I agree that if T_d is pushing 20ms, you're probably going to have other problems since that's a lot of computation going on. I mostly wanted to clarify this in the case someone was thinking about trying to sample an analog signal at a data rate higher than 1/T_d (probably somewhere in the 800Hz - 6400Hz range), and still do the processing in the spin loop. In this case they might start seeing data go missing every once in a while.

I guess my question then is why do we count on the spin code to do our processing since it's timing seems potentially sporadic. Wouldn't it be better to just do the gyro processing in the ISR alongside the analog-to-digital conversion? Then we would have high-frequency reliable processing of the gyro (or whatever other analog sensor we are processing), without having to worry about anything other than keeping our Teleop() execution time a decent amount under the theoretical limit of 26 ms.

[Kevin Watson]

Originally Posted by jleibs

Right now it looks like we are processing our Gyro at 50Hz? (800Hz / 16 samples per update). This means we need to make sure that T_d < 20ms or else we will occasionally miss gyro samples.

Your average does need to be less than 20ms over time, but it's 40ms before you actually miss data.

Originally Posted by jleibs

I agree that if T_d is pushing 20ms, you're probably going to have other problems since that's a lot of computation going on.

Agreed. If the execution rate is somewhere between five and ten million instructions per second, you can, on average, execute somewhere between 100,000 and 200,000 instructions per Teleop() loop even with the ISR overhead. If you're trying to execute 100,000 instructions in the Teleop() loop, missing an occasional ADC update is the least of your problems. I didn't point this out in the documentation, but you can determine if you're dropping data by testing the value returned by Get_ADC_Result_Count(). If it's two or greater, you're dropping data.

Originally Posted by jleibs

I mostly wanted to clarify this in the case someone was thinking about trying to sample an analog signal at a data rate higher than 1/T_d (probably somewhere in the 800Hz - 6400Hz range), and still do the processing in the spin loop. In this case they might start seeing data go missing every once in a while.

As I've stated elsewhere, I test the code with the ADC running at 6400Hz/4 samples per update, one encoder generating several hundred interrupts per second, several printfs generating a lot of telemetry in the Teleop() loop and as far as I can tell, everything works just fine (with the old 2.4 compiler I do see an occasional corrupted telemetry packet for reasons I don't fully understand; code generated with the 3.1 compiler doesn't have this problem).

Originally Posted by jleibs

I guess my question then is why do we count on the spin code to do our processing since it's timing seems potentially sporadic.

Like I said above, I think (er, hope ) it's a non-problem.

Originally Posted by jleibs

Wouldn't it be better to just do the gyro processing in the ISR alongside the analog-to-digital conversion?

This is how my code worked originally. The downside is that it's a lot of code to execute in a ISR and the ADC was dedicated to the gyro and nothing else could be sampled. After getting many requests, I split the ADC code away from the gyro code and provided a API to the ADC so that other sensors can be used alongside the gyro.

-Kevin

[jleibs]

Thanks for the response Kevin. Sounds like my fear (and interpretation of the code) was mostly right, but as I was hoping, also completely unjustified

This looks like a great set of code and I'm very excited about getting a chance to play with it soon -- things have come a long ways from where they were in 2002... I think we were screwing around with PBASIC back then.

I'm missing most of the competition, but I'll be hanging around my old team for their last week and a half or so. Plenty of time for last-minute debugging of the software.

Kind of funny... doesn't seem to matter what robotics project I'm helping out with: DARPA Grand Challenge, or FIRST robotics... Kevin Watson manages to be involved and giving advice

[Kevin Watson]

Originally Posted by jleibs

This looks like a great set of code and I'm very excited about getting a chance to play with it soon -- things have come a long ways from where they were in 2002... I think we were screwing around with PBASIC back then.

After a bit of tuning, you can get fairly spectacular results with the robot controller. As an example, I have a Silicon Sensing Systems' CRS03-02 gyro attached to a servo which is programmed to rotate such that the gyro will always point in the same direction (here's a low quality movie of it in action). Anyway, the cool part is that it ran for nearly two hours today and the gyro only drifted a maximum of two degrees over that period. It's kinda neat.

Originally Posted by jleibs

Kind of funny... doesn't seem to matter what robotics project I'm helping out with: DARPA Grand Challenge, or FIRST robotics... Kevin Watson manages to be involved and giving advice

Hey, say hi to your Dad for me. We had a nice discussion at the San Jose regional a few years ago <grin>.

-Kevin

[Jon236]

Kevin,

Upgraded to the final 3.0 version....now I get a RLOD with just 1 encoder enabled.....what can produce this condition?

[Kevin Watson]

Originally Posted by Jon236

Kevin,

Upgraded to the final 3.0 version....now I get a RLOD with just 1 encoder enabled.....what can produce this condition?

Did you enable the ISR in ifi_frc.h?

-Kevin

[Jon236]

Originally Posted by Kevin Watson

Did you enable the ISR in ifi_frc.h?

-Kevin

Nope.....I knew we were missing something!

Thanx!

[Guy Davidson]

Originally Posted by Jon236

Kevin,

Upgraded to the final 3.0 version....now I get a RLOD with just 1 encoder enabled.....what can produce this condition?

Yeah, we got this same issue today when enabling another encoder. Maybe a comment next to the #define ENABLE_ENCODER_# is in order to remind people to enable the ISR in ifi_frc.h?

[comphappy]

I must be missing something simple. I am using your code that is a couple of versions back, and when i enable the gyro code, all i get is this:

Gyro Bias=-1
Gyro Rate=0
Gyro Angle=0

after it has initialized
I then pulled your most recent code enabled the adc and the gyro in both spin and teleop the code compiles correctly, but soon as i load it, i get a code error.

[Kevin Watson]

Originally Posted by comphappy

I must be missing something simple. I am using your code that is a couple of versions back, and when i enable the gyro code, all i get is this:

Gyro Bias=-1
Gyro Rate=0
Gyro Angle=0

after it has initialized
I then pulled your most recent code enabled the adc and the gyro in both spin and teleop the code compiles correctly, but soon as i load it, i get a code error.

Did you follow the instructions in readme.txt step by step?

-Kevin

[comphappy]

I got my code to work, there was an ifdef that i had written that blocked out part of the init, but the new code still fails to load.

[Kevin Watson]

Originally Posted by comphappy

I got my code to work, there was an ifdef that i had written that blocked out part of the init, but the new code still fails to load.

Can you send me your code?

-Kevin

[comphappy]

The code that I cannot get to load is the code off of your webpage 1/20/08 both with and without the gyro enabled
My code based off of the older version is working fine.

[Kevin Watson]

Originally Posted by comphappy

The code that I cannot get to load is the code off of your webpage 1/20/08 both with and without the gyro enabled
My code based off of the older version is working fine.

When you say "I cannot get to load is the code..." are you getting the red-light-of-death, the LEDs are green, but nothing happens, or is it just not compiling?

Make sure you're performing all the steps documented in readme.txt.

-Kevin

[comphappy]

Red light of death. Code compiles fine. I then go into programming mode open the loader give it the hex file and it attempts of load. The file is loaded in, but the code error light stays solid, reset, same thing. It is not really an issue for me, as I am sticking with the old code (early version of the v3 compiler), but I do not quite get what is going on. Do you want the hex file that i generate?