New C18 3.0+ Compatible FRC Code

[Manoel]

Originally Posted by LordRed

Was your battery fully charged at the time of the error?

Now that you mention it, the battery was at 8.2 V

No, really, we always had a charged battery and the 8.2V bug never appeared to us.

[Kevin Watson]

Originally Posted by gwt8641

Can anyone confirm that this code works when interfaced to the competition control?

I ran this code, compiled with the 3.0 compiler, with no issues prior to competition. During our first practice match at the Finger Lakes competition, the "code error" light came on and we have encountered a number of very strange issues with our team's RC since. These malfunctions disappear for a short while after reloading the "master code", but keep coming back.

Any ideas? It very well might not even be related to Kevin's libraries... but the default .hex file from IFI seems to work, so I'm stumped. I can't even find a 2.4 version of the compiler, so I hope to make this work.

Thanks!

Looking at your code... You've got a lot of calls to printf() that could very well be causing problems. While my serial port driver is fully buffered and non-blocking, if the buffer fills up, the code will have to resort to a blocking scheme to prevent data corruption. In blocking mode, your code won't execute until there is enough room in the Rx buffer for the string you're trying to send. A few things to consider doing:

1) Use the DEBUG() macro (see ifi_frc.h) so that it's easy to remove the printf() statements from your competition code.

2) You can also redirect the output to go nowhere by placing this line in teleop.c/Initialization:

stdout_serial_port = NUL;

This will prevent the stalling, but isn't optimal because the code associated with printf() will still execute.

3) Increase the RX1 buffer size in serial_ports.h to 64 or even 128 bytes.

I've also seen a few inconsistances in your code. Can you describe the 'bot a bit? I'm mostly interested in the sensors you're using and how they're attached to the robot controller.

-Kevin

[gwt8641]

Our issue was a bad RC. We swapped a loaner in this morning and everything has worked fine since. Our inability to reproduce the error made it really hard to diagnose, but we finally traced the problem to cold booting the RC (cold booting was causing the program to become corrupted).

Kevin - Thanks for taking the time to look at our code We're now running a kit gyro with your gyro driver and a pot (which is used to control the direction our steerable front wheels are pointed).

Thanks for the help everyone, and watch out for defective RC's.

[Ken Streeter]

Originally Posted by Kevin Watson

Of the teams that used my code last week, did any bugs pop up?

We used Kevin's code at the Week 1 BAE Systems Granite State Regional, and had no bugs at all pop up in Kevin's code! (Wish we could say the same for our code! )

We used Kevin's beta 3.0+ code (as of 2 Feb 2008) with the following features / modules:

• ADC usage to periodically sample absolute magnetic encoders on our primary drive wheels
• ADC usage to periodically sample absolute magnetic encoders for steering position on our "Speed Racer" robot configuration
• ADC usage to periodically sample a multi-turn potentiometer on our arm for our hurdling robot configuration ("Fezzik")
• Gyro usage for current heading on both robot configurations
• Our own "fast loop" at 100Hz running in Autonomous_Spin and Teleop_Spin for increased PID responsiveness, using a timer, as suggested by Kevin in another thread

All of the above worked beautifully! Autonomous modes on both robot configurations behaved very well, and we never had any troubles that we can attribute to Kevin's code. (We did, of course, have our share of problems, including tracking down a flaky magnetic encoder, our own bugs in our own code, and an IR board that lost its programming before our last qualifying match.)

Thanks, Kevin, for all of your work on the "new and improved" FRC code!

[Kevin Watson]

Originally Posted by Ken Streeter

We used Kevin's code at the Week 1 BAE Systems Granite State Regional, and had no bugs at all pop up in Kevin's code!

Cool! Thanks for letting me know.

Originally Posted by Ken Streeter

Thanks, Kevin, for all of your work on the "new and improved" FRC code!

You're welcome.

-Kevin

[BotnEyedJoe]

This new code is a wonderful improvement. I especially like its straightforward approach, and simplified way of inserting mission-specific code. It has been a joy to use. But there's still something I'm trying to figure out about it, so if anyone can help, I'd be grateful...

It started with trying to figure out something unexpected which happens when we hold down the "Disable" button on our competition port dongle while booting the RC. In the function main() in ifi_frc.c, the one-time initializations occur of couse, and the "while (TRUE)" loop is entered, but to our surprise, we see "Teleop_Init()" execute, where we would have expected "Disabled_Init()" to be chosen instead.

Now the first thing inside the "while (TRUE)" loop is the test "if (disabled_mode)...", where disabled_mode is a field inside rxdata. But I don't see where rxdata has been set at this point. It appears to be set later on through calls to Getdata(&rxdata), once statusflag.NEW_SPI_DATA becomes 1.

Could someone enlighten me as to what I'm missing about the initialization of rxdata, specifically fields disabled_mode and autonomous_mode? Or is this, like, maybe a problem?

If you've read this far, thanks, but while we are in this vicinity, I also have a question about "statusflag.NEW_SPI_DATA", which before the "while (TRUE)" loop is set to 0. I assume it is really "volatile" even though I can't find that in any of its declarations (again I'm missing something?), but if it isn't 1 by the time we go through that loop the first time, wouldn't a _Spin() function be called before its corresponding _Init()? Is there some mechanism preventing this, or do we need to take this possibility into account in programming the _Spin() functions?

Anyway and everyway possible, Kudos to Kevin, he has made our world more enjoyable through his efforts!

[Kevin Watson]

Originally Posted by BotnEyedJoe

It started with trying to figure out something unexpected which happens when we hold down the "Disable" button on our competition port dongle while booting the RC. In the function main() in ifi_frc.c, the one-time initializations occur of couse, and the "while (TRUE)" loop is entered, but to our surprise, we see "Teleop_Init()" execute, where we would have expected "Disabled_Init()" to be chosen instead.

The problem is that the main loop is entered before the master processor has sent the first packet, and because neither the disabled or autonomous bits are set, the software first enters teleoperation mode. One quick way to get the behavior you describe would be to modify the code in main() to wait for the first packet before dumping into the while(TRUE) loop. Something like this should work:

statusflag.NEW_SPI_DATA =0;
 
while(statusflag.NEW_SPI_DATA ==0);
 
while(TRUE)

-Kevin

[BotnEyedJoe]

... And, once NEW_SPI_DATA becomes set, is a Getdata() call also needed, so that disabled_mode and autonomous_mode become set based on the contents of the newly-arrived packet?

[Joe Ross]

We ran your code successfully at the San Diego regional.

[Lafleur]

Kevin...

Team 812, The Midnight Mechanics from the Preuss School at UCSD used you code as the basis of there robot for the San Diego regionals and the team received the Chairman's Award.

Thank you very much for your contribution to the First Robotics Program.

[rdaugherty]

Kevin,
Just to add to the positive feedback, team 435 used your new code this year. (I think we are at least one version behind.) We had no problems which you have not already fixed. In addition to the base 3.0+ compatible code, we also used the EEPROM, tracking menu, and portions of the robot.c code from previous years.

The structure and starting sensor code has clearly been a great boon to the team's development of both teleop and automonous code.

So please take this as another great big thank you from another appreciative team.


Rich Daugherty
Programming Mentor - Team 435 RoboDogs
SE Raleigh High School - Raleigh, NC

[Kevin Watson]

Originally Posted by BotnEyedJoe

... And, once NEW_SPI_DATA becomes set, is a Getdata() call also needed, so that disabled_mode and autonomous_mode become set based on the contents of the newly-arrived packet?

Yes, I forgot to include that little detail <sheepish grin>.

-Kevin

[XXShadowXX]

does anyone know a site were i don't have 2 download anything to see the new code, because im at school and they won't let me save the kind of files that r posted on kevin

thnxs in advance


if you know the site just message me

thnxs again

[Manoel]

Originally Posted by Manoel

I've had the exact same problem you described, except I was using a competition dongle (practice time at home). The problem only happened three times, two with the flashing code error light. The other time, code error turned on steady and only a cold boot would fix it (resetting didn't do a thing).

The problem appeared to happen when we clicked the "set arm position" button, but all that does is change a variable's value, the function that sets it gets called every slow loop regardless of a button press. I couldn't replicate the problem in any way, I just noticed that it coincidentally happened when we pressed one of those buttons.

There's nothing too slow in my code (absolutely no for/while loops, only a few printfs, two 8 CPR home-made encoders and two analog channels reading - that's the heaviest section) and most of it is standard Kevin code. My "fix" to the steady code error light was a Master processor reprogramming (and updating the user code with the same code that was running before), and I haven't been able to replicate the problem. I didn't even think it was a big deal, but now that you may have the same problem there could be something wrong (and if there is, it's probably in this sequence: our code -> our RC hardware -> the PIC silicon -> Kevin's code )

Hopefully it went away, but, once again, it was too sporadical to know for sure.

Kevin, I can send you my code if you want, but I really don't think there's anything wrong with it.
Once again thanks for writing it!

Well, we were able to track down this problem today (on a regional practice day, what were the odds!). We have a custom made encoder in our robot and the perforated disk was in a position such that, in rare ocasions, it would trigger the IR receiver on and off continuously. That was generating several thousand interrupts per second and bogging the processor down. The problem only ocurred on a very specific position of the encoder, explaining why it was so intermittent (looking almost random).

In the end, it wasn't my code's fault, neither Kevin's (obviously ). Great when you can blame the other guy for the hardware, heh?

[SL8]

In the end, it wasn't my code's fault, neither Kevin's (obviously ). Great when you can blame the other guy for the hardware, heh?

This is a uncommon but great experience.