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.

Got the code working, hooked one player up, can control it with the remote :)

These things are both extremely clumsy and very, very fun! When they see anything in front of them they "kick", it looks awfully funny!

I wonder if the code for each should not give them an individual ID?

Anyway, I have a lot, lot lot of calibration to do, and I will then hook up a camera and a field, once I can show you all some moving players :) (Controlled by me / remote to start with)

Once the soccer bot code is installed each robot will have it's own ID number. For now I have just given you the standard code so you can experiment with them a bit and make sure they are all working.

Hey OddBot, for reference, can you post a video of a bot (no-proto) walking the best it can, 30 seconds+, pure slave whithout interfering, in each direction, one by one, so I know how hard to try to calibrate and what actual performance to expect at max. Thanks. (I've got 7 robots to tune in to the sports event of the year, something to benchmark against would be nice ;)

Also to keep me from inventing my own "improvements" if I should actually make them do better by calibrating and optimizing surface etc to match your conditions.

To be honest I don't have such video. never had time. My original test were on a glass table top but I suspect a felt top such as a pool table would work well to give them traction. Possibly a cloth stapled to a cheap piece of wood?

This is new territory for you to explore. If I can steal a bot from the sales department then I will try to make a video.

The thing is; I cannot make any of the robots able to walk in 4 directions;

Example: I have one here, that is now the best at walking forward. It does that pretty well. But that can not reverse (it just steps kinda sideways), it can turn to one side, but not to the other, just steps on the place. And that is how it is with them all; good at turning to one side, not possible to the other, or if good at both sides, then not able to walk forward etc.

So I really feel I need to know what to aim for here; Am I seriously to keep trying to make the robots able to walk in all 4 directions, is it even possible? (I do not think so any more, and I asked for the video, to give me fresh energy) If the desired control is not really doable, then could we say that I make them all able to walk forward and turn in one direction? I could do that, and that would make a game possible.

Also, I could give them wheels, modify the servos.. that would make the navigational part of the project so much easier, but I am not sure if I destroy the basic concept and idea then..(?)

Although I have had them working well I admit it is difficult. If one foot gets more traction than the other for any reason then they tend to turn in one direction only.As the legs are just the servo horns joined together they can sometimes be a bit crooked. Sometimes the batteries don't sit flat in the holder. Any little difference between the two legs tends to affect the controlability of the robot.

For now please do the best you can with them as they are. If a player can only turn in one direction but not another then it adds another level of dificulty / craziness to the game. I will see if I can improve the walking code.

Later when we get bored with them we can modify the crap out of them.

I have found the funnest games are the ones that support distinct diversity.  Getting the four directions support on walking bots would be great, but maybe it would be better to mount at least 2 on wheels anyway.  They could be the "forwards".  Give them a plow in front so they can't hit the ball straight on, but the ball gets deflected at a 45 degree angle.  

It would be cool to get a servo-claw on 2 of them, as potential goalies.

Since I don't have one, its a little difficult for me to give useful advice.  Are you tweaking OddBot's code?  Have you tried moving them like stop motion characters?  If you can't get them to move in the 4 directions that way, I don't think its physically possible. Maybe add other benefits, if they can move only forward and turn 1 direction, make them a goalie.  A one handed, one legged, crippled goalie, but a goalie none the less.. 

He could have a 3rd leg that extends out 8" ... heh...

Funny thing, I was home sick today and I did some work on my similar robot. My robot also has problems walking and turning. I have tried this options for turning:

- stop one leg and have the robot walk forward with only one leg; - this somewhat works for one side and not well for the other

- reduce the stride for one leg to half

I still want to try out the possibility to walk backwards while turning. But I modded the code a lot. I took out all that was remote related and eye related, added my code for Sharp sensor reading and panning to find a clear path to turn to. The code works, but the robot does not turn correctly. It seems that most of the weight falls on one leg and even when walking forward, the robot is actually turning right in a circle.

I will make a video tonight, after I get back from the hair cut.

There it is. Linked to my robot's page.


Looks like he's skating on the glass table - Scott Hamilbot

What about if you polymorphed some chicken feet.  Having toes which cross under the center of gravity keeps the little buggers pretty stable.  This is done often with windup toys.  This would be much more simple versus  shifting weight and rolling ankles etc (like this - although very cool).

Also if the heel has a point - like a high heeled shoe, you can use it as a pivot when the other foot is trying to turn.  Kind of like spinning on your dancing heels.