Subject:
|
Re: event driven vs. timing driven code...
|
Newsgroups:
|
lugnet.org.ca.rtltoronto
|
Date:
|
Sun, 19 Feb 2006 23:12:48 GMT
|
Viewed:
|
719 times
|
| |
|
|
Rob Antonishen wrote:
ing the state. Works OK, but you can still
> get stuck in undefined states...
>
>
> On the topics of video- I grabbed a quick one of my test bed crashing merrily
> into a light.
>
> <http://www.youtube.com/?v=-lBpjQepZ28>
>
> -Rob A>
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 first spin?
right now, I am working on "perfecting" code that will "square up" so
that if the bot approached than T.O. on an angle, then it will back up,
and try to get itself more centered.
lot more difficult than it seems. Im using a combo of WAIT's and other
sensors feedback.
Chris
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | 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)
|
7 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
