Re: problem with autonomous that has stumped all programmers so far
 

If your program is storing its state in a variable, the variable is not reset until the robot is reset. Hit the "robot reset" button on the OI, not the one on the RC. This should solve the problem. Hope that it does. :)

Re: problem with autonomous that has stumped all programmers so far
 

WOW i didnt even see that. okay but before you go basing all of your code off 26.6 ms, do a search on CD. it turns out that ( if i understand correctly ) each cycle IS NOT 26.6 ms, and that it varies depending on what code is executed. it is a MAX of 26.6 ms. so use something more concrete. like a timer inturupt. or a wheel counter. if your redoing all of your electronics, you might as well

Re: problem with autonomous that has stumped all programmers so far
 

actually, reports from various people i've talked to have said that NEW_SPI_DATA gets reset fairly regularly on a 26.2ms basis, because it is the master processor that is timing these updates. because there is no external code running during autonomous mode (unless you added some), chances are fairly good that the flag will be detected quite close to the ms mark. so it should work fairly well for most teams' needs. but yes, if you feel that you need the extra precision and have the programmers to do it, feel free to go down other paths. as I stated when I posted the code, this is for teams that don't really have the programming resources to get really into coding, but do want to experiment some and design a decent autonomous mode.


--edit--

also, let me explain my reasoning for not including a in-code reset for the autonomous mode timer variables. if, for some reason or other, the robot controller got a garbled packet that somehow made it though and set autonomous_mode to 0 for a cycle, i did not want a random team having to watch as their robot restarted its autonomous mode in the middle of the field :/ I felt that it was simpler to have the robot remember where it was, seeing as (as someone already mentioned) one can hit the reset button and have it ready to go again. It's a matter of personal preference, feel free to zero them out if you wish.

Re: problem with autonomous that has stumped all programmers so far
 

The easy fix is to use ((unsigned int)(a)) instead of int. you will never need negative time, so why specify a signed number?

Cheers!

Re: problem with autonomous that has stumped all programmers so far
 

making it unsigned only doubles the amount of space you have - anything over 6.5 seconds or so will still overflow it, hence the reason i recommend using longs.

Re: problem with autonomous that has stumped all programmers so far
 

unsigned long.... comon guys its got plenty of ram

Re: problem with autonomous that has stumped all programmers so far
 

unsigned vs. signed doesn't affect the amount of space the variable takes up - use what you want, i highly doubt you'll need the double capacity of an unsigned long vs. a regular long

Re: problem with autonomous that has stumped all programmers so far
 

easiest fix is to divide it out and multiply the number of seconds you want by 38 - thats what Im doing in my code, assuming 38 cycles per second

and since we are all tweaking this by observing the machine on the field, and nudging the numbers a little, it doenst really matter if your seconds are lockstep with the National Beuro of Standards in Bolder Colorado

or better yet, forget seconds and work in loop counts - one less thing to worry about.

Re: problem with autonomous that has stumped all programmers so far
 

the thing about multiplying by 38 is if you need partial seconds - floating point math is slow. working in raw loop cycles in fine, i just wanted to give less experienced teams other options. :) replacing int with long shouldn't be that hard.

Re: problem with autonomous that has stumped all programmers so far
 

The Radio Modems perform checksum calculation on the data packets. Although possible, its unlikely that a "garbled packet" would ever get through.

Re: problem with autonomous that has stumped all programmers so far
 

so call me paranoid. mcc18 hasn't made me any less so. *grumble*

Re: problem with autonomous that has stumped all programmers so far
 

I zeroed in on this line at first too, but then when I looked at where the macro is used, the only argument ever passed to it is 3, which should not cause a problem, so I kept looking.

Re: problem with autonomous that has stumped all programmers so far
 

I've only had a robot to test with for 8 days and 7 of them I have been chasing a problem like the initial message had. That is, you do a printf, a calcualtion and another printf - and the second printf never appears!!!

I'm beginning to believe that my problem is using "long" integers. Something in that compiler is weird.

Any body else had this experience? Did youfind a solution?

I have too many lines of code - so rewriting them is impossible. So much code to debug, so little time!

Re: problem with autonomous that has stumped all programmers so far
 

Sorry it took so long for me to get bak to you all. The code is working now and we should be fine once we get to Atlanta, thanx for all your help people! :)

Re: problem with autonomous that has stumped all programmers so far
 

In the second printf(), are you printing anything other than just a value? Meaning, is there a constant string in there some place? The printf() that is implemented is fairly limited in the format identifiers it can handle and if it encounters one that it doesn't recognize, it ignores it, printing nothing out in its place. If there is a string you can verify it is actually being called.