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.

I hope to be able to control the robots from my computer by tomorrow. Yes I know I've said that before - work keeps getting in the way :-(

Once I have the robots all working from my computer they will be ready for your software and I can send them to Frits.



I did some drawings that hopefully illustrate my ideas of possible video streaming network setups.

First one is pretty simple and it looks like this:

This is "the default" LMR live video setup where Frits dumps the video feed to uStream and all spectators and players get their video stream from uStream. Works like a dream (does it?) but is a bit laggy.

Let's take the P2P option next. This is what P2P looks like:

In P2P network everyone contributes a piece of their bandwidth. In some P2P video streaming implementations everyone wanting to contribute has to have wide enough upstream for at least one full stream. In others even lesser will do (I'm not 100% sure about this). Frits of course has to have upstream that can handle the whole stream. In P2P network lag depends on the number of nodes between broadcaster and receiver. In the picture above players 1 and 5 (P1, P5) have lowest lag because they are connected directly to Frits. Players 4 and 6 on the other hand have 3 nodes between them and Frits so they get bigger lag. It's a bit unfair but it might work. The problem is that I haven't (at least yet) found software that could do this easily on multiple platforms (Win, Lin, Mac). I have a list of programs that could do it but it's going to take time to see if any of them really work as they are supposed to.

Third option is this:

To get this working Frits has to get good enough connection to serve all players directly and also upload live stream to uStream. Spectators would get their video from uStream. Good thing about this is that lag between players and Frits is as low as it can get. Bad thing (for Frits) is that it's probably going to cost some Euros. To get some kind of idea of what it takes I'm guessing that each video stream needs about 512kbit/s of bandwidth (I'm getting "decent" quality with 640x480 sized video @ 450kbits/s). Having 6 players and uStream means 7 streams and that's 3.5Mbit/s upstream total. If we want more than one camera multiply by the number of cameras.

Fourth option looks a bit like the third one:

In this case we have a mysterious Mr. Big Tubes. Frits streams the live video to Mr. Big Tubes who then forwards the stream to players and uStream. Mr. Big Tubes would be someone who already has enough bandwidth to serve all players and put the video stream to uStream too. Good thing about this is that players get somewhat low lag (if everything works like we/I hope) and Frits wouldn't have to pay to get enough bandwidth to serve all players. Bad thing is that if we can't find Mr. Big Tubes this won't work. So Mr. Big Tubes: If you spot this post please take one step forward and let us borrow your bandwidth for a little while, please.

Those are "the basic" setups I have in mind. There are of course some possibilities of mixing these together. For example Frits could send video to Mr. Big Tubes and uStream and Mr. Big Tubes only forwards it to players. The first one (uStream only) is already doable, so that's where we'll probably go if we can't get other options working. Third and fourth are next in line (fourth being the preferred one) if you ask me what options are feasible. The second one (P2P) sounds good and looks sexy but I'm afraid that finding suitable software could be next to impossible. Of course I could be wrong or missing some piece of information that would turn this situation upside down. For forwarding the video stream (options 3 and 4) I'm putting my hope on VLC.

Any comments, thoughts, suggestions, improvements anyone?


Some extremely nice work nuumio,

I have a feeling that uStream will be the first implementation - just by the fact it currently works.
So another step towards that goal would be a test with Frits doing uStream from his host computer?  Maybe Frits can host a little of the Friday show? - It would be interesting to see a clock on the show from his computer compared to everyone else's reading of the same clock (its synced with ntp & an atomic clock) - could shout in your delays - might be a fun and useful test.

"MyRobotLab" - is the software I wrote to do distributed robotics (dorky name, but RobotLab was taken :P)
It's a work in process, but I've been at it for a while so, things are beginning to fall in place.  It also progress faster when someone lights a fire under my ass - like this cool soccer game is a great fire.  

Gareth and I have tested it a little from Portland, USA <----> St.Gallen, Switzerland, he reported (when it work) it did not appears "laggy".  It's Java based so PC-Win/Linux or Mac should all work.

I'd like to explain a little about the software so that you and maybe others might find creative ways to use it. (in this game or other projects) - I won't be too egghead about it cause Frits will fall asleep.

The software is service based.  The game is a group of Services.  Each Service is like a little block with inputs and outputs - and they all click together to form the RoboSoccer game.

Currently the list of blocks used to create RoboSoccer is.  ( 7 X Player blocks, 1 x SoccerGame Block, 1 x GUI block, 1 x Arduino block, 2 x Servo Blocks and 1x RemoteAdapter) - you can see every one of these Block's names in the Host gui below.

Someone wanting to play is given a single GUI in the form of an Applet.
They connect to the Host and are given a single Player.  The Player's gui is exported to them.

The camera man is given the 2 Servos & the Arduino.
One Servo will Pan and the other will Tilt.  The Arduino is what the Servos are attached too

Now let's look at the "Clicky Block Thingys" and how they are Clicked together now.

Nuumio has just joined the game - his gui block is named "gui1055366710" - One requirement is that all the blocks have a unique name so they can click together..

Here is what the little blocks stuck together look like from nuumio's side.

Look at that ! He's attached to the little player00 - And when the gui has a message - it sends it to the Player block player00 Oh, and match01 is the SoccerGame Block - He had to know where the SoccerGame is, right ?!?!?

So let's take a peek on the Host machine shall we?

Look - It's nuumio with gui1055366710 !  His little block has Clicked in to the host !  The green tab means the block is remote.

What else is clicked together?  Uh, the arduino is connected to tilt and pan blocks with servoWrite messages, and it is connected to the gamegui.  The RemoteAdapter block is connected to the SoccerGame block - and let's the SoccerGame know if one of remote gui blocks has dropped - so we can get a new player.

Oh and I threw the camera block in - which can send an image (singe frame jpeg at the moment) to the gamegui.

So my friends, hopefully you can visualize all kinds of wacky fun things...  like maybe connect DarwinBot up as a sudden death time keeper.. or the Walter Block as a cheerleader...  Anyone got a NeuralNet block?  GeneticCode block?  Processing Block?  Borg it all together !?!?!    Borg Borg Borg Borg Lovely Borg !

Oh .. were was I ... yes, so getting back to streaming video.  I included a little block called camera in this one.  Camera is it's unique name, it is a OpenCV block.  It's got a bunch of nifty functions, optical, face & blob tracking, scaling, color & gray filters, transforms ... yatta yatta

But video's a brute to transport - Big companies have spent large fortunes on figuring out how to do it better, faster, higher resolution.  And currently in my setup - I got a bug.. but I'm looking into it... but in the interim I think uStream should be sufficiently fun :D

I've looked into some P2P stuff and would like to do an implementation but I do not think its implementation would be ready for the game.

So there ya have it.... I like to think of it as the Hot Glue of Software :D



Reminds me quite a lot of things I did years back when I was deep in Java. Except that it wasn't robotics. It was real time document transcoding. Back then mobile browsers didn't do HTML and WML was the hottest thing. Oh, those were the days... :-) Idea was to create a piece software that could be used to "drag-and-drop" document readers, different formatters, writers, etc in place and plug then together. All those components had inputs/outputs and the system could check that all the pieces fit together. So easy system even management guys could use it :-D But then the company's funding stopped, everyone lost their job and that was it. Never got further than doing some preliminary architecture designs of that system.

But your MyRobotLab (whose is it anyway ;-) is way cooler. Instead of some boring documents you can control robots and you have actually implemented it (at least parts of it)! Excellent idea!

I agree that going for the uStream in the first implementation would be the best. I will still keep an eye on VLC and try to figure out its mysteries. If I ever get it working I could try to arrange some kind of demo. Maybe controlling camera's pan/tilt over network. But right now it doesn't look too good. Windows version of VLC has some codecs (and apparently some other features too) disabled, at least (X/K)Ubuntu Linux stable version was badly out of date and missing features like zerolatency tuning in x264, latest testing (alpha) version on the other hand seemed to have some encoder bugs on x264 and video was stretched weirdly, no idea about Mac version. All this is just too much mess if we want more than two people watching the game. In this case everyone getting the source and compiling it themselves (and fixing those bugs, hey it's open source) isn't a solution :-)

That "how my clock looking" shouting competition could be a funny and maybe also useful test.



I'm putting my hope on VLC. Yeah, Right! After struggling for couple of days with VLC trying to get it streaming something else than asf stream I spotted this on VLC wiki: "Note: this and many other video codecs appear to be disabled and silently not working on Windows binaries, the system won't complain, but all you find is a container with no video stream in it.". Well that kinda explains why I couldn't get any non-asf video streams out from my !"%¤#! Vista!

Screw this. I'm gonna build a robot.


 Let me know what BW you'd like from me. I think I should be able to manage it / upgrade to match it.

If I get VLC running the way I want it to run we could do a little field testing with your current internet connection (768kbit/s upstream I think you mentioned earlier). May something like 2 low bitrate (maybe 350kbit/s) video streams, one to somewhere not too far away (in Europe) and another to a more further away (maybe the States). Video quality wouldn't be the best possible in this case but we could get some kind of idea what kind of lag to expect and if my suggestion is feasible.

But let's not run to the closest internet operator just yet. Let's hear if others have suggestions too. These are just my ideas and I'm kinda new to this streaming thing. In the meanwhile I'm gonna build a robot. It's relaxing after fighting with crappy software :-)


You'll be fine for just the straight ustream upload. Start creating your own account!

good luck guys!

I have no ideal what GroG and Nuumio are on about, Arduino code is about as advanced as I get and I still like DOS because it didn't have the blue screen of death. Maybe if you drew your conversation as a schematic diagram I would follow it more easily :P

Just know your efforts are not wasted and will be appreciated by all of LMR. I hope your software will get used for many events in the future, not just for my humble bots.