Re: [SeattleRobotics] Coin Toss Post Mortem
- Hi Tom
That is probably the best wrap up of a topic I have ever read. I agree totally. Thanks for the summary.
----- Original Message -----
From: Tom Capon
Sent: Friday, June 01, 2007 2:21 PM
Subject: Re: [SeattleRobotics] Coin Toss Post Mortem
Perhaps I'm being too simplistic in looking at things, but I've felt all
along that the arguments taking place in this discussion are relatively moot
points in the long run. Here's why:
- Many (if not most) problems can be conceivable decomposed into either
hierarchical declarative code (C-style) or into a number of networked FSMs.
In some cases, the FSM implementation may not be the most efficient, nor is
its logic necessarily obvious to a hardened C programmer, but to someone
familiar with a well-written FSM-based language it is a perfectly
satisfactory solution. There are still problems for FSMs are by far the
best (if not the only) solution, and as such are implemented in other
languages either implicitly or explicitly, but given a good development tool
they can be applied beyond that.
- That said, there no doubt still exist problems that cannot be completely
tackled by simple FSM structures. But simply because a language is
FSM-centered does not mean it cannot be adapted to do things which don't
fall directly into the textbook definition of an FSM. Randy mentioned
features that effectively make IsoMax a real-time operating system, allowing
multiple FSMs to run at the same time, and provide user interaction for
development purposes. I would be surprised if it were not possible to do
creative and unconventional things with the tools IsoMax provides. Just as
it was pointed out with C, if a language is flexible enough, it can be
warped into doing things for which it was never intended, and in the process
gain longevity in many different applications. It is possible that the
features of IsoMax allow it to be "warped" into doing things a traditional
FSM would never dream of doing. But you can still debate its relative
efficiency in this mode of operation.
- Finally, the way I see it, and as evidenced by Randy's examples, an awful
lot of robot behavior of the type we typically deal with can be directly
state-mapped. It's true that I would never want to write a
vision-processing algorithm based solely on FSMs, but then again, I wouldn't
really want to write it on anything but a fully-fledged PC, and that is not
IsoMax's primary target. Most of the embedded software I write could be
done using a nest of FSMs, and very often it turns out that way, though in a
sort of jury-rigged way. Very likely, these programs would be easier for me
to debug if their state machines were more formally constructed, as IsoMax
would allow. But at the moment I don't have time to invest in learning a
new development tool.
In conclusion, I really don't see what you guys are arguing about ;-) not
to say I haven't enjoyed reading the discussion, much to learn (having not
had any formal programming training). I can easily understand where Randy
is coming from, that most if not all problems can be converted into state
machines somehow, but also that many people prefer to stick with their
language of choice and only use state machines explicitly when necessary.
I hope this post is a constructive addition to the discussion.
On 5/31/07, Randy M. Dumse <rmd@...> wrote:
> PeterBalch wrote: Tuesday, May 29, 2007 10:51 AM
> > Maybe I should study the ServoPod docs too.
> Probably not, very little difference between IsoPod(TM) and
> ServoPod(TM) except more memory and A/D channels.
> > Firstly, you can convert a Haskell program into a FSM by
> > connecting it's output back to its input but with a "latch".
> I was unaware of Haskell program issues, but yes, the adding the
> latch and a feedback loop sounds very much like a FSM. For
> instance, the simplest FSM in hardware is a latch, and it is two
> gates (usually NANDs) interlaced with feedback.
> > A week later, I was talking to Loius Natanson who has also
> > done research in functional programming and language design.
> > If you want to find a big FSM, look at those used in
> > compilers for the lexical analyser and syntax analyser.
> > They're probably the biggest FSMs around.
> Yes, I would agree. Compilers, string recognizers and
> translators, etc., which work on some protocol are often
> diagrammed as state machines. They tend to be a little different
> from the real time programs, because the machine runs on arrival
> of each character. The output doesn't change if the characters
> are buffered and translated at a later time (again showing
> non-realtime nature) and the machines are often rather boring,
> because they progress along a string until something doesn't
> match, and branch back to waiting for input. But they often are
> very large diagrams. People wouldn't bother diagraming them as
> FSM's if there wasn't some utility in recognizing the structure
> in their visual representation.
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
- Ed Okerson responded: Thursday, June 07, 2007 2:59 PM
> OK, but did you continue watching as it evolved, or did you'83? I remember being asked about it in an interview in '78.
> just decide you didn't like it in 1983 and went off to do
> something else?
What concerned me most was what was wrong with it, and it took
me until 1984 to really understand what you couldn't do with it,
although everyone said there wasn't anything that couldn't be
done. A retreat to a multitasker was just another kind of goto.
A hidden one. A context switch is still a goto, a big fancy one,
but a goto none the less.
> Fair enough, so we need some education to teach C programmersIf you can only imagine C programmers need better state
> how to write better state machines.
machines, then yes, C programmers need better state machines.
For the rest of the world, including guys working in assembler,
some of them need better state machines too.
> To some extent that may be true, but time marches on, andYes, that's fair. Time does move on. On the other hand 4-bitters
> there is no shortage of silicon. When a 32 bit processor
> that can run a full OS like linux costs less than the 8 or 16
> bit micro that requires specialized non-standard software to
> function, many will choose the 32 bit processor.
lasted longer than lots predicted. I'm sure some are still in
use. We haven't seen the end of 8-bitters by any means, yet,
either. Declaring the conversion of all applications to
32-bitters immediately is quite premature. May I suggest, as a
designer, you're looking at the front end of new designs.
But the factories are still turning out the designs of the past
7 to even 14+ years. They're still profitable, and ripping them
out to "improve" them at a huge new programming cost, isn't high
on lots of peoples task list.
How many PICs, HC11, and AVRs are commented on the robot lists?
Introduced in what, 1980, 1987, 1995. These are probably the
most common mentioned processors.
> You simply haven't looked around lately then:Sure... And you can show me those quadrature encoders and full
featured, complimentary output, deadband protected PWM on those
processors you're linking to there?
Oh, doesn't look like any of these PowerQUICCs list any motion
control. Industrial control is listed in one place, along with
printers. I bet these aren't the controllers hooked to the
steppers and servos though.
I don't deny there are things that can run Linux. Never said it.
I deny there are things that run Linux that do expert motion
control without adding supporting hardware.
> But according to the Freescale web site the DSP56F805Naw. It's still active. What they are recommending instead of
> you use is not recommended for new designs, so it may be too
> late to get it into the toolbox. Time marches on.
the 56F8xx chips are the 56F8xxx chips. Nearly the same type,
but faster, with much more memory (you know, for the guys who
have to use the bloat tools to get anything done.) Our
SuperPlugaPod(TM) will be based on the 56F8365. Hardware has
been done a long time, just waiting for our software guys to
catch up. We are porting our IsoMax(TM) to it. That's the
project I mentioned where we were leaving C behind, and gaining
a 5x improvement in speed.
S'pose we can give this thread a rest now? Looks like we've left
FSM's way behind, and off on a topic not of much interest to me.
Or is my feeling about Linux like you're feeling about Windoze
just too big a heresay to allow to stand?