CSE 466 Lab 7: Making a Player Controller

Introduction

Now that you've got some experience working with the iMote2, we'll be starting the first phase of the final project.

WARNINGS!!!

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.

Objectives

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

Part 1: Designing your player controller

For this lab you will be designing your player controller and your own simulated game controller. For your player controller you must do the following:

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.

For your game controller you must do the following:

Periodically send packets addressed to your node and print out your node's response. If your node does not respond within a reasonable period of time, you should indicate that as well.

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
------------------------------------------------------------
| src | dest | merged | score | action | position | reset | player |
------------------------------------------------------------

where:
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)
merged = 1 Byte: Merged or not merged
        0 if not merged, # of captain if merged
score = 1 Byte: Current score
action = 1 Byte: where 1=scored, 2=merged, 3=unmerged, 4=teleported, 5=hit out-of-bounds line
position = 4 Bytes: 0..1 X position, 2..3 Y position of player on field
reset = 1 Byte: Reset
player = 1 Byte: Player on=1/off=2

Player to Game Controller (or group captain)
----------------------------
| src | dest | deltaX | deltaY |
----------------------------

where:
src = 2 Bytes: Team, player #
dest = 2 Bytes: To Game Controller (0, 0) or Captain (team, player #)
deltaX = 1 Byte: change in X value
deltaY = 1 Byte: change in Y value
Packets to the game controller must be sent as quickly as possible after reception of packet from game controller

Once you are finished, feel free to move on and implement correct responses to different packets.

Deliverables

E-mail a single .zip file containing all requird documents to cse466-tas@cs.washington.edu
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.

Grading will focus on if it works, and design of your interaction with the iMote2.

Turn in a soft copy of your commented C code.