problem with autonomous that has stumped all programmers so far

[Ryan M.]

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.

[jacob_dilles]

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

[deltacoder1020]

Originally Posted by jacob_dilles

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

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.

[Larry Barello]

Originally Posted by deltacoder1020

nice catch, Ken. the code this is based off of is an example that I posted on the forums here: http://www.chiefdelphi.com/forums/sh...d.php?p=233912

the problem is that for any time period larger than about 3 seconds, 10000*a is greater than the max limit for a plain "int", and thus it's either wrapping around or just mucking stuff up.
...

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!

[deltacoder1020]

Originally Posted by Larry Barello

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!

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.

[jacob_dilles]

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

[deltacoder1020]

Originally Posted by jacob_dilles

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

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

[KenWittlief]

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.

[deltacoder1020]

Originally Posted by KenWittlief

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.

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.

[KevinB]

Originally Posted by deltacoder1020

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 :/

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

[deltacoder1020]

Originally Posted by KevinB

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

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

[Greg Ross]

Originally Posted by KenWittlief

if the only thing you changed was adding this stuff:

SECS_TO_TICKS(a) ( ((int)(a)) * 10000 / 262 )

then maybe its not doing what you think it is?

int is signed, isnt it? so if a = 4 you end up with 40,000 which is a negative number divide by 262?

if this is what you changed and it got weird on you, just work with the tick counts in your code forget the fancy translations.

also could try running with a few printf statements and see what is happening at the start and end of each state - there might be something weird going on.

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.

[Daniel]

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!

[bd02]

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!

[Ryan M.]

Originally Posted by Daniel

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!

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.