Re: [beam] Re: Tekno
- I think part of the appeal of BEAM robots is how quickly they can be prototyped and tested, compared to traditional robotics that seem to require far greater up-front investment. For that reason I was drawn to BEAM, and I think that if others also find that part of BEAM robotics most appealing, they would also be keenly interested in prototypes, examples, small built things to look at.Connor, if you were to build an example of what you describe, I agree that it would be incredibly cool to see. I, among others, would quickly demand videos, schematics, photos, explanations, and all sorts of other things that would drive discussion and generate interest. So, please take a shot at it, give it your best shot. Plan a bit, build a lot, inspire others. I've gotten busier but still attempt to create a new BEAM-ish bot every summer or winter to add to my collection, and I always tend to adapt whichever is the coolest bot I've seen lately. Wolfgang's intuition is correct for what generates engagement.GrantOn Thu, Aug 29, 2013 at 10:41 PM, winglabs_inc <connor_ramsey@...> wrote:
Thank you for that, Wolfgang. I really don't know why, but BEAM just makes me more excited than traditional robotics. I think perhaps some of my ideas have been better than I've given myself credit for, as I have a tendency to move on to new ideas quickly.
Indeed, Mark's bots far surpass today's BEAM standards. Perhaps the problem with BEAM is that it progresses in the opposite direction of mainstream tech, whether or not that was the original intent, this has come to be just as counter-intuitive as it sounds.
And as a matter of fact, I do have a number of sketches stashed away in a drawer, many because they wouldn't have worked in reality. But many amongst those are finished designs that I simply haven't bread-boarded. Perhaps I should upload some of those to the group photos. I also have conceived many concepts that I found difficult to express in circuitry, and most of the unworkable designs I have are attempts at physically implementing these.
Concepts like a version of Bruce's learning circuit that tunes itself according to a dynamically realized probability in order to process its responses under different biases according to different conditions. In theory it could be more applicable in some areas than a digital processor, and I even have a memristor-based non-volatile memory circuit that implements arithmetic coding to compress large amounts of data down to two values: the probability of a Boolean 1 being extracted, which also acts like a superposition in that it also represents every other possible sequence of digits that could be measured under that probability, and the measurement value, which interacts with the probability to determine and read a specific state. In principle it could be compared to a quantum machine. It would make learning very easy because the machine would simply have to alter the measurement value slightly, which would cause the machine to "guess" what it is supposed to do based on how similar the unknown situation is to the most comparable familiar situation. If it's wrong, then it alters the probability value slightly until it reaches a correct guess, while minimizing impact on established memories. All I would have to do would be to wire in a series of these in place of the "long-term memory neurons" in Bruce's learning circuit, and add some form of external situation analysis, likely Nu based, then hook it up to BEAM body w/nervous core, and out comes the single most sophisticated BEAM bot ever, and possibly the most cognitively capacitive machine built to date. I really should upload a schematic of that.
--- In email@example.com, "David Buckley" wrote:
> Well I read them all.
> Now I am sure a lot of us have mountains of such ideas stashed in boxes somewhere.
> The reason they are stashed away is that they are history, they were dreams, they were not realisable, generally they relied upon some unavailable technology so not being funded by DARPA posed a problem.
> I noticed in one of the posts (unless I am mistaken) the modern idiom of 'I have made' when really the phrase should have been 'I've noted down some rough ideas'. People do it all the time 'see what I have made' and it is a drawing in CAD which is obviously never going to work in the real world.
> For Beam to survive it has to show it has something to offer. So far I have not seen any Beam critters perform better than those of MT let alone perform as well as processor based robots of today. Even a $30 or so servo based quadruped kit walks better than MT's Spyder and has a far richer behaviour.
> So Wolfgang, you are right, building something is the crux of the matter.
> ----- Original Message -----
> From: J Wolfgang Goerlich
> To: beam
> Sent: Wednesday, August 28, 2013 9:11 PM
> Subject: Re: [beam] Re: Tekno
> "You know, I was kind of figuring that would have been met with a greater response. I must be alone on here again."
> Build. Share. Repeat. I have seen, over the years, that process is the best way to engage (and awaken) the BEAM community.
> I feel your excitement. I see your posts. You have some great ideas. Now it is time to go forth and build.
> I look forward to seeing what you share.
- Thanks, I appreciate that. For now I'll try and upload a rough schematic of the device, but I really do want to get the real thing working. I think it would provide a good example of just how great the capacity ratio is between neural and digital processing. Most of the reason why BEAM is popularly conceived as inferior technology is because it's almost always realized in discreet circuitry. What most fail to see is that if a neural circuit was minimized to the scale of integrated components, its performance would far surpass any digital circuit per U^3 of space, even if it couldn't do nearly as much. Thus the only drawback is that neural networks don't mostly consist of repetitive patterns of circuitry. And problems like research grants and funding are just run-of-the-mill obstacles that I think every worthy technology has to overcome.
So anyway, I joined "the Robotics Club" group, figuring it more likely that someone on there could help me with Tekno, only to find that no one has posted there since last year, and the posts before that were barely semi-annual. That and the message I attempted to post hasn't been posted yet, as it has to be approved first, so I'm probably looking at another year before the message even gets posted, if ever, let alone anyone seeing it.
Also, I built a Carry-Look-Everywhere(CLE) adder/subtractor, which is a form of binary adder, and I find that it has some strange properties compared to a typical binary adder, specifically regarding subtraction. Ripple-carry adders, and every derivative thereof, will readily accept a 1's complemented integer and add a positive integer to it, resulting in basic binary subtraction. Even carry-look-ahead adders consist of congregated ripple-carry stages in conjunction with a separate CLA unit. But while in concept the idea of CLE logic is similar to CLA logic, in practice a CLE adder is built very differently than any other type of adder, as it is not a derivative of ripple-carry logic like most adders. So while it is far faster than most adders, I've encountered a unique quirk with the CLE unit: it inverts its result while in subtraction mode. So I had to add another multiplexer at the other end of the adder to un-invert differences. When I did this, however, I found that the adder is actually operating under 2's complement, whereas almost every other adder operates under 1's complement. Which also means it can translate any 1's complement integer directly into 2's complement format. I think the bug that inverts differences is caused by adder mistaking negative integers for very large positive integers. Because of this, when the adder underflows, it wraps around to the "highest" value, which is actually the lowest negative value, and the reverse occurs when the adder overflows. So it ends up outputting a value in the opposite quadrant from 0 than the correct result. It's not a problem, because a simple inversion will solve this quickly. But I still didn't realize that CLE adders worked on 2's complement. To me, that actually makes it even better that ripple-carry derived adders, because 2's complement lacks -0, and thus includes a slightly higher range of values, and also because signed negative integers are processed identically to their unsigned positive equivalents. This means that signed integers are actually ambiguous, and a programming language can refer to them either as their negative value or as their positive value, which is 2[-x]. Another weird thing about CLE logic is that it actually uses the carry-in and carry-out bits as negative indicators, allowing the system to represent twice as many integers as it normally would. Actually three times, if the par of a signed value depends on context. My adder is 8-bit, so that's 512 values, plus signed ambiguity, which adds up to 768 representable integers! Though a language would have to be specialized to provide context for ambiguous data.
--- In firstname.lastname@example.org, Grant Nelson wrote:
> I think part of the appeal of BEAM robots is how quickly they can be
> prototyped and tested, compared to traditional robotics that seem to
> require far greater up-front investment. For that reason I was drawn to
> BEAM, and I think that if others also find that part of BEAM robotics most
> appealing, they would also be keenly interested in prototypes, examples,
> small built things to look at.
> Connor, if you were to build an example of what you describe, I agree that
> it would be incredibly cool to see. I, among others, would quickly demand
> videos, schematics, photos, explanations, and all sorts of other things
> that would drive discussion and generate interest. So, please take a shot
> at it, give it your best shot. Plan a bit, build a lot, inspire others.
> I've gotten busier but still attempt to create a new BEAM-ish bot every
> summer or winter to add to my collection, and I always tend to adapt
> whichever is the coolest bot I've seen lately. Wolfgang's intuition is
> correct for what generates engagement.