So I have been working on a robot project the last year a little. The project is to create a group of robots that play soccer with a golf ball. The hardware is almost done. The software is almost started. The part I have been working on lately is the networking.
Sense we are using Ubuntu Linux as our OS I decided to use BSD sockets to do the network programming. After I found a good guide to the sockets I was off and running. Then thanks to a networking class I am in this semester I got a good feel for what is going on behind the scenes. With that great knowledge I decided to use UDP and then to test it out and see if it worked like I hoped it would. UDP packets are best effort. I also known that a wireless network link does more then UDP and acts more like TCP. So I figured if the network link is checking to make sure the packet gets there perhaps I did not have to.
To test it I make a simple program to send a bunch of UDP packets and see how many made it. I created the program so I could set the size of the packets and set the delay between sending them and the number of packets sent. The program is still somewhat hacky, but I got it working. The result are good for the most part. If the delay between packets is more then a millisecond I get 100 to 99.9 percent of the packets making it. I the size of the packet does not matter much. As the delay between sending packets goes to zero the loss increases. So far I the highest loss was like 30%. I was able to push the link up to to 4 Mib/s by making large (1300 bytes) packet. At that limit it lost a lot, but at 2 Mib/s it was fine. I also noted that no matter how hard I push it the CPU never works hard, which is good because the robots lack CPU power.
I have to more things I want to do with the program, but the biggest is to test it over the internet. So far I have just had one hop. I want to see how the loss goes up when I don't have the full link to use and have to share.
1 comment:
I like it. I've always wanted to build something like this myself, so I'm glad at least one of us is programming a UDP stress test.
I do have some questions though (If you don't have solid answers for some, a ballpark estimate would work):
1. How much latency have you observed in your packets?
2. How many bots will be on a team?
3. What is the data that one bot will relay to another bot? Position, velocity, rotation, and where he thinks the ball is and where it is going, or is there more or less than that?
4. How big is this data (minus overhead) you think? Like 24 bytes?
5. How frequently will this data need to be communicated?
6. What is the worst average latency do you feel the bots could constantly operate under and still communicate well enough to play a good game of soccer? ~100ms?
7. What type of network will the bots use to communicate with each other and the coach? Will this be a star network with one bot acting as the hub, or will it be a mesh network, or something else entirely?
8. What was the reason you ruled out TCP? Did your research on your bot communication performance indicate that TCP wasn't quick enough at all? How much latency and data throughput did TCP have that it wasn't able to meet the criteria set forth in questions 4, 5, and 6? Or is it some other reason, like TCP would be totally inappropriate for this scenario, or would be more difficult to set up with the network you have planned? If so, can you go into detail?
9. What is the size of the playing field?
If no one else could tell, I'm very interested in the soccer bot project. It sounds so fun, I wish I didn't graduate when I did. So, Paul, I'll just have to live vicariously through you. Let me know if it gets annoying.
Post a Comment