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

61189Re: Wire Computing? A Theory

Expand Messages
  • connor_ramsey@ymail.com
    Aug 1, 2013
      Well the biggest advantage behind a colony of robots composed of simple Braitenburg drones and a high level queen, is that there's far less overhead on the manufacturing process to create the drones. Constructing a drone in a traditional concept would require the resources to print all the circuit patterns for each computer "brain" for each drone, have enough digital memory to store the patterns for the circuitry, the program for each drone(unless it's hard-wired into the ROM), and the equipment necessary to produce the hardware. Versus constructing simple Braitenburg drones, which only requires the production of simple discrete components and a simple mechanature, and the software resources to recall how to assemble these together. If the queen is being used in a mining or salvage operation, then the cost of the drones should be minimal. In general, the net worth of each drone will be considerably less than a digital drone, because the queen doesn't have to put as much effort into their construction, and the queen itself will become a cheaper piece of equipment. Basically the point is to minimize resource overhead for the drones.
      But yes, I find simple robots to be more fun than many digital bots. Although I wish that Hexbugs would come out with a better bug. Like, one that could move in more than two directions. Or have a more adept mechanature. Honestly, they're almost a step down from BEAM. Despite the fact that their circuits seem to use more components. I mean, seriously, I wish they would just pump out a nice, neatly trimmed bicore walker in a plastic exoskeleton, with photodetectors and microphones and feelers and everything, and make everyone happy. Whether it be one or two motors. Heck, even a beetlebot on legs would satisfy me.
      Oh, and I've been working on a digital hardware system the encodes and decodes a data word in a single register, using arithmetic coding. It's SO complicated. The register is very simple. But the decoder stage just gets more and more complicated. First there's the multiplier, which utilizes the "shift and multiply" algorithm. For a 16-bit register I need a 32-bit adder, but it can't just be a ripple-carry adder, because that takes too long, and it can't be a carry-save adder like is often used in multipliers, because each successive product needs to be analyzed individually. So I'm going with a carry-select adder, because it seems to be the simplest adder that offers high-speed performance over ripple-carry. All the multiplier does is exponentiate the word in the register in integrals. But then there's the addressing system. The imaginary storage space in the register is accessed via content, hence it emulates CAM more than RAM, because the files are actually stored by bit similarity. The earlier a file deviates from another, the farther away it is located. The problem, though, is that it would take a very long time for the machine to look through every single file(the imaginary space is laid out in files. In a 16-bit architecture, that's 65,536 8Kib files, or 512Mib total), so the address pointer has to predict where a file will be located, that matches the search word, and then somehow skip the multiplier along by the number of bits the pointer wishes to skip. In theory it's not very complicated, but in terms of designing the circuitry gate by gate, the decoder is absolutely monumental, especially because it has to achieve high performance in order to keep up with a decent processor speed. And I have a feeling that the encoder stage won't be much better. So now I'm very convinced in my stance on the analog variant.
      Enjoy, Connor

      --- In beam@yahoogroups.com, Martin McKee wrote:
      > I agree whole-heartedly that BEAM still has great potential, even if it is
      > just for fun. It is the same everywhere... why duplicate simple CPU
      > architectures in discrete logic or FPGAs? There is not "advantage." Why
      > create yet another imperative programming language. But, more than just
      > for the play aspect, I think it is important to consider the fact that
      > people learn most effectively when they are playing. We do it all the time
      > as children, and it's okay. As we get older, play starts to become a bad
      > word, but the way our brains are wired doesn't change. Sometimes, doing
      > "simple" things just for fun is the most efficacious way to move forward.
      > It can get one's brain out of a rut and lead you to new discoveries.
      > I have become quite aware, over the past few years, how powerful
      > non-traditional use of sensors can be. By rearranging them one can force
      > particular behavior or avoid weaknesses ( blind spots ). A combination of
      > flexible control circuitry, careful sensor layout, and careful tweaking,
      > certainly do show their potential in the spider bot. The behavior of the
      > robot is, as you say, quite complex and impressive. Sadly, it wouldn't be
      > able to handle much from a mechanical standpoint. Even the "obstacle" test
      > ( with chop sticks ), is fairly simple to achieve. I would be surprised if
      > it were not almost immediately stuck when placed in a real natural
      > environment. But that's not the point. The mechanical design could be
      > expanded and the same concepts used to control it. The result would be a
      > more capable robot. The question becomes one of how much work is required
      > and what the perceived benefit is. If the benefit is that one has fun in
      > the process, anything is justifiable. And anything can add to
      > understanding.
      > Martin Jay McKee
    • Show all 60 messages in this topic