Loading ...
Sorry, an error occurred while loading the content.

Re: [SeattleRobotics] Coin Toss Post Mortem

Expand Messages
  • Next Kiwi
    Hi Tom That is probably the best wrap up of a topic I have ever read. I agree totally. Thanks for the summary. Cheers Keith ... From: Tom Capon To:
    Message 1 of 45 , May 31, 2007
    • 0 Attachment
      Hi Tom

      That is probably the best wrap up of a topic I have ever read. I agree totally. Thanks for the summary.

      Cheers
      Keith

      ----- Original Message -----
      From: Tom Capon
      To: SeattleRobotics@yahoogroups.com
      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.

      --Tom C.

      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.
      >
      > Randy
      > www.newmicros.com
      >
      >
      >

      [Non-text portions of this message have been removed]





      [Non-text portions of this message have been removed]
    • Randy M. Dumse
      Ed Okerson responded: Thursday, June 07, 2007 2:59 PM ... 83? I remember being asked about it in an interview in 78. What concerned me most was what was
      Message 45 of 45 , Jun 7, 2007
      • 0 Attachment
        Ed Okerson responded: Thursday, June 07, 2007 2:59 PM
        > OK, but did you continue watching as it evolved, or did you
        > just decide you didn't like it in 1983 and went off to do
        > something else?

        '83? I remember being asked about it in an interview in '78.
        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 programmers
        > how to write better state machines.

        If you can only imagine C programmers need better state
        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, and
        > 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.

        Yes, that's fair. Time does move on. On the other hand 4-bitters
        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:
        >
        > http://www.freescale.com/webapp/sps/site/homepage.jsp?
        > nodeId=02VS0l3208

        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?

        http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=02V
        S0l3208691741421104

        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 DSP56F805
        > you use is not recommended for new designs, so it may be too
        > late to get it into the toolbox. Time marches on.

        Naw. It's still active. What they are recommending instead of
        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?

        Randy
        www.newmicros.com
      Your message has been successfully submitted and would be delivered to recipients shortly.