Re: [beam] Re: Wire Computing? A Theory
- Thinking, thinking...I saw it as well, it shows quite well how adaptable the BEAM mechanical designs can be and also how well processors can be fit into the same thought schema. All around, I think it is a good example of how this could all work together ( even though is is solely processor controlled.As to actuators, I typically prefer gear motors too ( larger metal ones for much of what I do ), but the robot club starts back up in the fall and I'm seriously thinking that I could do something with this idea... however, REALLY inexpensive ( half the price of a GM7 or less ) and repeatable ( due to the built-in control system and pulse control ) are two big advantages in favor of R/C micro servos. It would also allow the same control system to be transferred to much larger robots in the future ( there are some BIG R/C servos at this point! ).
Martin Jay McKeeOn Tue, Jul 16, 2013 at 9:24 AM, connor_ramsey@... <connor_ramsey@...> wrote:
Yeah, that link is kind of what got me started on all of this. I saw it in action and started thinking of how implementing hardware BEAM could benefit the design.
When it comes to actuators, I prefer to use GM7 gearmotors from solarbotics over servomotors, as they were designed by Mark Tilden himself specifically for BEAM purposes. They use nice, low-power, efficient motors, although a bit expensive.
--- In firstname.lastname@example.org, "Lee" wrote:
> I sent this a while back and it but I do not know if you both saw it. It is
> my servo walker based on the 08M2 Picaxe chip. The layout and leg geometry
> is beam based.
> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Martin
> Sent: Tuesday, July 16, 2013 8:30 AM
> To: email@example.com
> Subject: Re: [beam] Re: Wire Computing? A Theory
> There are miracles from time to time!
> I wonder what would be a good test bed for something like this? What I
> would love to see is a very capable walker of some description, and
> something that is easy to reproduce with off the shelf components. The
> ability to use unmodified hobby micro servos ( either the 9 gram or 5 gram
> from HobbyKing ) would be excellent, but these servos are hardly energy
> conscious -- to solar power the system would be difficult at best. It would
> also require a more complex underlying Servocore / microcore like circuit.
> All of which adds up to a more difficult implementation. Nevertheless, I
> could see a "kit" of a robot like this used in the robotics club at the
> University that I've worked with where a simpler BEAM type robot wouldn't
> gain any traction ( you have to realize, these are people that are
> fascinated with advanced quad-copters but are unwilling to learn more than
> basic programming ). Add to that the ability to program the robot using
> something like Arduino, and I think it could be a very easy "sell."
> I can see a few options for the design of a robot: three, four or five-motor
> with or without head. The BEAM circuitry would be fully self-contained and
> would control the system in a basic way, forward/reverse, bump sensors. The
> microcontroller would then connect directly to the BEAM circuits to adjust,
> modulate and control them. I know that the students would benefit from both
> the simple programmablility and from some introduction of discrete
> electronics ( we have issues explaining connection of LEDs... don't even get
> me started on something like I2C bus... yes, it's frustrating at times! ).
> My greatest worry is just that the general inefficiency of the servos would
> swamp any possible efficiency gains from the control system. It would be
> easy enough to integrate a hard power switch ( just a high-side P-channel
> MOSFET ) to the servos so that the BEAM circuit would be able to turn all
> power to the servos off, but a robot that sleeps, unmoving, much of the time
> isn't terribly exciting to many people these days.
> I would agree that a suitable low-level system could make programming much
> easier in many ways. Not having to control the precise movement of each
> actuator frees up quite a bit of the typical programming load. But, the
> interaction between the microcontroller and the BEAM then becomes very
> important. You would want high levels of influencablility without having
> the same "precision" requirements. Otherwise the programming gains are
> simply re-lost. It would take some thinking. But I do think it's an
> interesting problem and one worthy of consideration.
> Martin Jay McKee
- Yeah, the usability bit is a primary focus of mine. Just for fun, really, I've taken an approach at a very traditional style, basically using a set of counters in place of an actual processing unit. At it's simplest, it lacks the hardware to perform Boolean logic operations outside of 1's and 2s complement, but these can still be used to simulate logic functions in a few cycles. It can also simulate bit shifting easily enough by multiplying or dividing by 2. It also places quotients and remainders into different registers for easy handling of remainders. Not to mention floating point math isn't difficult, either. It could even perform <, =, > comparisons between values. As a matter of fact, I can't really say that any electronic computer has ever been built in this fashion. I'm pretty much basing the design entirely on DigiComp2, a mechanical 4-bit binary computer distributed as an educational toy from 1968-1976.
Yes, the 1-bit processor array concept is in fact cellular automata, which is why I refer to each unit as a "cell". I don't entirely understand bandwidth, yet. But the idea doesn't really focus on that. It regards robustness of the system, as well as massive parallel processing without most of the usability problems. I would also think it much more flexible, because a key construct is that each cell can alter its connectivity with its neighbors. It would take several orders of magnitude more component failures to trash the system than your traditional hardware, it could also be incredibly fault tolerant, and I'm thinking on the lines that the entire system would be programmed as a whole, so that determining how each cell should connect can be left up to the OS shell. Also, even if bandwidth restricts how quickly information is processed, another perk of the idea is that a very large amount of data could be processed at once.
On a side note, I once came up with an idea for a machine that was mostly electronic, but stored data temporarily as photon states(like, particle for 0 and wave for 1), and would be able to take advantage of the fact that photons, being 4-dimensional objects, can move in more directions than we can perceive, and thus allow the machine to literally do everything at once. What I mean is that each new cycle would take place in the same time frame as the last cycle, so that it could register an infinite amount of data in about a billionth of a second or so. It would only ever have to go forward in time if it needed to write a result back to main memory or update I/O, because the way it works, the events that occurred in previous steps literally would have never happened, and so the electronic memory wouldn't be able to remember such a result, and the outside world could only observe the final state of the program, if there was one. Fundamentally it is a photon based delay line with a negative delay. As in, instead of the delay propagating forward in time, it "rewinds" time slightly. So the potential would be literally instant computation, a stack of infinite size could be fed into the computer and processed in less than a billionth of a second, and an entire program run could be accomplished in the same amount of time. Branches and subroutines would be included. Only writing data back to memory or porting to the I/Os would really take any time at all. Only the program's final result could be observed from outside, as each step in between would never have happened in our timeline. Also, the program counter would have to be photon based, somehow, since if it was electronic, it wouldn't be able to remember what program line to go to next after time was rewritten again. The only thing I can see being interpreted as dangerous with this is that it does, indeed, rewrite time. But it only rewrites about a billionth of a second each time, and it doesn't effect outside events whatsoever. It has absolutely no way to affect reality.
> For myself, life is catching up with me. Come Monday, I'll be starting a
> new degree ( one not even tangentially related to my first ), so I've been
> rushing around trying to get all that in order -- no time for seriously
> thinking about robotics at all.
> I've only got a minute or two now, but, some few comments. The massively
> parallel 1-bit processors sounds a bit like a cellular atomaton type
> system. I remember having see once ( but can I find it now? of course not!
> ) a computer system that was being developed in that vein, compiler and
> all. There is certainly potential for quite a bit of performance, but for
> maximum performance, the bottleneck is often memory bandwidth, and not,
> strictly, computational. A large number of processors with a handful of
> neighbors and a 1-bit interconnect is not going to help in that line.
> To be honest, much of the architecture design lately has been targeted at
> increasing performance ( adding parallel instruction sets, vectorizability,
> hyperthreads, etc. ) but because of memory access issues and programming
> concurrency issues, simple small instructions and a minimal set of fully
> atomic instructions has seemed to have the best balance of usability and
> performance. No one has really been able to demonstrate an architecture
> that is both highly performant and efficient in the face of concurrency (
> and many parallel computational units ) while remaining easy to program. I
> think what can be said about "traditional" architectures, is that they are
> easy to understand and they work "well enough."
> Back to work...
> Martin Jay McKee