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

Re: [beam] Fw: [small-gods] Adaptive walkers

Expand Messages
  • Wilf Rigter
    Here is an example of a linear gain block using local feedback to avoid oscillation during switching (what causes saturation) This one uses a HC245 buffer for
    Message 1 of 8 , Dec 1, 2002
    • 0 Attachment
      Here is an example of a linear gain block using local feedback to avoid oscillation during switching  (what causes saturation) This one uses a HC245 buffer for a  4Nv microcore with motor drivers. Note the Nv resistors must be alternately referenced to +V and gnd. Doesn't matter for the motor drivers though since they are also connected to alternate Nvs. The small cap is used as a trigger and the large cap provides the time constant for each Nv. The small resistor provides isolation for the trigger pulse. The large resistor can be adjusted to the duty cycle of the motor pulses for turning etc. Nice and compact circuit : not yet tested but should work.
       
       
      wilf
       
         
      ----- Original Message -----
      Sent: Sunday, December 01, 2002 8:32 PM
      Subject: Re: [beam] Fw: [small-gods] Adaptive walkers

      Sorry Ori, no can do!
       
      For  Nv networks greater than two, you need to use Schmitt inverters or use some other (one per Nv) positive feedback loop to avoid saturation. 
      No problem for a bicore to use an HC240 since that loop is always saturated.
       
      wilf
       
      ----- Original Message -----
      From: Ori
      Sent: Sunday, December 01, 2002 8:15 PM
      Subject: Re: [beam] Fw: [small-gods] Adaptive walkers

      Hmmm, I was thinking about automatic saturation... would an HCT240 do the trick? Also, I forgot the resistors across the inverters of the red IC... One meg should do it.
       
      Ori
      ----- Original Message -----
      Sent: Sunday, December 01, 2002 11:14 PM
      Subject: Re: [beam] Fw: [small-gods] Adaptive walkers

      Allas the 240 octocore will imediately saturate. It  needs Schmitt inverters to work as shown. Also consider that the left/right enable switches 
      require that you use active high input smoke free h-bridge drivers. Best to use 240 motor drivers, eh? Ofcourse the motors won't turn until at least one switch is closed. Not only that but the motor will continue to rotate in one direction until both switches are closed. However the basic scheme of injecting/neutralizing processes is right with some improvements to make it practical. 
       
       
      The attached schematic show a practical way to parallel load a dip switch pattern into a 8Nv core.  Some settings are "illegal" as you will soon find out by experiment.  Closing the load switch loads the pattern but also disables the motor drivers to avoid stripping gears.  Open the load switch and the core executes the first of eight steps of one cycle.  The load oscillator C1/R1 should be adjusted to be equal to one or more complete core cycles. C2/R2 should  be kept small.SInce the load oscillator periodically refreshes the core pattern,  it will never degenerate in time.
       
      wilf
       
       
       
       
      --- Original Message -----
      From: Ori
      Sent: Saturday, November 30, 2002 6:17 PM
      Subject: [beam] Fw: [small-gods] Adaptive walkers

      As Bruce wanted, here is the post that I made to Small-Gods:
       
      ----- Original Message -----
      From: Ori
      Sent: Saturday, November 23, 2002 11:10 PM
      Subject: [small-gods] Adaptive walkers

      Adaptive walkers are something that has been greatly emphasized in BEAM. Mark's papers mention multiple gaits, which gets people very exited, but then leads to disappointment when circuits for such robots are not available. No one makes these bots other than Mark!
       
      In the general collection of BEAM walker circuits, the only adaptive aspect of the walking gait is timing. Under greater loads, the motor current increases, which slows down the timing of your bicore or microcore.
       
      Although this effect is interesting, it is not very obvious, and it is also repeatable with microcontrollers. This analog action is generally considered impossible for a microcontroller, but a 2 motor walker controlled a microcontroller can do the same thing - just add two field-effect sensors (one at each motor), and you can get feedback about the motor. The timing can then be dynamic, by using the field value as a coefficient, or in IF statements.
       
      What, then, is holding us back from building the walkers with multiple gaits that Mark made? We limit the Nvs! With the PNC-free circuit (Not that I have anything against it), we ensure that only one pulse travels through at a time. Tricores, pentacores, and other odd-numbered loops are avoided, because of the 'unwanted' saturated states.
       
      If you have bigger loops, and don't try to limit the pulses, you can get multiple gaits, because of the multiple possible patterns. Add sensors that drop in or take out a pulse and there you have it! So, why can't you do this with a microcontroller? The Nv loops don't have to all switch on or off at the same time, like a shift-register loop would do. That means that you have an infinite number of gaits! You start off saturated, which may or may not be a good thing, but the gaits change as the walker goes, when you flick the add-pulse or remove-pulse sensors.
       
      Not all the gaits work well, but that's the point! It is all adaptive. You can have tons of possible gaits with this concept. I've made up a very simple example:
       
      Adaptive Walker
       
       It's a 4-motor walker, Scout Walker II-style motor orientation, with left and right turning (reverse if both are triggered). The 8 extra switches would just be the standard tactile sensors (spring around a pin, which triggers on flick),sticking up in the air for humans to play around with. Flick the springs, and the gait will greatly change before your eyes! Infinite possibilities in gaits are possible, because the Nvs do not all switch at the same time.
       
      To make this more interesting, mount these springs at the bottom, sides, and legs of the walker. This way, as the walker travels around it's environment, it will change it's own gaits. This is *definitely* something to add LEDs to! :)
       
      This is something that I think is very cool, and I'm curious to know who else is interested by multi-gate walkers.
       
      Later,
       
      Ori


      To unsubscribe from this group, send an email to:
      beam-unsubscribe@egroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


      To unsubscribe from this group, send an email to:
      beam-unsubscribe@egroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


      To unsubscribe from this group, send an email to:
      beam-unsubscribe@egroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


      To unsubscribe from this group, send an email to:
      beam-unsubscribe@egroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Wilf Rigter
      Well I build the 245 microcore and it don t work .... but evolved it into this similar circuit which uses the non inverting version of the HC240. and it works
      Message 2 of 8 , Dec 6, 2002
      • 0 Attachment
        Well I build the 245 microcore and it don't work ....  but evolved it into this similar circuit which uses the non inverting version of the HC240.
         
         
        and it works very well indeed. The HC244 microcore  uses a primitive PNC which, on power up, swallows all but one process while inhibiting the motor driver enable pin 19.  The layout is a natural for freeforming and it uses even less parts than it's non-functional 245 microcore ancestor.
         
        wilf
        ----- Original Message -----
        Sent: Sunday, December 01, 2002 9:52 PM
        Subject: Re: [beam] Fw: [small-gods] Adaptive walkers

        Here is an example of a linear gain block using local feedback to avoid oscillation during switching  (what causes saturation) This one uses a HC245 buffer for a  4Nv microcore with motor drivers. Note the Nv resistors must be alternately referenced to +V and gnd. Doesn't matter for the motor drivers though since they are also connected to alternate Nvs. The small cap is used as a trigger and the large cap provides the time constant for each Nv. The small resistor provides isolation for the trigger pulse. The large resistor can be adjusted to the duty cycle of the motor pulses for turning etc. Nice and compact circuit : not yet tested but should work.
         
         
        wilf
         
           
        ----- Original Message -----
        Sent: Sunday, December 01, 2002 8:32 PM
        Subject: Re: [beam] Fw: [small-gods] Adaptive walkers

        Sorry Ori, no can do!
         
        For  Nv networks greater than two, you need to use Schmitt inverters or use some other (one per Nv) positive feedback loop to avoid saturation. 
        No problem for a bicore to use an HC240 since that loop is always saturated.
         
        wilf
         
        ----- Original Message -----
        From: Ori
        Sent: Sunday, December 01, 2002 8:15 PM
        Subject: Re: [beam] Fw: [small-gods] Adaptive walkers

        Hmmm, I was thinking about automatic saturation... would an HCT240 do the trick? Also, I forgot the resistors across the inverters of the red IC... One meg should do it.
         
        Ori
        ----- Original Message -----
        Sent: Sunday, December 01, 2002 11:14 PM
        Subject: Re: [beam] Fw: [small-gods] Adaptive walkers

        Allas the 240 octocore will imediately saturate. It  needs Schmitt inverters to work as shown. Also consider that the left/right enable switches 
        require that you use active high input smoke free h-bridge drivers. Best to use 240 motor drivers, eh? Ofcourse the motors won't turn until at least one switch is closed. Not only that but the motor will continue to rotate in one direction until both switches are closed. However the basic scheme of injecting/neutralizing processes is right with some improvements to make it practical. 
         
         
        The attached schematic show a practical way to parallel load a dip switch pattern into a 8Nv core.  Some settings are "illegal" as you will soon find out by experiment.  Closing the load switch loads the pattern but also disables the motor drivers to avoid stripping gears.  Open the load switch and the core executes the first of eight steps of one cycle.  The load oscillator C1/R1 should be adjusted to be equal to one or more complete core cycles. C2/R2 should  be kept small.SInce the load oscillator periodically refreshes the core pattern,  it will never degenerate in time.
         
        wilf
         
         
         
         
        --- Original Message -----
        From: Ori
        Sent: Saturday, November 30, 2002 6:17 PM
        Subject: [beam] Fw: [small-gods] Adaptive walkers

        As Bruce wanted, here is the post that I made to Small-Gods:
         
        ----- Original Message -----
        From: Ori
        Sent: Saturday, November 23, 2002 11:10 PM
        Subject: [small-gods] Adaptive walkers

        Adaptive walkers are something that has been greatly emphasized in BEAM. Mark's papers mention multiple gaits, which gets people very exited, but then leads to disappointment when circuits for such robots are not available. No one makes these bots other than Mark!
         
        In the general collection of BEAM walker circuits, the only adaptive aspect of the walking gait is timing. Under greater loads, the motor current increases, which slows down the timing of your bicore or microcore.
         
        Although this effect is interesting, it is not very obvious, and it is also repeatable with microcontrollers. This analog action is generally considered impossible for a microcontroller, but a 2 motor walker controlled a microcontroller can do the same thing - just add two field-effect sensors (one at each motor), and you can get feedback about the motor. The timing can then be dynamic, by using the field value as a coefficient, or in IF statements.
         
        What, then, is holding us back from building the walkers with multiple gaits that Mark made? We limit the Nvs! With the PNC-free circuit (Not that I have anything against it), we ensure that only one pulse travels through at a time. Tricores, pentacores, and other odd-numbered loops are avoided, because of the 'unwanted' saturated states.
         
        If you have bigger loops, and don't try to limit the pulses, you can get multiple gaits, because of the multiple possible patterns. Add sensors that drop in or take out a pulse and there you have it! So, why can't you do this with a microcontroller? The Nv loops don't have to all switch on or off at the same time, like a shift-register loop would do. That means that you have an infinite number of gaits! You start off saturated, which may or may not be a good thing, but the gaits change as the walker goes, when you flick the add-pulse or remove-pulse sensors.
         
        Not all the gaits work well, but that's the point! It is all adaptive. You can have tons of possible gaits with this concept. I've made up a very simple example:
         
        Adaptive Walker
         
         It's a 4-motor walker, Scout Walker II-style motor orientation, with left and right turning (reverse if both are triggered). The 8 extra switches would just be the standard tactile sensors (spring around a pin, which triggers on flick),sticking up in the air for humans to play around with. Flick the springs, and the gait will greatly change before your eyes! Infinite possibilities in gaits are possible, because the Nvs do not all switch at the same time.
         
        To make this more interesting, mount these springs at the bottom, sides, and legs of the walker. This way, as the walker travels around it's environment, it will change it's own gaits. This is *definitely* something to add LEDs to! :)
         
        This is something that I think is very cool, and I'm curious to know who else is interested by multi-gate walkers.
         
        Later,
         
        Ori


        To unsubscribe from this group, send an email to:
        beam-unsubscribe@egroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


        To unsubscribe from this group, send an email to:
        beam-unsubscribe@egroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


        To unsubscribe from this group, send an email to:
        beam-unsubscribe@egroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


        To unsubscribe from this group, send an email to:
        beam-unsubscribe@egroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


        To unsubscribe from this group, send an email to:
        beam-unsubscribe@egroups.com



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • tom_headoflead <tom_headoflead@yahoo.com>
        Hmm this sounds like something I did awhile back. instead I used a single photo bicore to feed into two seperate strings of 74hc14 Nv s, which works reallly
        Message 3 of 8 , Dec 13, 2002
        • 0 Attachment
          Hmm this sounds like something I did awhile back. instead I used a
          single photo bicore to feed into two seperate strings of 74hc14 Nv's,
          which works reallly good and cant saturate because there is no loop
          involved allows many diffrent walking gates which are constantly
          changing with the light, both sides of the bot are essentially
          seperate. The bot is able to reverse without a reverser and turn as
          well. When the bot gets close enough to an object it ushaually speeds
          up the bicore in frequency and it feeds alot more pulses into both
          sets of strings and the gait is sped up and causes it to kind
          of "shimmy" backwards. It's very interesting to watch and isnt as
          predictable as a microcore. It even finds its way into the same dark
          corner when I let it loose.

          Tom



          --- In beam@yahoogroups.com, "Wilf Rigter" <wrigter@d...> wrote:
          > Sorry Ori, no can do!
          >
          > For Nv networks greater than two, you need to use Schmitt
          inverters or use some other (one per Nv) positive feedback loop to
          avoid saturation.
          > No problem for a bicore to use an HC240 since that loop is always
          saturated.
          >
          > wilf
          >
          > ----- Original Message -----
          > From: Ori
          > To: beam@yahoogroups.com
          > Sent: Sunday, December 01, 2002 8:15 PM
          > Subject: Re: [beam] Fw: [small-gods] Adaptive walkers
          >
          >
          > Hmmm, I was thinking about automatic saturation... would an
          HCT240 do the trick? Also, I forgot the resistors across the
          inverters of the red IC... One meg should do it.
          >
          > Ori
          > ----- Original Message -----
          > From: Wilf Rigter
          > To: beam@yahoogroups.com
          > Sent: Sunday, December 01, 2002 11:14 PM
          > Subject: Re: [beam] Fw: [small-gods] Adaptive walkers
          >
          >
          > Allas the 240 octocore will imediately saturate. It needs
          Schmitt inverters to work as shown. Also consider that the left/right
          enable switches
          > require that you use active high input smoke free h-bridge
          drivers. Best to use 240 motor drivers, eh? Ofcourse the motors won't
          turn until at least one switch is closed. Not only that but the motor
          will continue to rotate in one direction until both switches are
          closed. However the basic scheme of injecting/neutralizing processes
          is right with some improvements to make it practical.
          >
          >
          >
          > The attached schematic show a practical way to parallel load a
          dip switch pattern into a 8Nv core. Some settings are "illegal" as
          you will soon find out by experiment. Closing the load switch loads
          the pattern but also disables the motor drivers to avoid stripping
          gears. Open the load switch and the core executes the first of eight
          steps of one cycle. The load oscillator C1/R1 should be adjusted to
          be equal to one or more complete core cycles. C2/R2 should be kept
          small.SInce the load oscillator periodically refreshes the core
          pattern, it will never degenerate in time.
          >
          > wilf
          >
          >
          >
          >
          > --- Original Message -----
          > From: Ori
          > To: beam@yahoogroups.com
          > Sent: Saturday, November 30, 2002 6:17 PM
          > Subject: [beam] Fw: [small-gods] Adaptive walkers
          >
          >
          > As Bruce wanted, here is the post that I made to Small-Gods:
          >
          > ----- Original Message -----
          > From: Ori
          > To: small-gods@yahoogroups.com
          > Sent: Saturday, November 23, 2002 11:10 PM
          > Subject: [small-gods] Adaptive walkers
          >
          >
          > Adaptive walkers are something that has been greatly
          emphasized in BEAM. Mark's papers mention multiple gaits, which gets
          people very exited, but then leads to disappointment when circuits
          for such robots are not available. No one makes these bots other than
          Mark!
          >
          > In the general collection of BEAM walker circuits, the only
          adaptive aspect of the walking gait is timing. Under greater loads,
          the motor current increases, which slows down the timing of your
          bicore or microcore.
          >
          > Although this effect is interesting, it is not very obvious,
          and it is also repeatable with microcontrollers. This analog action
          is generally considered impossible for a microcontroller, but a 2
          motor walker controlled a microcontroller can do the same thing -
          just add two field-effect sensors (one at each motor), and you can
          get feedback about the motor. The timing can then be dynamic, by
          using the field value as a coefficient, or in IF statements.
          >
          > What, then, is holding us back from building the walkers with
          multiple gaits that Mark made? We limit the Nvs! With the PNC-free
          circuit (Not that I have anything against it), we ensure that only
          one pulse travels through at a time. Tricores, pentacores, and other
          odd-numbered loops are avoided, because of the 'unwanted' saturated
          states.
          >
          > If you have bigger loops, and don't try to limit the pulses,
          you can get multiple gaits, because of the multiple possible
          patterns. Add sensors that drop in or take out a pulse and there you
          have it! So, why can't you do this with a microcontroller? The Nv
          loops don't have to all switch on or off at the same time, like a
          shift-register loop would do. That means that you have an infinite
          number of gaits! You start off saturated, which may or may not be a
          good thing, but the gaits change as the walker goes, when you flick
          the add-pulse or remove-pulse sensors.
          >
          > Not all the gaits work well, but that's the point! It is all
          adaptive. You can have tons of possible gaits with this concept. I've
          made up a very simple example:
          >
          >
          >
          > It's a 4-motor walker, Scout Walker II-style motor
          orientation, with left and right turning (reverse if both are
          triggered). The 8 extra switches would just be the standard tactile
          sensors (spring around a pin, which triggers on flick),sticking up in
          the air for humans to play around with. Flick the springs, and the
          gait will greatly change before your eyes! Infinite possibilities in
          gaits are possible, because the Nvs do not all switch at the same
          time.
          >
          > To make this more interesting, mount these springs at the
          bottom, sides, and legs of the walker. This way, as the walker
          travels around it's environment, it will change it's own gaits. This
          is *definitely* something to add LEDs to! :)
          >
          > This is something that I think is very cool, and I'm curious
          to know who else is interested by multi-gate walkers.
          >
          > Later,
          >
          > Ori
          >
          >
          > To unsubscribe from this group, send an email to:
          > beam-unsubscribe@egroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          Service.
          >
          >
          >
          > To unsubscribe from this group, send an email to:
          > beam-unsubscribe@egroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          Service.
          >
          >
          > Yahoo! Groups Sponsor
          > ADVERTISEMENT
          >
          >
          >
          >
          > To unsubscribe from this group, send an email to:
          > beam-unsubscribe@egroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          Service.
        Your message has been successfully submitted and would be delivered to recipients shortly.