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.
 
Example:
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.

 

UPDATE:

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.

 

AttachmentSize
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.

Agree to all :)

  • We need authentication - no hard security, but somehow it needs to be decided which 6 players are on.
  • I would like to print out the players LMR-names, and put them on top of the players heads. That way everyone can follow everything, and it is funny to see how DutchBot is kicking GroG in the arse or something.
  • I would like to be able to record the games - we have a round globe with night for one, while day for the other. And if a member is joining a team, it would be coolest if he could see the game(s) that went before, without having to get up in the middle of the night.
  • I myself will try to host games at variyng hours, so every one can join in live at some point.
  • I would like it to be so that "teams" are formed. But in order not to make stuff too complicated, and to make sure the games can go on even if a player of a team is missing, I would like the rules of the "league" to be like this:

    * To join, you must join in a team. A team can be formed in any way (through shoutbox, on the fly, perhaps, no prob) Only rule for a team is: It must have a captain. Therefore it would be smart, if entry was made by this captain. He could then get passwords for the team. If a player was missing for the next game (another day perhaps) this team had to play, then the captain could replace the player with a reserve. So - teams are formed around the captain - And I write all this to make it easier for you guys with all the complicated programming.
  • The simple rules should - is my idea - be that if a team has won a game, it is automatically this team that plays the next game. The opposition is the next team on the list available.Teams written up for a game, will be in a line, the team that has waited the longest is the one to play to play against last winning team.

Apart from this all will be anarchy, if there is not enough to play a VS, we will just play, and in general make it up as we go along :)

However, I think we will be much better off if the authentication took the above into consideration:

  1. Players join by one team leader that gets a password
  2. Teams sign up to play, and the winning team plays again, against the team that has waited the longest to play

:)

 

After this game, we have a second round where each player can build his or her own bot, within set parameters. The, we hook them all up by using the same comms protocal and have a more diverse match (more specialized robots, 'teams' can organize so one's goalie, one's shooter, and one's defense, etc) Ship them all in for the match, then send them back out to their builders after a weekend of soccer, bot-awesomeness, and vuvuzelas.

I rigged my DarwinBot for direct control over IRC.

The perl script is an adaptation of my reception_bot. You go into command mode by typing "wanna" anywhere in a line of text.

Commands are formatted as an equal sign followed by a single letter:
=r (right)
=l (left)
=s (stop)
=f (forward)
=b (backward)

See for yourself how DarwinBot interprets these soccer commands.

Warnings: Ustream channel is live when it is live. Code is still under development. You get 10 commands per wanna. Debugging feedback is on my screen only. If the bot catches fire, please wake me up.

Get a feel for the kind of video lag this soccer setup will have to deal with.

1. is it necessary?
2. what pins do you re-transmit out on the Arduino - any digital one?

The Arduino does 2 things. It provides the 38KHz carrier wave and it let's me modify the IR protocol if necessary. Yes I could use a 555 timer to generate the carrier frequency and have the TX from the host driving it's reset pin. The down side to this is the host software must be directly compatible with the robots. As I am not writing that software it is easier for me to use one of the 10,000 ATmega8A chips we have in stock. Then I can tweak the Ir protocol as necessary without modifying the host code.

So nuumio and I have basically the same idea.. (great minds! :D)

I was a little confused on what Oddbot's Players hardware, but was informed by Rik that each has an "Arduino-like" controller on it.

Now I've come to the understanding that the Arduino connected to the Host computer doesn't do much at all.  In fact the IR TX module could just be soldered to the RX pin, because the serial data written from the computer is the data that should be directly transmitted to the little "Arduino-like" controller on the soccer player.

If this is not the right idea... and I've got it muddled up again - please slap some sense into me...

Yes, each robot has an ATmega8A configued as an Arduino. It is basically a small Arduino compatible board. The code for reading the IR commands is really just a few pulsin commands. Very simple and it allows me to adjust the IR protocol as neccessary to try and get more speed out of it.At the moment I could get as much as 20 commands per second to each robot but I have it dialled back to 10 per second for reliability.

That being said, the ustream video lag sounds like our biggest issue. When I talk to my friends in Australia with the video feature in windows live messenger I get less than a second delay time so perhaps we need to use a different video service.

Sounds like you got it about right. Of course IR transmitter Arduino has to take the data out of serial frame and pack it into a Sony IR frame so direct soldering wouldn't do it.

 

Here's one way to do it: http://letsmakerobots.com/files/remote_soccer_demo_01.zip

I wrote a quick and really ugly demo with Java. It can be used to control Head's head over a network connection. Server side runs in a terminal/command prompt and client side has a small GUI for controls. They look like this:

Server


Client

Not the most beautiful ones but they'll do their job. Server side uses RXTX library version 2.1-7 for serial connection. So if you are interested in giving it a try you have to download and install it.

When running the server it will first ask you to choose a serial port from a list. After you have selected the serial port it will start waiting for incoming connections. When it has a connection it will spit command received from client to serial port. NOTE: There's no real connection handling. It will just accept 6 connections and then die in agony. IMPORTANT NOTE: There's no authentication of any kind. Anyone can connect to the server. GroG mentioned authentication earlier in his post. There should be some kind of authentication when this thing goes live. Server can be started by running following on command line:
$ java RSBServer

Client side is pretty easy. Just start it by running:
$ java RSBClient

After that enter your server address to server address field and click connect. Controlling can be done by those buttons on GUI or by arrow keys and space. NOTE: Control keys won't work when server address or server port fields have focus (yea, yea, yea. I was lazy again).

The code itself is really ugly because I just threw it together. If you think this could be a way to do it I'm willing to improve it further. Of course you can also take that task to yourself and I'll just watch how you do it. But I'll try to help if you just ask ;-)