Subject:
|
FSMs, coding techniques and other goodies
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Mon, 13 Dec 1999 08:49:52 GMT
|
Viewed:
|
1310 times
|
| |
|
|
Hi all!
I know that multitasking is reducing the need for using FSMs, but in my case
the tasks ended being smaller FSMs after all, and because some parts were
overlapping - why not use a single large FSM? [maybe it is my own fault that
FSMs appear as often in my code! a mental block or something...]
There is a note I'd like to make about that. When I say "FSM" it is a
generalized one, not like the one I learned about in school (ie with everything
coded as integers and a large table containing the data). For the first, that
approach won't work very well with so little data memory (more about that
later). Then it isn't easy to read and modify. And it's not as flexible.
My idea is quite close to using macros, but that tends to be ugly, so by using
a preprocessor a better suited description language can be used. Reading the
FSM and understanding it would be easier from the code, even if the state
transition diagrams won't ever get useless.
Returning to the lack of data memory in the standard firmware, this led me to a
'revelation'. Maybe it is stating the obvious, but I will share it anyway :)
The coding technique used in NQC must be different than that with regular C
(for example). With the latter, one is encouraged to use table-based
computations; but here we have not enough memory, so the opposite approach must
be used: move as much as possible in the code! From the 6k available, I would
happily trade 1k for the equivalent of some 32 more variables (but I guess the
real trade-off is not that bad).
The downside is that when cluttering the code with such more or less artificial
constructs, it becomes harder to read. Commenting helps, but I think it is
better to build a higher-level language where the structure is obvious. For
FSMs it certainly works. I have not tested for neural networks, but I think it
might be possible to get 6-8 neurons at least (compared to 2-3).
Here comes a simple example, a line-following FSM like the one in the
"Unofficial Guide" (written here from memory, so it might be wrong, but that's
not important here)
state START
// OnEnter action
Forward;
begin
// condition-or-event -> action
(SENSOR_2 > DARK) -> { goto TURN; }
true -> { /* do nothing */ }
end;
state TURN
StartTimer(TIME);
TurnLeft;
begin
SENSOR_2 < DARK -> { goto START; }
TimerElapsed -> { goto TIMEOUT; }
end;
state TIMEOUT
TurnRight;
begin
SENSOR_2 < DARK -> { goto START; }
end.
To me it looks like much clearer than the equivalent if-else or case construct.
Cheers
/Vlad
|
|
Message has 2 Replies:
 | | Re: FSMs, coding techniques and other goodies
|
| Vlad, why don't you write a graphical FSM generator? Textbook FSMs are quite powerful, but in practice, states and transitions are usually augmented with enter/hold/leave actions. This provides plenty of configuration potential. Also, there's a (...) (25 years ago, 14-Dec-99, to lugnet.robotics.rcx)
|
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
