 | | 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 (...) (19 years ago, 19-Feb-06, to lugnet.org.ca.rtltoronto, FTX)
|
| |
| | 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 (...) (19 years ago, 19-Feb-06, to lugnet.org.ca.rtltoronto)
|
| |
| | Re: event driven vs. timing driven code...
|
|
(...) Yep Chris - it is a basic line follower type routine, with the only sneaky thing being that it always looks for the light staying the same or getting brighter (as it gets closer). If it looses the light in its FOV then it will reset an go back (...) (19 years ago, 20-Feb-06, to lugnet.org.ca.rtltoronto)
|
| |
| | Re: event driven vs. timing driven code...
|
|
In lugnet.org.ca.rtltoronto, Rob Antonishen wrote: <snip> (...) That's a beautiful vid! I think this is gonna be a great competition... (19 years ago, 20-Feb-06, to lugnet.org.ca.rtltoronto, FTX)
|
| |
| | Re: event driven vs. timing driven code...
|
|
(...) You know, I'm man enough to eat my words from before...I am looking forward to this too. I spent a lot of the weekend working on my "you come to me, I'm lazy" robot. Prompted primarily by my friend Sacha, who wrote all the software for it. (...) (19 years ago, 20-Feb-06, to lugnet.org.ca.rtltoronto, FTX)
|
