Let's Make Robots!

Self Charging Swarm Communication

Alrighty quicky background. I'm one of the founding members of a highschool level robotics team, and I'm currently in college for electrical engineering, to go into robotics. I have some background in robotics :D, but my question is new ground to me. Swarm robotics have always seemed awesome to me, so once my new programmer gets here in the mail I'm going to start a new project.

To start on my project, I want to make a small self charging robot, that still can communicate with other robots. Communication with anything beyond a singluar controller is a new field to me. So can anyone give me some possible ideas for me to start researching? I'm vaguely familiar with the different types of communication possible, but I don't know how effective in small scale robotics they are, ease of implementation, cost, or if any of them would conflict. Oh, I also intend for this to be in a controlled environment, plywood with walls kind of deal.

 And don't worry, you'll get pictures once this bot gets life. :D

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

You could try searching the web for some of Wilf Rigter's power smart designs. Start at www.solarbotics.net/library perhaps.


My fault.

 I meant self charging, as in self-docking to a charger. Not renewable energy sources :D

Sorry bout that. Thank you for the name though. His stuff does seem fun. I may read up on it more later.

I am also interested in this combo. I do not see a contradiction between communicating and auto charging. Rather a necessary combination. I regard the charging station as a (stationary?) robot. The two bots "communicate", if only in order to find each other (beacons).

There are some options already discussed on this site. I am not sure if anyone is already trying something out. Time will tell.

About comms:
Look at easy radio. If you have that sort of budget, it might help you get a serial communication up and running, well, easily.
Check out everything tagged "radio control".

About self charging:
This is really two tasks - power management (wait for the next Pulse or do a power search) and locating a power source.
Locating anything can be done by many different means. Machine vision is hot, but also hard. Beacons can be radio or infra red and are discussed here. IR comms can be as easy as using a TV remote. It would not be too difficult to combine a beacon and more intelligent comms. Serial talk from micro to micro is discussed all over the site.
Finally a link outside LMR: I've been saving this for the day I start my bot and make it auto-recharging.


You sir, are amazing.

 First of all, thank you for the idea that a docking station is only a stationary robot... that simplifies my thinking greatly.

Ok one this thing still confuses me about RF. Well here is an example. Lets say we have Bot A, whining that its lonely. Bot B, is telling Bot A how it doesn't care. All the while the docking station is advertising to the world it has some free lovin' to pass around. (This is only a theoretical. This would never happen, because I intend to have the bot ask the station where it is, instead of just constant transmission) But the question is, How badly would everything being transmitted get jumbled up?

@rik, I'll make sure to keep you updated on anything interesting I find out since you have a similar project planned :D

Thanks for your kind words.

Do I understand your question correct? You are wondering if three robots transmitting at the same moment would jam each other? Effectively cancelling everything. 

If so, study ethernet. It has the same problem and solves it with "collision detection". Google for Aloha Net as it taught me to understand the same issues vv. Other networking protocols work around this problem. Token Ring for example only lets one node transmit at any time.

All this requires quite a bit of high level programming. That is no good. Even if you feel challenged by that, it would eat a big chunk out of your tinkering time. We cannot have that!

Instead, play the odds. Make your transmissions short and far between. Chances are that nothing gets disturbed with just three or four nodes claiming the same ether as a medium. And for that one time a day when it does, retransmit.


In high school I took a crash course that was supposed to prepare us for A+ and some type of cisco certification. I guess I just wasn't thinking sideways.

Reading about Aloha Net, and CSMA/CD gave me two idea's that I think would be fairly easy to implement ontop of what I planned to do. First of all, just listen to see if someone else is transmitting. Second of all I originally intended to send a packet that included a destination ID, an instruction, and a sender ID. Fairly small each of those sections would be 6bit or less. But my new idea is to make sure there is always a back and forth between the two bots. If a sender doesn't get a response back, it will just re-transmit (after a slightly random wait time if possible, to deter against infinite loops of two bots trying to send at the same time. Not likely, but worth the extra little bit of deviation). The last packet will just be an empty packet to say the reciever got the previous packet, but won't expect a response for the empty one.

I think those couple things will be easy adds, to significantly increase throughput. And if it takes more than a couple highly caffinated nights to impliment, I'll change it up later.

I like the idea of just playing odds :D  but I've got a professor I need to impress the pants off of also. I need to balance those two factors ;D

 Another idea that the Aloha Net gave me, was when the hub detected a collision, a jamming signal was sent out to all the nodes, to tell to resend. A later implementation I'm going to work on, is control from a PC. (Somehow I'm thinking it would be techy sin to not when it would be this close). When I want to say something from the PC, I can send out a jamming signal (I'm thinking a packet repeated two/three times), that would take over the communication, and tell all of the bots to be quiet and wait for instruction.

Thank you again, but this time I don't have any questions yet :D Other than your opinion of my new ideas.


Sounds like what I was imagining.

And impress your professor with a

int kiss(n) {
   if (impress == ENABLED) {
      /* very elaborate csma/cd code here */
   } else {
   return passing_grade;

You can show off your programming skillz in the first piece of code and the abundant documentation that comes with it. And then you impress him again by disabling that code and demonstrate equal effectiveness by just playing the odds.


I love it.

This project isn't for a grade or anything like that, there is just a robotics specific professor at our campus. Having her interested in my projects would be a very helpful boost to my career, in knowlege/connections. Plus she's fun, She got in trouble in college for programming an industrial robot (huge ton machine) to follow her around. 

why not use something like xbee for your comunication

there are quite a few PCBs made for it already and lots of projects that use them as well


In short, because I'm poor.