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

Re: Active users

Expand Messages
  • graybeard2ca
    ... Thank you. It s been an enjoyable ride. Not strictly BEAM, but if people want, I ll post photos on my web site blog.graywriterrv.com. My son took one
    Message 1 of 17 , Jun 18, 2012
    • 0 Attachment
      --- In beam@yahoogroups.com, "connor_ramsey@..." <connor_ramsey@...> wrote:
      >
      >
      >
      > --- In beam@yahoogroups.com, "Tom Gray" <grayed@> wrote:
      > > Currently working on a solar power dual-axis tracking system with dusk sensor, shunt charge control, clock, motor drivers. Worked out the electronics a couple of years ago but building the hardware (solar panel support frame, gearing) has taken three revisions over the last year.
      > >
      >
      > Ooh, that sounds like it's gonna be a treat!
      >

      Thank you. It's been an enjoyable ride. Not strictly BEAM, but if people want, I'll post photos on my web site blog.graywriterrv.com.

      My son took one look at the circuit on the breadboard and said, "I could replace that with a single microprocessor." Well, yeah, but where's the fun in that?
    • Neuron Craft
      Would be great if you can post them up. I am glad to see a couple long time (over 10 - 15 years maybe?) BEAMers are still around but there are barely new
      Message 2 of 17 , Jun 18, 2012
      • 0 Attachment
        Would be great if you can post them up. I am glad to see a couple long time (over 10 - 15 years maybe?) BEAMers are still around but there are barely new people jumping in or new projects being posted. I am rebooting my interest in BEAM having been busy with web dev for the past few years. It is also because it's easier to get the parts I need these days so exciting times ahead.


        From: graybeard2ca <grayed@...>
        To: beam@yahoogroups.com
        Sent: Tuesday, June 19, 2012 12:52 AM
        Subject: [beam] Re: Active users

         


        --- In beam@yahoogroups.com, "connor_ramsey@..." <connor_ramsey@...> wrote:
        >
        >
        >
        > --- In beam@yahoogroups.com, "Tom Gray" <grayed@> wrote:
        > > Currently working on a solar power dual-axis tracking system with dusk sensor, shunt charge control, clock, motor drivers. Worked out the electronics a couple of years ago but building the hardware (solar panel support frame, gearing) has taken three revisions over the last year.
        > >
        >
        > Ooh, that sounds like it's gonna be a treat!
        >

        Thank you. It's been an enjoyable ride. Not strictly BEAM, but if people want, I'll post photos on my web site blog.graywriterrv.com.

        My son took one look at the circuit on the breadboard and said, "I could replace that with a single microprocessor." Well, yeah, but where's the fun in that?



      • J Wolfgang Goerlich
        Neuron Craft wrote: Is there other beam community people hang around out there? Hello, Welcome, and here is to the next generation of
        Message 3 of 17 , Jun 20, 2012
        • 0 Attachment
          Neuron Craft <neuroncraft@...> wrote: "Is there other beam community people hang around out there?"

          Hello,

          Welcome, and here is to the next generation of our community!

          I am still here in the background, tending to the occasional group administrative need. I slowed down on Beam robotics when my son grew out of spending time with me. I had thought I would pick Beam back up again when my daughter reached the right age. So far she and I have been doing other non-robotics projects. That may change in the next year or two. Time will tell.

          -- 
        • Martin McKee
          I am still here as well ( for the better part of a decade I guess ), but I have been doing little that connects with BEAM and have, therefore only been
          Message 4 of 17 , Jun 20, 2012
          • 0 Attachment
            I am still here as well ( for the better part of a decade I guess ), but I have been doing little that connects with BEAM and have, therefore only been lurking.  I have been doing a fair amount of robotics, in the form of microcontroller based systems and am currently working on a UAV ( unmanned aerial vehicle ) and have found that the time I spent with BEAM helped me to consider my designs in unique ways.

            I keep thinking I'll get back into BEAM proper, of course, but it is just so hard for me to justify given the biomorphic sorts of things ( neurons NV and NU type, spiking, and others; analog input and output; extreme low power usage; and modularity... many processors ) that modern microcontrollers allow.

            Nevertheless, its good to see the community continuing to develop.  I'm proud of the time that I focused on such stripped down robotics.

            Martin Jay McKee
          • connor_ramsey@ymail.com
            I keep thinking I ll get back into BEAM proper, of course, but it is just ... Well, yes, they certainly do allow for virtual neurons of sorts. Perhaps a
            Message 5 of 17 , Jun 24, 2012
            • 0 Attachment
              "I keep thinking I'll get back into BEAM proper, of course, but it is just
              > so hard for me to justify given the biomorphic sorts of things ( neurons NV
              > and NU type, spiking, and others; analog input and output; extreme low
              > power usage; and modularity... many processors ) that modern
              > microcontrollers allow.
              >
              > Nevertheless, its good to see the community continuing to develop. I'm
              > proud of the time that I focused on such stripped down robotics."
              >
              > Martin Jay McKee


              Well, yes, they certainly do allow for virtual neurons of sorts. Perhaps a microcode containing a dynamic formula that determines the robot's response under an unlimited number of circumstances, therefore maintaining the essence of BEAM behavior. However, there are only a finite number of voltage levels that a digital circuit can possibly muster up, so while BEAM behavior could, theoretically, be replicated in a digital control system, OISM is still out of the question for something so rigid.

              And even so, I don't feel it's a microcontroller's place to have direct control over a robot's sensory responses and actions. It would be like people thinking with their DNA. Even in unicellular organisms, DNA only controls how every piece of automata is supposed to work, but the automata themselves are responsible for the cell's response and metabolism. The microcontroller is best used to aim the robot toward a specific goal or a series of goals, something a BEAM circuit is no use at, yet the BEAM circuit should be directly in charge of all interaction with the external environment, something a microcontroller isn't necessarily good at either. What I'm trying to say is that digital and analog mechanisms coupled in such a fashion would make for a wildly more successful robot than either technology alone could dream of.

              Even as Mark Tilden himself said, "Choosing digital or analog is like choosing food or water."
            • Amit Tiwari-Jones
              ... This isn t necessarily true, or perhaps it needs to be cleaned up with some more qualifications and definitions. When we re dealing with a strictly digital
              Message 6 of 17 , Jun 24, 2012
              • 0 Attachment


                >Well, yes, they certainly do allow for virtual neurons of sorts. Perhaps a microcode containing a dynamic formula that determines the robot's response under an unlimited number of circumstances, therefore maintaining the essence of BEAM >behavior. However, there are only a finite number of voltage levels that a digital circuit can possibly muster up, so while BEAM behavior could, theoretically, be replicated in a digital control system, OISM is still out of the question for something >so rigid.


                This isn't necessarily true, or perhaps it needs to be cleaned up with some more qualifications and definitions. When we're dealing with a strictly digital system we're not particularly looking at voltage levels, at least the way i understand it. In an analog beam system if we're talking about thresholds etc then yes. When it comes to artificial neural nets though, the models allow for weighting of inputs and outputs, and you can represent numerical weights quite well digitally, numbers representing voltage levels in memory. Comparing that with a beam system, a range of voltage levels can be represented by a particular weight digitally. What i'm getting at is that some circuit may change it's behaviour at any voltage level above a particular threshold, and have that same response for a range of levels above the same one. You can represent that digitally.


                In terms of the plasticity of a controlling network, I believe that now it is easier and more feasible to implement the controller mathematically in a program than with an Nv network. Reason being is that it is easier (and faster) to change the values of weights governing input and output responses and neuron inter-connectivity than in a beam system. After all, you would have to whip out your iron and rewire your network, plug in and experiment with new resistors. And then with the computer program you don't quite have that problem about large networks losing phase, or neurons affecting each other in unexpected ways for unexpected reasons (which can be a bad thing if you like emergent behaviour I guess. I got pissed when two identical circuits with (almost) the same components behaved quite differently, turns out it was solder flux around the neurons and still...).When I was experimenting with the argument resistor networks I reasoned that you can provide as many resistor arguments as you were willing, and change the networks output completely for many situations, an example of that would be a bunch of parallel argument Nvs being reconfigured to output patterns you find in a chain, a ring, a bicore. The problem I found myself in, was that I still had to choose resistors for the fuse and fire neurons (and sensor diversity and placement) in anticipation of particular conditions, and that there wasn't enough board real estate to handle them all, and I was in no way smart enough to figure out the inter connectivity. With a programmed net with some sort of genetic algorithm, it could be possible within a number of cycles to selfconverge on a solution.


                That brought me back round to what we've been saying though. To converge on something means you have a goal in mind. You can hardwire that beam style (phototaxis, say and more in a heirarchy), have unconstrained gearmotors and watch your bot "adapt" or you can program a goal (which you can change on the fly easily), and a virtual network which changes its structure and output. Of course, I suppose you could use a uC with the A-net, but now it's wheels within wheels for me.


                As an example, I was able to program a simple network on a pocket PC capable of controlling my old salamander. Two neurons in a loop for the phototaxis as in a bicore or monocore, two more with weighted inputs for some velocity regulation (left right) and an interconnected network of motor neurons for the 9 motors. It worked a treat. I could change the weighting manually, or the program could do it, of course the number of weights are limitless within the same resources unlike resistors.

                >Even as Mark Tilden himself said, "Choosing digital or analog is like choosing food or water." 


                Agreed. Right now I still prefer to build beam style because i like the experience of soldering and building. I filled up two A1 sized sheets with schematics for the spyder robot and I don't have the heart or time or money to build it. It would be a bit easier for me to implement the net in a program and get the same result, but I'd still be left with the expense. Oh well, when my job starts paying I'l see.


                Have fun, Best Regards and Good Luck,
                Amit


              • connor_ramsey@ymail.com
                I see. Although it s probably still best to implement a nerve net between the microcontroller and the body. As I ve suggested before, the analog portion
                Message 7 of 17 , Jun 25, 2012
                • 0 Attachment
                  I see. Although it's probably still best to implement a nerve net between the microcontroller and the body. As I've suggested before, the analog portion controls the the robot directly, and the digital portion loosely controls the analog portion, where the robot's goal can be controlled through the digital portion.

                  And can you explain to me what exactly solder flux, a Uc and A-net are? Because they sound too interesting for me to ignore.
                • Amit
                  Well, all roads lead to Rome. uC is slang for microcontroller. The u is supposed to be mu, which is the SI prefix for micro, C for controller. I picked
                  Message 8 of 17 , Jun 25, 2012
                  • 0 Attachment
                    Well,

                    all roads lead to Rome.

                    uC is slang for microcontroller. The 'u' is supposed to be mu, which is the SI prefix for micro, 'C' for controller. I picked that one up on this group.
                    Turns out that solder flux will affect your microcore. See 1.1 of
                    http://faq.solarbotics.net/nvnet.html

                    Some good information on there.

                    Sometime back when the whole Nv thing really clicked in my head, I realised that by injecting different processes in a loop you can create different gaits(which isn't a huge realisation I guess). If you have a hexcore, by drawing a 3x2 matrix of neurons, you can see that you can generate the tripod gait, one-by-one gait, (can't remember if I got wave/ripple done) etc. I had started a page on how to do this on my website, but I don't think I completed it or put it up. Anyways, the number of gaits was limited to the topology of the network, that is the size of your ring, if you have crossed neurons. As I thought about topology more, I figured that what else is topology, but timing between different neurons. If you had neurons with exceptionally short time constants it would be as if they weren't there and you could "reduce" the size of a network. The problem then, was figuring out how to do that. At first came the parameter resistors. Using a bilateral switch you could shorten or lengthen time constants of neurons to bring them in or out of the loop. This was fine, for a time, but still limited for reasons I can't quite remember.
                    My next big realisation, and it seems that all these realisations are me just seeing the brutally obvious, is that in an n neuron Nv network, the (n-1)th neuron acts as a delay for the activation of the nth neuron.
                    The crazy and powerful thing then, is this:
                    If you have several 2 Nv chains, with the inputs of the proximal(fuse) neurons in parallel and therefore receiving the same input, by simply varying the time constant of the fuse neurons, you could influence when the distal (fire) neurons activate. What this means is that you can output any pattern you feel like from this network. They could all activate at the same time, or activate in a descending or ascending pattern, some may be simultaneous, some may overlap. I thought it was excellent because now I was almost topology independent and could produce outputs simulating those of any current core. Think about a microcore switching over to something like a bicore.
                    I called it the A-net, not after my name though, lol.

                    I used this scheme as the basis for my Spyder redesign in an effort to produce the gaits for climbing, walking, running, turning. Later I added speed control with bicores.

                    You can see it on my website: http://amitnv.solarbotics.net/Topologies.htm

                    Later on, I would go on to find this paper by Bruce Robinson about human motor control theory. Turns out he did the same thing years before for advanced motor control, and had cooler things like brakes I believe, instead of just timing and speed.

                    B.R.

                    Amit


                    --- In beam@yahoogroups.com, "connor_ramsey@..." <connor_ramsey@...> wrote:
                    >
                    > I see. Although it's probably still best to implement a nerve net between the microcontroller and the body. As I've suggested before, the analog portion controls the the robot directly, and the digital portion loosely controls the analog portion, where the robot's goal can be controlled through the digital portion.
                    >
                    > And can you explain to me what exactly solder flux, a Uc and A-net are? Because they sound too interesting for me to ignore.
                    >
                  • Martin McKee
                    I must agree that there need be little functional difference between an analog ( typical BEAM... or even OISM ) and a digital ( that is programmable )
                    Message 9 of 17 , Jun 25, 2012
                    • 0 Attachment
                      I must agree that there need be little functional difference between an analog ( typical BEAM... or even OISM ) and a digital ( that is programmable ) implementation.  At one point ( five years ago or so ) I did a quick test of neural network simulation on an AVR microcontroller -- outputing to LEDs.  The simulation was of a 16 neuron fully connected network ( every neuron could receive as input the output of itself, a bias value and all of the other neurons ).  The weights ( similar to the resistor values on NV neurons ) were 16-bit values and the neuron thresholds were 32-bits.  The total number of weights was 16x17=272.  At each network update there was noise added to the threshold.  The whole thing would update at up to 120Hz running on the processor's internal clock.

                      By simply changing the weights between the neurons it was easy to easy to create pulses with widths between 1/120 sec. and ~25 sec. ( it could have gone on indefinitely, but I got bored watching the whole cycle ).  It was also easy to produce random width continuous pulses because of the noise on the threshold.

                      The problem was not that the system was unable to process or react quickly enough ( it was updating at >100Hz easily ), but that the huge number of parameters was simply too much to deal with.  I never did extend it to handling external input either ( though it would be easy given the built-in analog-to-digital converters available ), there were too many questions about how the weights would be adjusted.  

                      I've often thought that it would be fun to go back to the project and build a robot around the neurons as the main controller.  Perhaps I'll try to fit it in this summer.

                      In the end, though, either analog or digital, an increase in functionality tends to lead to an increase in complexity of implementation.  The earlier suggestion of a learning system ( like a genetic algorithm ) seems to be the best way to go to really end up with complex networks.

                      Martin Jay McKee

                      On Mon, Jun 25, 2012 at 8:24 PM, Amit <amitjones101@...> wrote:
                       

                      Well,

                      all roads lead to Rome.

                      uC is slang for microcontroller. The 'u' is supposed to be mu, which is the SI prefix for micro, 'C' for controller. I picked that one up on this group.
                      Turns out that solder flux will affect your microcore. See 1.1 of
                      http://faq.solarbotics.net/nvnet.html

                      Some good information on there.

                      Sometime back when the whole Nv thing really clicked in my head, I realised that by injecting different processes in a loop you can create different gaits(which isn't a huge realisation I guess). If you have a hexcore, by drawing a 3x2 matrix of neurons, you can see that you can generate the tripod gait, one-by-one gait, (can't remember if I got wave/ripple done) etc. I had started a page on how to do this on my website, but I don't think I completed it or put it up. Anyways, the number of gaits was limited to the topology of the network, that is the size of your ring, if you have crossed neurons. As I thought about topology more, I figured that what else is topology, but timing between different neurons. If you had neurons with exceptionally short time constants it would be as if they weren't there and you could "reduce" the size of a network. The problem then, was figuring out how to do that. At first came the parameter resistors. Using a bilateral switch you could shorten or lengthen time constants of neurons to bring them in or out of the loop. This was fine, for a time, but still limited for reasons I can't quite remember.
                      My next big realisation, and it seems that all these realisations are me just seeing the brutally obvious, is that in an n neuron Nv network, the (n-1)th neuron acts as a delay for the activation of the nth neuron.
                      The crazy and powerful thing then, is this:
                      If you have several 2 Nv chains, with the inputs of the proximal(fuse) neurons in parallel and therefore receiving the same input, by simply varying the time constant of the fuse neurons, you could influence when the distal (fire) neurons activate. What this means is that you can output any pattern you feel like from this network. They could all activate at the same time, or activate in a descending or ascending pattern, some may be simultaneous, some may overlap. I thought it was excellent because now I was almost topology independent and could produce outputs simulating those of any current core. Think about a microcore switching over to something like a bicore.
                      I called it the A-net, not after my name though, lol.

                      I used this scheme as the basis for my Spyder redesign in an effort to produce the gaits for climbing, walking, running, turning. Later I added speed control with bicores.

                      You can see it on my website: http://amitnv.solarbotics.net/Topologies.htm

                      Later on, I would go on to find this paper by Bruce Robinson about human motor control theory. Turns out he did the same thing years before for advanced motor control, and had cooler things like brakes I believe, instead of just timing and speed.

                      B.R.

                      Amit



                      --- In beam@yahoogroups.com, "connor_ramsey@..." <connor_ramsey@...> wrote:
                      >
                      > I see. Although it's probably still best to implement a nerve net between the microcontroller and the body. As I've suggested before, the analog portion controls the the robot directly, and the digital portion loosely controls the analog portion, where the robot's goal can be controlled through the digital portion.
                      >
                      > And can you explain to me what exactly solder flux, a Uc and A-net are? Because they sound too interesting for me to ignore.
                      >


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