Does this project spark your interest?

Become a member to follow this project and don't miss any updates

The Emergence Project

An experiment in group machine intellegence
(Or lack thereof...)

Similar projects worth following
This project is submitted for

This project was created on 06/28/2014 and last updated 18 days ago.

The original impulse for this project was to make solar powered BEAM-style robots that would dart from light spot to light spot continually recharging themselves before moving on. As we were contemplating how to do this, we decided the use of a microcontroller was all but inevitable, and we wondered how we could utilize it's capabilities. At this point we began to run into the concept of emergence.

Emergence: In philosophy, systems theory, science, and art, emergence is conceived as a process whereby larger entities, patterns, and regularities arise through interactions among smaller or simpler entities that themselves do not exhibit such properties.

In other words, emergence happens when a group stops being just a collection of individuals, and starts to become a flock, or a hive, or a nest.

Our intention is to build a small swarm of robots and see if emergent behavior arises through their repeated cooperation and interaction with each other.

The idea is to build a number of small (palm sized), simple (using the BEAM 'less is more' philosophy), and relatively inexpensive ($50 is the target) robots, and give them the basic abilities to communicate with each other and adapt to their environment. The idea is to see what kind of complex social behavior we can coax out of a multiple of relatively simple machines, and hopefully be surprised by something we didn't explicitly program them to do.

The 'bots are eventually going to be solar powered. They will sit collecting energy until they have enough to run through a movement or communications cycle. When they decide to move (the target is to have them move for 15-20 seconds every 15-20 minutes) they will wander randomly for the first half the cycle to ensure that they spread and explore. During the second half, they will realize that they're 'hungry' and will use light detection to head for the brightest area they can see, bettering their chances of recharging quickly.

A few of the settings (ones for, say, motor speed or level of contrast it looks for when seeking light) will be left for them to decide for themselves. When they sit out a cycle and go into a communications phase, they'll use small radio transmitters to broadcast their efficiency level, and what their settings currently are. All the other 'bots in the immediate area will compare their own efficiency to the one broadcast, and nudge their own settings closer to the broadcasting 'bot's, or ignore them if they're doing better. Eventually, this yes/no better/worse behavior should help each other find the best settings for whatever environment that they're placed in.

To ensure that the 'bots go through the full range of their settings, random mutations will be introduced into their settings. Mutations that prove beneficial will spread through the swarm. The ones that don't will disappear within a few hours or days depending on how often they interact with their hivemates. This presented us with the first behavioral question we ran into before we'd even begun: Can the 'bots even exist individually? We didn't explicitly set out to design this behavioral aspect in, but a single 'bot might not be able to. It will still generate random mutations in it's code, but without at least one companion to compare it's efficiency with, it might get itself so far out of whack that the amount of power from sunlight it gathers during the day won't be sufficient for it to survive the night.

As for how the rest of the 'bots will spend the night, some members of the swarm may find themselves in a slightly better position than the rest. It may find it's way to a light that's been left on, or a bright spot beneath a window from a streetlight outside. If it manages to find one of these 'it's better than nothing' sources, it will remain in place and turn it's IR LED fully 'on'. This acts as a beacon for the rest of the members, who use the exact same light seeking script that they use to find sunlight during the day, except the brightest light it sees and steers towards is it's hivemate, and not the sun.

Once we get the 'bots built and programmed, we will wait and see how they act. Will they run about randomly during the day, or will they migrate from one side of the room to another following the sun's arc? Will they tend to roam alone, or will they travel in a pack? What happens when they reach a homeostasis with the environment we put them in? Will 'bots who have the same settings act exactly alike, or will individual traits arise? Will 'bots that live upstairs in the electronics area settle on the same settings as 'bots that live in the workshop, that gets no natural light at all? What happens if we introduce code that causes not just mutations in their settings, but also the code that they use to communicate...

Read more »


Project logs
  • Bouncin' Right Along...

    11/09/2015 at 03:31 0 comments

    Greetings True Believers! A quick project update...

    We've finally, positively identified the gremlin that's been plaguing the project for so long. As we've long suspected, it was something simple that our Fearless Leader managed to overlook while doing his pre-project research. This phenomenon is known as 'contact bounce'.

    When mechanical switches like the ones we use for obstacle avoidance are tripped, they don't make positive contact instantaneously. In that split second it takes to go from 'off' to 'on', it may arc hundreds, or even thousands, of times. This understandably freaks out the controller, making the action it decides to implement erratic. It also explains why the problem seemed to be getting worse over time. When we thought the problem was faulty switches, we were replacing the relatively expensive switches we had bought for the prototypes with the cheaper ones that we're going to use for the swarm. The more switches we replaced, the worse the problem got. The worse the problem got, the more switches we replaced, and so on.

    Now that we've gotten the problem identified, we need to do two things:

    First, we need to eliminate the noise. You can use capacitors to try to smooth out the noise, but most of the material we've read on the subject suggests that it's easier and more effective to take care of the problem in the software. That's the tactic we're going to try first.

    The second thing we need to do is to throw an evil glance and a wagging finger at you, True Believers. We know some of you out there are electronics gurus. You could have spoken up when these problems began, but you chose to let us fumble in the dark for months. We place this whole affair squarely on your shoulders...

    It's all your fault...

    Shame on you...

  • Success in Failure

    10/22/2015 at 05:26 0 comments

    Sometimes you just need things to go wrong so you can eventually get them to go right. It seems that our latest frustrating setback might have an upside, though. First off, we decided to give our original prototypes, Frankie and Johnny, a rest since they'd been crosswired, changed, shorted out, and otherwise abused during our first round of building. We decided that the first 'bot to use the final electronics should start over as a blank slate. We randomly selected one of our future swarm, and it turned out to be 'Jan'.

    We went back to the breadboard, so we could iron out any systems intigration problems with the new components easier. But, an old nemesis came roaring back: intermittent and often random problems with the obstace and edge avoidence. But, it seemed a bit different this time. With the new Arduino Mini Pro controllers, it wasn't as random as it was with the previous controller. It wasn't working any better, but it was more consistent. We noticed that when it acted up, there was a delay before it would begin to move again. It was exactly the same delay we built into the beginning of the program to give us a chance to put the 'bots on the floor before they started off. It seems that the microswitches we use as obstacle detectors generate either a voltage spike, or enough EM noise, to make the controller reset itself. This was both disheartening and encouraging at the same time. We may still have a problem to resolve, but FINALLY know what's causing the problems to begin with.

  • The Emergence 'Bots Roll Again

    09/28/2015 at 03:30 0 comments

    True Believers! The Emergence Project is back in gear. Our Fearless Leader is a season-ticket holding Chicago Blackhawks fan, and their successful Stanley Cup win left the project a bit scarce of both initiative and disposable income. However, the project is gathering steam once again.

    After having so much free time to think, we've made a couple of changes. First off, the operating voltage. When we last heard from the 'bots, we were switching from the original 5v to 3v, to keep everything consistant with the new charging boards and batteries. We're changing back to 5v. It was a nice idea, but two things prompted the change. First, we managed to find a 5v step-up board that could bump the power components' lower voltage to that of the 'bot's nervous system. We didn't initially want to do this because we were worried that the conversion would be inefficient and cost precious power, and more components adds cost and extra points of failure. But, we happened across a new board that wasn't available when we changed things, and claims to do it efficiently without breaking the bank. We'll see if they're telling the truth...

    The second change is to the communication system. We've scrapped the IR pulses in favor of FM radio. We've been kicking the idea of going to radio since the projects inception, and it became apparent that it was likely a better system. When the Emergence 'bots were initially concieved, we imagined that they would communicate with each other via sound, sending information chirping like crickets. Radio is actually a bit closer to the initial concept, since it has the ability to go a fair distance, as opposed to infrared, which need line-of-sight contact. Another advantage is that with radio, we can have another reciever listening to the cross-talk, recording an log of exactly who is saying what to who, and when. Lastly, the radio transmitter and reciever aren't all that much more expensive IR components, and they will plug in neatly to the same Rx and Tx pins on the Arduino.

    Well, that's the news for now. We'd like to thank all the True Believers out there that have stuck around during all the stop, start, then stop again road the Emergence Project has been on. As for the new True Believers, welcome! Hopefully the road ahead will be a bit less bumpy...

View all 23 project logs

Enjoy this project?

Adam Fabio wrote 07/07/2014 at 05:55 point
Great project Greg! I miss those old BEAM bots. Thanks for entering your robot in The Hackaday Prize. Keep the updates coming! can't wait to see when you have the solar system working!

Are you sure? yes | no

Greg Daneau wrote 07/07/2014 at 06:57 point
Thanks for your vote of confidence Adam! I believe I may have bitten off a bit more than I can chew, but I've already taken the leap. I'll be sure to keep the updates coming, I'm sure there will be plenty of entertaining misadventures to come!

Are you sure? yes | no

Similar projects