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

[SeattleRobotics] Why FSMs? Example! (was Loki)

Expand Messages
  • PeterBalch
    Randy said ... It s a tutorial on how easy it can be to write a 4-servo controller. The point is that processor time costs next to nothing. Processor time is
    Message 1 of 212 , Jan 1 3:55 AM
      Randy said
      > Good heavens! This is a tutorial how to throw away 25%+ of your
      > processing power to service only 4 servos! All that is happening
      > in that 25%+ of your processing is sequentially, 4 line, one at
      > a time, goes up, and come back down.

      It's a tutorial on how easy it can be to write a 4-servo controller.

      The point is that processor time costs next to nothing. Processor time is
      only expensive when you run out of it and have to buy a bigger processor.
      If 75% of a cheap processor is more than you need to run the rest of your
      robot then it doesn't matter if you've thrown away the other 25%.

      My programming time, on the other hand, is always expensive.

      > Rather than keeping explicit state information,
      > a <begin check-timer until> structure captures the processor's
      > Program Counter, restricting it to a very short range of
      > possible values. While the Program Counter holds those values to
      > the exclusion of all others, no other processing occurs.

      So what? The processor isn't an employee. I'm not paying it piece-rate. I
      don't care!

      I looked at using timers and interrupts and found that, using the processor
      I had, I could get just as accurate timing with a tight loop. And it took
      less programming effort.

      The accuracy I needed was determined by the granularity of the byte used to
      set servo-position - not by the granularity of the timing loop. I had to
      put NOPs into the timing loop to slow it down.

      My programming time is more important than the processor's time. Or do you
      think I should write everything in assembler so that the PIC is used more

      > So we have these loops checking a thousand times
      > (or more) in a row if 1.5mS has passed, and disallowing a
      > thousand (or more) useful things being done.

      The PIC doesn't have a thousand other useful things to do.

      > Now things like 1) timing the echo time on a sonar 2) measuring
      > pulse width on accelerometers/gyros 3) taking A/D conversions on
      > accelerometers/gyros 4) reading GPS sentences 5) etc. can be run
      > concurrently with servo updates.

      Were I doing all those ther things, I'd have a PIC dedicated to controlling
      the servos. (I understand you can even buy such things ;-).) And I'd
      program it using whatever technique was simplest to program. What saves me
      effort not what saves the PIC effort. Writing a tight timing loop takes
      less time than writing this paragraph. Setting up timers and interrupts
      takes a lot longer. My time matters, the PIC's doesn't.

      In this particular example (my biped), what else did the PIC have to do? It
      had to send the servos though a sequence of positions - which took around
      1% of it's time. It checked comms with the PC (around 1% of it's time). And
      it had to check the two obstacle detectors (around 60% of it's time). An
      obstacle detector works like this: charge a cap, discharge it through a
      phototransistor, time the discharge, turn on an LED, charge the cap,
      discharge it through a phototransistor, time the discharge, turn off the
      LED. I've looked at doing the timing via interrupts and via a tight loop.
      The tight loop can have variable timing resolution - you need more
      resolution for shorter times, the response is logarithmic. Also the
      interrupt would interfere with the servo timing. The whole point of an
      interrupt is that it can happen at any time. I can't use interrupts for the
      servos because they would interfere with the accurate timing of the
      phototransistors. I can't use interrupts for timing the phototransistors
      because they would interfere with the servos. By doing it all in tight
      loops, I can keep complete control of the timing of everything. Perhaps I
      could start turning interrupts on and off depending on what's currently
      happening but that's getting awfully complicated and has no advantage.

      I certainly can't use FSMs to do everything because the housekeeping
      overhead means none of the timings would be accurate enough.

      > Why more people don't get the FSM concepts, is a somewhat
      > interesting point. As you say, it's not all that hard to do. It
      > saves bundles of processor time.

      I "get it". I know exactly how to write and use FSMs. Please stop implying
      that the rest of us are stupid because we don't always use them. We don't
      always use them because they're not always appropriate. I don't care about
      processor time. If a project manager spends his entire life worrying about
      processor time, you fire him. Programing time, design time and software
      maintainance time are important. That's what "structured programming" is
      about. And please don't say that FSMs are as easy to program or as
      efficient in programming effort. They're not. That was proved in the 1970s.
      That's why everyone sensible switched to structured programming. The 1970s
      weren't an era when intellectual giants bestrode the world and nowadays all
      that's available are dim-witted C++ programmers. "Structured programmers"
      aren't less intelligent, they're more efficient. That's why their employer
      pays them to do it that way.

      Look, I've been programming for decades. I've used FSMs many times, I've
      used interrupts many times and I've used dedicated timing loops many
      times. I've known how to do all that stuff since (at least some of) the
      people on this forum were in diapers. I know how to write programs that use
      the processor's time efficiently and I know how to write programs that use
      my programming time efficiently.

      But most importantly of all, I know when to use which technique. There is
      no One Size Fits All.

    • PeterBalch
      Dr. Bruce. ... have ... OK, I looked it up. In Danaidae (monarchs), Satyridae (whites, graylings) and Nymphalidae (emperors) the two front legs are very short,
      Message 212 of 212 , Jan 14 3:47 AM
        Dr. Bruce.
        > Interesting question and explanation - except that butterflies actually
        > 6 legs.... 4 long and 2 short.

        OK, I looked it up. In Danaidae (monarchs), Satyridae (whites, graylings)
        and Nymphalidae (emperors) the two front legs are very short, have no claws
        and are useless for walking. I thought Papillionidae (swallowtails) were
        the same but they're not, they have 6 good legs.

        It gets wierder. In Riodinidae, the males have 4 walking legs but the
        females have 6.

        Lycaenidae (blues) and Hesperidae (skippers) all have 6 legs.

        What on earth can one learn from that?

        Anyway, Alan asked what "bugs" are quadrupeds. I said mantises, monarchs
        and swallowtails. I was wrong about swallowtails. I was taught all this
        stuff decades ago so forgive me if I'm a bit rusty. I even spent one summer
        as a student doing fieldwork in the west of Virginia catching swallowtails
        and monarchs so I certainly _ought_ to have remembered the details.

        I still can't think of any other arthropods with just 4 walking legs. I
        think some crustacean larvae have only 4 legs but they don't use them for

      Your message has been successfully submitted and would be delivered to recipients shortly.