61158Re: [beam] Re: Wire Computing? A Theory
- Jul 18, 2013I've been working on the design of an op-amp based servo pulse generator circuit that I will, then, couple to a leg pattern generator. The ultimate platform is targeted as being an 9-motor, 4-leg, walker with an independent head. Over all, the system should be able to walk and survive as a typical BEAM walker but it will contain a tightly coupled microcontroller wired to the different bias points in the control system. The processor I'm looking at is probably an AtMega328. That way I could make the board fully Arduino compatible. Just plug it into the computer and it will act like any other Arduino. Not precisely what I would do if it were just for myself, but it seems to make sense if I am going to try to integrate this into the robot club that already works with Arduinos.Honestly, I love to see many different approaches to the issue. Although digital control has taken over the bulk of the robotics market, analog like control has definite advantages in certain areas. For one, it can be lower power if properly designed. That has been discussed sufficiently at this point though I think. Analog is also "instant." It works at the speed of electricity. On the other hand, digital control has latency limits that can only be overcome by adding a faster processor ( or, sometimes, programming smarter ). Analog also makes it easy to "sum" many different signals from different sources. The availability of bias points in analog control circuits allows for reflexes from sensors or control from above and the systems can remain completely decoupled. In a digital setting, that modularity can be harder to come by.I've though along some of the same lines as well. I've got a whole pile of four quadrant analog multipliers in my junk box. Along with op-amps, there are no reasonable arithmetic operations that cannot be implemented. Combine that with some simple wave form generators, and I think you have the beginnings of an extremely powerful and flexible control system. I just have never gotten around to doing more than think about it in passing. But, I do think it is possible to do so efficiently ( though not with the components I have at the moment ( they expect +/- 10v rails! ). It seems like a logical progression to move in both directions. I have been thinking along the lines of making BEAM even more analog by using op-amps and continuous values, while adding a digital control unit. I am still up in the air about if it is better to use pulse width modulation or a programmable resistor for control voltages though. PWM has two distinct advantages: 1) it needs no external components and, 2) it can be easily disconnected ( simply make the pin an input ).All my thinking has been along the lines of a five to eight motor walker ( not twelve for cost reasons ). I agree that a two motor walker is unlikely to place much of a "walking" load on a processor. Although I don't think it would make the program much more complicated, I do think that the combination of BEAM and a microcontroller would allow the processor to be decoupled from the time constraints of walking and that could simplify the structure of the program ( if not greatly reduce the size ). In the end, I have always looked at the combination in a leveled manner, somewhat akin to the Subsumption Architecture developed at MIT in the '80s. There would be a low-level analog ( BEAM ) control system that is closely coupled with a microcontroller that deals only with "emergency" situations and basic control. There would then be a mid-layer "general learning" system that dealt with optimizing the robot's basic behaviors. At the very top would be a "planning logic" module that deals with big picture, long term, planning. At each of the lower levels, it seems fully reasonable to combine BEAM and digital, at the very top level... I'm not sure.
Martin Jay McKeeOn Wed, Jul 17, 2013 at 2:24 PM, connor_ramsey@... <connor_ramsey@...> wrote:
The energy advantages of conjugating BEAM and microcontrollers in a robot is certainly obvious, but I really do wonder about how many resources it actually saves the program. In a simple two-motor walker, the only obvious software performance advantage is that the program doesn't have to remember how to make the robot walk, the body already knows how, it just needs to know where to take it. This sounds great, but in practice, David's right, the difference in the program's size is barely noticeable compared to what the mc has to offer, and you could just write a single chunk of code that remembers how to walk, and use it like a function throughout the rest of the code. But imagine building a more complicated body, like a 12 motor walker. You can still do the same thing, but the chunk of code that specifies how to control the motors is going to be exponentially larger than before. Applying BEAM to this situation will make a significant dent in resource availability, again with added energy benefits. Now imagine an even more anatomically derived chassis, a biped that has to balance itself to walk. This type of chassis probably would need a much larger chunk of code to control it than before, since it has to work even to stand still, let alone move in any direction, and it would constantly have to run fast enough to simulate a constant feedback loop on almost all of the motors. The code block you would have to write for this would be enormous(at least by microcontroller standards), so a much more overall efficient way to implement control into this design would be to use easily influenced OISM circuits to balance the legs automatically, so that the programmer can write a program just as simple as in the two motor walker if he/she chooses. Although the program could specifically position the body, the underlying circuitry always makes sure it's as balanced as possible. And it also allows the computer to get some beauty sleep.
You know, I've looked into programmable BEAM circuits before. I started at simple BEAM circuits with tunable parts, but the concept went all the way to representing data as points in a wave function. I never really got around to how to store this wave statically using a simple circuit, but the idea was that the wave would travel in a loop. A sensor signal would tune a timer to close the output line at a specific point in the wave. This signal would bias the robot's core, and if the action was successful, the point would remain unchanged, but failure would alter it in some way until it was successful. Basically the goal was to make an uber improvement on Bruce's learning circuit. It would be able to respond uniquely to a multitude of different situations rather than just one. Theoretically the wave could be stored in a res-cap network with analog switches linking the caps to ground for locking a charge on each one when powered off. I figured the gaps between points will fill themselves in, so that if the robot encountered a scenario it didn't know how to respond to, it could try to do something similar to how it responded in the most similar situation it recognizes. The larger the network, the higher resolution the wave could be retained. I figured it might not work that well, though. I just thought of this as I'm writing: instead of storing the wave itself, create a circuit that can perform an equation that represents a wave that represents points of data. Believe or not I've actually had a schematic for an analog arithmetic unit lying around here, and I think I could use electronically tuned resistors as memory devices to program this AU to perform a polynomial algebraic sequence on an input variable to yield the desired data point on an emulated grid chart. This data point would bias a neuron in the control loop, and if it fails, then the equation is altered. I'm not sure if it's plausible, and it's definitely not practical with the advent of today's processors, but no evil mad genius super-scientist like me could possibly resist the challenge. XD. Enjoy, evil mad genius super-scientist Connor.
--- In firstname.lastname@example.org, Martin McKee wrote:
>> The AtTiny85 ( and '25, and '45 ) is, indeed, a very nice chip. In the old
> days I had fun with the '13 but the '25/'45/'85 series are a very nice
> upgrade. I also like the '24/'44/'84 series. It's a 14-pin package
> instead of the 8-pin, but it actually uses slightly less power. I did a
> quick "learn to solder" project with the AtTiny24 and was quite impressed
> with its capabilities vs. price. Another interesting series ( using even
> less power ) are the AtTiny '261/'461/'861 series. They actually include a
> 16-bit timer ( unusual for the Tiny series ) and a high-speed PWM generator
> also. At low-voltages, though, the AtMega328P ( used in the Arduino ) uses
> roughly the same power as the Tinys but it has lots more peripherals. It
> does cost more, however, and a pdip-28 package isn't all that small...
> What I hope, soon ( i.e. when they become available ), to play with are the
> NXP LPC800 series. Much higher running power than the AVRs ( 1mA @ 12MHz
> 3.3v vs. 200uA @ 1MHz 1.8v ) but in sleep they can drop down to the same
> range as the AVRs, ~1uA with a clock still running. And they are 32-bit
> with ( compared to an AVR ) lots of RAM memory ( 4K ). They look ideal for
> something like a learning system that needs to keep track of ( relatively
> speaking ) large amounts of information -- they are also available ( or
> will be ) in a dip-8 package!
> So much for talk of microcontrollers. I've still got designs for easily
> influencable BEAM networks running through my mind. But, I must admit, the
> use of servomotors is proving to be quite a complicating factor... holding
> the network timings in tight bounds with widely varying voltages is proving
> to be something of an annoyance.
> Martin Jay McKee
- << Previous post in topic Next post in topic >>