Let's Make Robots!

Live soccer robots on LMR

Recently Gareth suggested to me that it would be good to have 2 teams of my bi-ped robots playing soccer. This was too good an idea to ignore.

After talking about this idea backstage this is where we are at:

On behalf of DAGU I will donate 6 Mini-Biped robots (plus spare parts) and an Arduino compatible IR transmitter to control them. Frits has volunteered to host the robot soccer match. Players would control the robots from their homes via the internet and the video would be streamed on LMR so the players can see what their robot is doing.

What we need is someone who can write some simple software to be loaded on the player and host computers.
The software for the the players will take keyboard commands (e.g. Cursor keys and spacebar) and send this information via the Internet to the host PC.
The software for the host computer (preferably mac compatible) will receive the data from the 6 player computers and send it to the Arduino compatible transmitter as serial data.
The data only needs to be a simple code such as the number 1-6 indicating which player has pressed a key followed by a letter A-E indicating which key was pressed.
A = forward       
B = backward
C = left
D = right
E = stop / kick
Thus the data stream would be something like 0D1A2A3E4D5C etc.
These robots are small, slow and clumsy so while the game will not be fast and furious I hope it will be fun to watch as well as to play.



Below is an explanation of how I will be programming the Arduino transmitter which will receive serial data from the host computer the same as it would using the serial monitor built into the Arduino enviroment. The Host computer will simply pass on the data it receives from the players computers.

Because the IR receiver needs to receive at least 14 pulses at 38KHz to recognise a 1, the Sony protocol uses 600uS as the width of a data bit and 1200uS as the width of the start bit. These times could be shortened but that could reduce reliability so for now I will stick with them. Beyond that I am ditching the Sony protocol which has 7 data bits and 5 device bits for a shorter, faster protocol.

I will write the Arduino code to send out 1 start bit, 3 player ID bits and 3 command bits. This will allow a maximum of 8 player and 8 commands. For now we will only have 6 players and 5 commands.

The Arduino will poll the player IDs thus the first 3 ID bits will count 0-5 repeatedly. The command sent out will be the last command received for that robot.

Each robot will be programmed with it's own ID so for example when the code 1A is sent out, all robots will receive the code but only robot 1 will respond and walk forward.

Because the slow IR transmission presents a bottle neck to the flow of data it would probably be best if the program running on the players computers limited the rate it sent command to 10 commands per seccond. This is fast enough to ensure a reasonable response time but will prevent the Arduino serial buffer from overflowing.

7 lovely red robot brains sitting on my desk. The main PCB is a simple little Arduino compatible board. The smaller PCB at the back is his "backpack" with speaker and IR comms hardware. An IR compound eye plugs into the front. I should have 7 little robots on their way to Frit's house next week. The seventh is a spare, just in case.

I've dubbed them the 7 dwarfs.
Here are some links to video of the prototype so you can get an idea what their soccer skill are like :P

RC chasing a ball: http://v.youku.com/v_show/id_XMTg0NDMxNTY4.html

Autonomous goal keeper: http://v.youku.com/v_show/id_XMTk5NDY1MTcy.html

Update: 20-09-2010

I have upgraded the Game Transmitter hardware and software to allow the pan/tilt assemblies to fire lasers (or other weapons) at the players. Lets be honest, no robot competition is complete without laser fire!

I have attached the code for both the game transmitter and the soccerbots. Currently the soccerbots will accept commands from both the game transmitter and a TV remote. The TV remote allows the host (Frits) to calibrate and test the players without a computer. The players ID can also be entered by TV remote so that if a player dies during a match Frits can quicky replace it with the spare robot just by changing the spare robots player ID to that of the dead robot.

Calibration settings and player ID are stored in the robots EEPROM so that the data isn't lost when the robot is turned off.

Update: 22-09-2010

As the famous saying goes, the devil is in the details! The seven dwarfs are not accepting commands from the game transmitter. As they work fine from the TV remote I have to assume the problem is with the transmitter. On the oscilloscope the transmitter seems to work fine with a nice modulated 38KHz signal.

Until I can sort this problem out the Dwarfs are staying in China :(



Update: 22-01-2011

Well they are finally in Frits's workshop. If nothing else Frits will learn a bit about Arduino. I did a lot of last minute stuff before I sent it all out and forgot the ball in the process. Now I need to get some instructions together for Frits.

I've taken some of Frits's photos and labelled them so every one knows what all the thingys are.

The Mini-Bipeds are normally sold pre-programmed for use by younger robot enthusiest. Therefore a programming cable was not produced. As Frits's will probably need to update the code a few times I quickly made up a cable. Experienced users can make a serial cable quite easily or use the ISP socket.


Soccerbot_transmitter_V2.zip2.35 KB
Soccerbot_V1.zip3.7 KB

Comment viewing options

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

The host should stream video  in a specific port .

I tried to find something about processing

and the only solution i found

is to convert the video that comes from the camera into udp packets and then send them through internet to a client

wich will receive the packets convert them again to video and play them

on screen.

I think it's best to stream the video through some existing streaming service (uStream has been mentioned but it's no good for LMRers in CN). If the host sends video stream to every client it could be quite a bandwidth hog and/or viewing would be limited only to players and that's not fun. Of course I'm not sure what kind of connection our kind host Frits has :-)


AFAIK Fritsl is a MAC user. Maybe Quicktime Broadcaster or Streaming Server is an option for the video streaming part. This would eliminate an extra streaming service and some of the delay. But I don't have any experience with that kind of stuff.

You could look at a distributed system such as peercast or freecast, that would vastly reduce the required bandwidth.

edit: and be somewhat immune to censorship

How about something like this?
I called it a "Player".
Currently, it will take keyboard input and send it to a Arduino, which in turn controls several servo's.
It can run as an Applet so a standalone Java app.

I was working on something else, until I read your post this morning and kind of retro-fitted some pieces together.In either Applet or Java application it can run remotely.The server part I was going to call "SoccerGame" and that would have the Arduino part in it.

You and Frits might want to clear up a few parts:

  • Authentication? Should users register or not?  The players have to be uniquely identified - this could be done with authentication to a current Drupal account - or should the player be anonymous?  
  • Time span - how long will the players have to play?
  • How will players be matched with users?  First come first serve?  A queue?  Should people who want to play but can't at the moment have a estimated wait time?
  • Do you want the ability to call foul on a player and shut them down?  Yellow flag red flag?
  • I know I'm a dumb American, but isn't this supposed be called Futball ?

video here -> http://www.youtube.com/watch?v=OF7n0Hq8sMU
currently I have one click = 1 servo increment or decrement (I have it mapped to arrows too - but this could be changed easily)

A few questions I have :

  • what is the hardware on each robot? Another Arduino or something your putting together custom?


You have a nice GUI there. Looks way better than mine :-)

A quick and dirty solution to authentication could be "per match" user ids/names and passwords. Those could be created by the host and sent to previously selected players by private message through LMR (for example). This way we could get this thing going pretty quickly. Even dirtier solutions would be to keep the host address and port a secret from others. Authentication through Drupal using existing accounts would be great. I'm just afraid that it could take really lot of work to get it working (without compromising LMR user accounts!). But I know nothing of Drupal so I can't tell if it's going to take days, weeks or months. Some kind of queue management would be needed to give everyone possibility to play. The first game should of course be reserved for who made this site possible and have contributed a lot.



Instead of sending Sony IR codes an UART can be used. For the sender the IR LED would be feeded by a 38kHz square wave form from one side and the UART signal from the other side. Asuro robot is doing it that way. The receiver side would be a 38kHz IR receiver chip directly connected to RX. 1200-2400Baud should be possible.

On Arduino side a software UART for sending will be needed, because the UART is used for USB.

Thanks but this is not an issue. To begin with I am using my own variation of the Sony protocol to speed up the transmission rate. Secondly it is easier for me to set up an Atmega8A as an Arduino and use it to control the IR LED. This was one reason I got your help with fixing the tone command. I use it to generate the 38KHz carrier frequency.

OK, I understand. The Robot side is already done. On the PC side, I'll not be a great help.

I would throw out Processing as a suggestion. It's simple and easy to install, proof of concept would be pretty easy and extending it through JAVA is seamless. Not to mention that it's got some useful libraries for netowrking and data transfer...