Quote:
|
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.