CSE 466 Lab 8: World Cup Soccer
This is the final project for 466 this quarter. Using all of the knowledge you've gained through lab this quarter, you will be designing a player controller that can participate in a world cup soccer game. You will also be interfacing your controller with our super-bird sensor boards.
- NEVER attach or detach the imote from the debug board or the sensor board when power is attached. ALWAYS make sure you've unplugged ALL of the USB cables when connecting or disconnecting the sensor board or debug board.
In this lab, you will learn:
- How to implement communication protocols
- How to communicate with the game controller
- How to design interactions with your iMote2 to control your player
- How to interface the iMote2 with the super-bird sensor board. Specifically the display screen and audio drivers
Suggested Reading and Resources
Part 1: Designing your player controller
For this lab you will be completing your player controller.
For your player controller you must do the following: (from lab 7)
Additionally, you must implement the rest of the functionality for your player controller:
- Determine what movements you will use to read your accelerometer and move your player. We encourage creative interactions. You should be able to control the movement such that your iMote2 sends a value between +/-20 for both the X and Y axis.
- Your design should be generally human friendly. (i.e. holding the node generally steady should result in no movement of your player)
- Make it respond to a game controller when your node is contacted.
- Make it stop sending if you receive an OFF packet for your player and start sending if you receive an ON packet for your player.
Also, we're adding the superbird sensor board, so we're expecting you to do the following:
- If you receive a packet telling you you're merged, you should send your response to your captain rather than the game controller
- If you are the captain, you should appropriately calculate your deltaX, deltaY based on all of the packets you've received from your merged group.
- On your display you should show your player number, if you're merged or not (and the captain's # if you are merged), the game score, and the position of your player on the field.
- You should also implement sounds for different events in the game. Specifically you should implement sounds for scoring, hitting the out-of-bounds line, merging, and hitting an opponent.
- Feel free to be creative with both the displays and the sounds and add any additional information/sounds you think would be fun/interesting.
- You may also add other sensors and/or button presses, etc... to help enhance your project
The LCD on the SuperBird and your accelerometer are configured to use the same SPI port. Therefore, we will be giving you a new accelerometer board that is configured differently. You must modify your driver to use SSP port 2. Note that you must change the alternate function registers accordingly. See the iMote2 and PXA27x datasheets for more info.
You'll need several drivers for the superbird:
Note that the I2C interface is needed for many of these drivers, so you must
- superbird.ko -- A driver for the switches and tri-color LED
- superbird-audio.ko -- A driver for the audio chip. You must
mknod /dev/dsp c 14 3. This driver uses the standard ALSA/OSS sound interface for Linux.
- snd-pxa2xx-pcm.ko -- A driver that provides many support functions for superbird-audio. This must be loaded before superbird-audio.ko
- lcd-fb.ko -- A driver for the LCD that gives you a text console on /dev/vc/0. Note that you should look at
man console_codes on attu for special commands you can send to the console. In particular, you must unblank the display and set the blanking timeout to 0 minutes. Since dim colors do not display well on the LCD, you may want to adjust the color palette by using the FBIOPUTCMAP ioctl, as demonstrated in this file.
- lcd.ko -- A driver for raw access to the LCD. This is optional, but allows you to do graphics. Pixels as 12 bits, with two pixels packed together as 3 bytes, in RG BR GB format. Use only lcd-fb.ko or lcd.ko. For an extra challenge, ask us for the source code and you can integrate them. :)
modprobe i2c-pxa for these to work!
A header file for superbird.ko is available here. The header for the tri-color LED is here. In addition, you might find mpg123 useful for testing your bird's audio chip.
The packet structure for this lab is as follows. You should put this structure into the data field in a TOS_Msg, and parse it from the same. You should broadcast your packets (i.e. set pkt.addr = 0xFFFF;).
Game Controller to Player
UPDATE: We've changed the packet structure slightly to help with word alignment issues with the xscale. More information about that can be found here.
| src | dest | position | merged | score1 | score2 | action | reset | player |
src = 2 Bytes: Source address identifying packet as coming from controller
Controller is player 0 on team 0
dest = 2 Bytes: Destination address
1st byte is team (1 or 2) and 2nd byte is player number (player number unique)
position = 4 Bytes: 0..1 X position, 2..3 Y position of player on field
merged = 1 Byte: Merged or not merged
0 if not merged, # of captain if merged
score1 = 1 Byte: Current score for team 1
score2 = 1 Byte: Current score for team 2
action = 1 Byte: where 1=scored, 2=merged, 3=unmerged, 4=teleported, 5=hit out-of-bounds line
reset = 1 Byte: Reset
player = 1 Byte: Player on=1/off=2
Player to Game Controller (or group captain)
| src | dest | deltaX | deltaY |
src = 2 Bytes: Team, player #
dest = 2 Bytes: To Game Controller (0, 0) or Captain (team, player #)
deltaX = 2 Bytes: change in X value
deltaY = 2 Bytes: change in Y value
Packets to the game controller must be sent as quickly as possible after reception of packet from game controller
We will be giving you a test game controller soon so you can test your responses, but until then feel free to update your game controller from lab 7 to help you test.
E-mail a single .zip file containing all requird documents to email@example.com
For all files turned in, the comments at the top of the file should contain:
- Both partners' full name, login and student number.
- The lab number and the part of the lab (e.g. "Lab4, Part2").
Demonstrate your player controller and fake game controller to a T.A. You can either do this during lab, or during the first 1/2 hour of the next lab.
Turn in a soft copy of your commented C code.
- Grading will focus on if it works, and design of your interaction with the iMote2.