 | | my test platform.
|
|
Short video of my seeking. (URL) (1) (its 4.5 meg - taken with a cheap labview web cam. ) right now, I have a few things I need to over come. 1. Work on "squaring" up when bot finds T.O. on an angle. 2. make unit faster by getting rid of worm/24 (...) (21 years ago, 19-Feb-06, to lugnet.org.ca.rtltoronto)
|
| |
| | Re: event driven vs. timing driven code...
|
|
Rob Antonishen wrote: ing the state. Works OK, but you can still (...) COOL!!!! i might just have to do a short video myself. it would seem that the "spin" idea works well. Rob, do you have other code that keeps it looking for the light after your (...) (21 years ago, 19-Feb-06, to lugnet.org.ca.rtltoronto)
|
| |
| | Re: event driven vs. timing driven code...
|
|
(...) When using events I tend to use a state model, and use the events to switch the state. So my main loop is: repeat forever if state 1 do stuff if state 2 do stuff if state 3 do stuff and then have eternal tasks defining the state. Works OK, but (...) (21 years ago, 19-Feb-06, to lugnet.org.ca.rtltoronto, FTX)
|
| |
| | Re: event driven vs. timing driven code...
|
|
(...) Welcome to MY world! thats how I have programed MOST of my bots, and THATS the number one thing that bites me in the A..... arm. you just CANT think of all the scenarios. This is going to be a GREAT game. (...) i am so impressed with your seek (...) (21 years ago, 18-Feb-06, to lugnet.org.ca.rtltoronto)
|
| |
| | event driven vs. timing driven code...
|
|
K, most of my codeing for every competition has been based mostly on timing--sure I had a few events, such as touch sensors and light sensors and such, but when touch sensors were pressed, the code was to back up for x seconds, rotate for x seconds, (...) (21 years ago, 17-Feb-06, to lugnet.org.ca.rtltoronto)
|
