Evolution is a fact of life, except in Kansas. It is the defining characteristic of life itself, but that doesn’t mean a stupid robot can’t evolve. For his entry into the Hackaday Pi Zero contest, [diemastermonkey] is doing just that: evolution for robots built around microcontrollers and a Raspberry Pi.
[diemastermonkey]’s project is a physical extension to genetic algorithms. Just like DNA and proteins have no idea what they’re actually doing, microcontrollers don’t either. Instead of randomly switching up base pairs and amino acids, [diemastermonkey]’s project makes random connections pins depending on the values of those pins.
The potential of these crappy, randomly programmed robots is only as good as the fitness function, and so far [diemastermonkey] has seen some surprising success. When putting these algorithms into a microcontroller connected to a tilting table mechanism and a PIR sensor, the robot eventually settled on a bit of code that would keep a ball in motion. You can check out the video of that below.
The Raspberry Pi Zero contest is presented by Hackaday and Adafruit. Prizes include Raspberry Pi Zeros from Adafruit and gift cards to The Hackaday Store!
See All the Entries
We often see “logic analyzer” projects which are little more than microcontrollers reading data as fast as they can, sending it to a PC, and then plotting the results. Depending on how fast the microcontroller is, these projects range from adequate to not very useful.
At first glance, [esot.eric’s] logic analyzer project has an AVR in it, so it ought to be on the low end of the scale. Then you look at the specs: 32 channels at 30 megasamples per second. How does that work with an AVR in it?
The answer lies in the selection of components. The analyzer uses a 128MB SDRAM DIMM (like an older PC might use for main memory). That makes sense; the Arduino can’t store much data internally. However, it isn’t the storage capacity that makes this choice critical. It seems [esot.eric] has a way to make the RAM “free run”.
The idea is to use the Arduino (or other host microcontroller) to set up the memory. Some of the memory’s output bits feedback to the address and data lines. Then the microcontroller steps aside and the SDRAM clocks samples into its memory by itself at the prevailing clock rate for the memory.
Of course, this isn’t good for things like complex triggering, and you give up some memory storage to the control “program” (if that’s the right word). However, it is easy to see this technique being useful in other cases where you want to offload the CPU for repetitive data transfer. For example, [esot.eric] has also used this method to drive an LCD panel.
Just to prove the point, the video below shows the device working even after the AVR microcontroller is removed. It is only necessary during the setup phase. Admittedly, the logic analyzer part isn’t the cool part. If you want a logic analyzer, pick up a DSLogic from the Hackaday store or one of the many other inexpensive ones out there. If you want to roll your own, there are plenty of options for that, too.
But for sheer audacity and dirty trickery, you have to admire how this design uses an SDRAM in a unique way. It makes you wonder what other components we could use in strange ways.
I was re-watching Iron Man recently and noticed something interesting. During Iron Man’s first “boot up sequence”, in the “terrorist” caves of Nowhereistan, some butchered C code is displayed on a faked up laptop screen.
The code displayed on screen, although missing some syntactically important characters such as semi-colons, is actual valid C source code. So valid in fact that I wondered where it came from.
Read the original post to find out the Iron Man/LEGO connection.