Re: New C18 3.0+ Compatible FRC Code
 

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.

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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.

Re: New C18 3.0+ Compatible FRC Code
 

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! :ahh:)

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!

Re: New C18 3.0+ Compatible FRC Code
 

Cool! Thanks for letting me know.

You're welcome.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

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!

Re: New C18 3.0+ Compatible FRC Code
 

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:

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

... 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?

Re: New C18 3.0+ Compatible FRC Code
 

We ran your code successfully at the San Diego regional.

Re: New C18 3.0+ Compatible FRC Code
 

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.

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

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

Re: New C18 3.0+ Compatible FRC Code
 

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?

Re: New C18 3.0+ Compatible FRC Code
 

This is a uncommon but great experience.:D