Re: New C18 3.0+ Compatible FRC Code
 

Using the wrong format string can cause wacky behavior. I'll have a quick look if you zip up your code and e-mail it to me.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I have a early port of your ATD code working on the board with DMA, also have the serial drivers working with a few bugs...

this was done to gain experience with the tools and processors...

Re: New C18 3.0+ Compatible FRC Code
 

There is a later theme about not allowing enough time for the circular buffer to fill. I suspect that might be what I was doing wrong.

Re: New C18 3.0+ Compatible FRC Code
 

Just wanted to post a big THANK YOU to Kevin for his code...

Re: New C18 3.0+ Compatible FRC Code
 

You're welcome :). Of the teams that used my code last week, did any bugs pop up?

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

We used it. There was one wierd issue with something that used to happen in the initialization routine not happening any more (initializing two variables to values read from the ADC), but that could be connected to me disabling the gyro code, or something else. If I can't find it after I try to look for it harder, I'll let you know.

Overall though, the code worked fantastically well.

Re: New C18 3.0+ Compatible FRC Code
 

While we did not use any of you gyro or encoder or any other fancy code, we did use your base new format. It was wonderful and easy to work with. We did not have any problems with the code itself and generally we are all very glad you made something like this. The Quick_ADC function was enough for our mast even though it was really fast (relatively). Thanks for the hard work to provide such a quality product.

Re: New C18 3.0+ Compatible FRC Code
 

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!

Re: New C18 3.0+ Compatible FRC Code
 

We tested it without issues at a local practice event. The competition port was used to control the systems.

From your description, it sound like you may be using a "While" loop.??

We did this and killed our selves. Once we realized what happened, we dropped the "While" loop and everything returned to normal.

Re: New C18 3.0+ Compatible FRC Code
 

It definitely works. We ran it at Portland.

Re: New C18 3.0+ Compatible FRC Code
 

What sort of malfunctions?

Re: New C18 3.0+ Compatible FRC Code
 

The Green power light on RC flashes slowly. On the OI, the "No Data / Radio" light flashes and "Code Error" is on solid. If I keep playing with the reset and program buttons I can get it to run normally for a while and get it into program mode.

I just looked for while loops thinking maybe I mistakenly typed it instead of an "if" statement or something, but didn't find anything. Any other ideas on what may cause this?

Thanks for the help!

Re: New C18 3.0+ Compatible FRC Code
 

I've received quite a few e-mails and PMs with positive feedback on the code (team 1024 used the code in Chicago last week and won). Two people have had problems, but one turned out to be a call to printf() inside an interrupt service routine that was quickly fixed. Tom Bottiglieri is having a weird issue with the RC occasionally throwing the red-light-of-death when it's cold booted, but it's not clear to me what is causing the problem.

If you want, you can zip up your code and send it to me for a quick look.

-Kevin


Edit: Whoops, 1024's master programmer just contacted me to point out that they used some of my other code, but not the 2008 base code.

Re: New C18 3.0+ Compatible FRC Code
 

Anything that causes your program to be slow at responding to the master processor during normal execution can cause a Code Error light (Red Light Of Death). Even an over-chatty set of printfs can cause this to occur.

If you are using interrupts for things like encoders and have too high resolution encoder (say 256 pulse per rotation) on a shaft that spins too quickly (say > 4 revolutions per second), then that encoder alone can generate >1000 interrupts per second. We use a guideline of no more than 4000 interrupts per second and very small, streamlined interrupt processing.

If you've configured a millisecond timer interrupt, then you've got 1000 per second occurring there also.

One indication that you're being a bit slow in responding to the master controller is a sluggish response to OI commands like joystick motion. That's the first indication, although you may not see it if the slow response occurs on some other event (like hitting a limit switch or turning on a motor to high speed that is being read by an encoder).

All things to think about. I hope you get it figured out!

Lynn (D) - Team Voltage 386 Software

Re: New C18 3.0+ Compatible FRC Code
 

This sounds almost like your Master Processor is messing you up, especially since you say that the battery indicator LED flashes slowly. Try to first reload the master code using a different computer, a different serial port, and redownload the code, as some information may be getting messed up. Also start fresh, preferably with IFI's code and see if you encounter the same issues. If you don't have any issues, go back to the default version of Kevin's code, if that doesn't give you issues, then load your code to see if that gives you any issues.

Basically, go through some troubleshooting steps. Go back to what you know should work, and if it doesn't, then call IFI for them to fix your RC.

Nothing that you code should mess with the indicator lights on the RC... this is what leaves me to believe that your master code is corrupted.

Re: New C18 3.0+ Compatible FRC Code
 

I'm sorry, I think my first post came across as more accusatory than I intended. Kevin, you did an awesome job with this code and your work is much appreciated. I've been using various bits of your code for years now with great success. My reason for posting was hope that someone else had encountered the same problem we hit and had a simple solution.

I'm still not sure exactly what is going on. Reloading the user program to our RC seems to briefly fix the problem, leading me to believe that this program is somehow becoming corrupt. I no longer believe Kevin's 3.0 compatible code to be contributing in any way (and I'm glad to be using it!)

Kevin, I'll still zip and send you our program.

Thanks all!

Greg

Re: New C18 3.0+ Compatible FRC Code
 

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!

Re: New C18 3.0+ Compatible FRC Code
 

This sounds real close to what I keep seeing. It usually happens in response to a change in command input, but I can't figure out exactly what triggers it.

The fix I've discovered is to re-upload the master and user code (although sometimes just re-uploading the user code works). Not sure if this is relevant to the new 3.0 compatible code, maybe we should move to a different thread?

- Greg

Re: New C18 3.0+ Compatible FRC Code
 

There's generally a lot of finger pointing in the engineering profession, so I'm used to it by now :D. In all seriousness, if someone thinks they've found a bug in my code, I'm very interested in hearing about it.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

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

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

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

As the TechnoTicks (236) programming team's mentor, I want to thank you for your great code template. We were able to accomplish a great autonomous mode by running laps with the use of encoders as well as provide for controllable mecanum drive. The traditional view is that to control mecanum drives you need velocity feedback on each wheel; I argued (and proved) that a gyro would work as well.

Our programmers used EasyC last year and graduated to using MPLab this season. Your code provided a clean and logical template for them to start. It was a lot easier teaching the new members of our team as well!

Re: New C18 3.0+ Compatible FRC Code
 

"The proof of the pudding is in the eating"

Team 709 used Kevin's new code with gyro, A/D, encoders, and two serial ports all integrated as we battled hard at the Chesapeake Regional, and that software was rock solid, baby! We also integrated your ir_sensor module after our IR board died, and it basically dropped right in. Really nice and simple approach!

Can't wait for the Philly regional!

I think the students have just picked up on the flow of the software so easily and so well, compared to previous years, I just can't thank you enough for doing this!

Re: New C18 3.0+ Compatible FRC Code
 

Hello Kevin,

I'm Veevee from team 2036 and I've been scrolling through this thread and found somebody with the same issue, but apparently they could fix it...and I still can't seem to figure this out. Our team's IR board has fried so we're trying to implement your solution to it. Yeah, this is late I know, but our team doesn't necessarily need the IR board, we just recently decided we might as well try and get it to work though if we can. I'm relatively new to programming, but here's my issue:

I'm using MPLAB v8.00 and C18 v3.10, but we still get the tmpdata/pragma error that some other people had earlier but fixed by updating...I'm decently certain everything's up to date on my machine though...:

Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\autonomous.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "autonomous.c" -fo="autonomous.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\disabled.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "disabled.c" -fo="disabled.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\ifi_code.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "ifi_code.c" -fo="ifi_code.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\ifi_frc.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "ifi_frc.c" -fo="ifi_frc.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
C:\Documents and Settings\Science\Desktop\ifi_frc\ifi_frc.c:263:War ning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\ifi_frc.c:266:Err or [1020] unexpected input following 'interrupt'
C:\Documents and Settings\Science\Desktop\ifi_frc\ifi_frc.c:392:War ning [2002] unknown pragma 'tmpdata'
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\interrupts.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "interrupts.c" -fo="interrupts.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\pwm.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "pwm.c" -fo="pwm.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "serial_ports.c" -fo="serial_ports.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:93 5:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:10 02:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:10 28:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:10 95:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:11 21:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:11 61:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:11 87:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\serial_ports.c:12 27:Warning [2002] unknown pragma 'tmpdata'
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\teleop.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "teleop.c" -fo="teleop.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\timers.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "timers.c" -fo="timers.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\encoder.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "encoder.c" -fo="encoder.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\gyro.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "gyro.c" -fo="gyro.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Make: The target "C:\Documents and Settings\Science\Desktop\ifi_frc\adc.o" is out of date.
Executing: "C:\mcc18\bin\mcc18.exe" -p=18F8722 "adc.c" -fo="adc.o" -k -mL -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
C:\Documents and Settings\Science\Desktop\ifi_frc\adc.c:387:Warning [2002] unknown pragma 'tmpdata'
C:\Documents and Settings\Science\Desktop\ifi_frc\adc.c:442:Warning [2002] unknown pragma 'tmpdata'
Skipping link step. Not all sources built successfully.
BUILD FAILED: Wed Mar 26 10:50:49 2008


None of thecode has been modified at all, I'm just trying to compile your original code so far. If you could help at all, thanks very much!

Re: New C18 3.0+ Compatible FRC Code
 

I have no idea if this will help, but can you open a command window, change directories to C:\mcc18\bin, and run "mcc18 -v"? This should confirm what version of C18 you're running, and I'm just curious if it's the right one.

Re: New C18 3.0+ Compatible FRC Code
 

Hmm...I tried reinstalling C18 v3.1 and now it seems to be working. Thanks for your help! (Last time I checked by going into the folder and clicking on the readme file for C18...and it said v3.10...perhaps it's different still though?)

Re: New C18 3.0+ Compatible FRC Code
 

Since it has to do with the 3.0+ code, I figure I'll post the question here:

quick_adc.c/h says it's incompatible with the adc.c/h code, but I think our 'bot very briefly needs the functionality. We're using a decade thumb wheel rigged as a voltage divider for an autonomous mode selector. (Delays, starting position, etc.) I really really don't want to waste 400-800 samples per second on an analog value we only need to read once after the RC initializes. Since the Quick_ADC(n) function seems just to be making a standard blocking ADC conversion, is there any reason we can't call this in our Initialization() code right before we call Initialize_ADC()? I realize the potential pitfalls with match restarts, etc., but I'll still feel silly burning that many cycles on something like this.

Re: New C18 3.0+ Compatible FRC Code
 

That is exactly what I was going to suggest. I believe it "should" work.

Although, I think an answer from Kevin would be the most prudent considering he knows his code inside and out.:)