Hardware Description
The casing for the device was removed to access the front of the motherboard. Located there were the button contacts which we had to devise a solution to “hack” the controls. The general concept behind the buttons is that there is one high-asserting (3.3 V) contact and a low-asserting contact beside it. When the user presses the button, a conductive plastic connects the two contacts and shorts the signal. The GameBoy then responds to the button’s action. In our example we intercepted this signal by soldering on each of the high-asserting contacts; 6 in total – 4 directional buttons and 2 special buttons.
Each one of these intercepted signals was then connected to the Firefly ADC pins. Table X below summarizes the connections. We should note that we needed the Firefly ADC to have a common ground with the GameBoy, so we had to connect the ground terminal of the battery slot on the GameBoy to the ground ADC pin on the Firefly. We did not need to connect to the 3.3V pin on the Firefly, since it was already receiving power from the Firefly’s batteries. Lastly, we include in the table the equivalent Firefly Sensor Board pins as they were defined in our header file.
| Table 1: GameBoy Configurations | ||
| GameBoy Button | Firefly Pin | Sensor Board |
| Up | ADC1 | Light |
| Down | ADC2 | Acc_X |
| Left | ADC3 | Audio |
| Right | ADC4 | Temp |
| A | ADC5 | Acc_Y |
| B | ADC6 | Acc_Z |
| Wire | Ground | Ground |
We then had the Rumble Pack connect to the Firefly’s GPIO. We had the red pin connect to the Debug_0 GPIO, and had the black pin connect to ground. The rumble pack would thus be activated when Debug_0 became high-asserting; the pack would be driven by the supplied DC power.
Software Description
With the correct hardware in place, the Firefly that is attached to each of the Gameboy can start interpreting which key the user presses on the Gameboy, if any. The way the software is set up, the Firefly on each is initiated on a different channel (20 and 10). Each Firefly also only has one task: to read ADC values for each of the 6 inputs, and determine which key is pressed, and then send a certain char over BMAC. That task is repeated over and over again.
Because each of the 6 buttons on the Gameboys are connected to ADC pins rather than GPIOs, we found that when the user isn’t pressing any of the buttons, the ADC value read is around 1023. However, when a certain button is pressed, the ADC value for that specific button goes down to close to 0. As such, in the code we detect for whether any of the ADC values for Up, Down, Left, Right, A, B are close to 0, which if one of the values are, to send over BMAC the characters “u, d, l, r, a, b” respectively. If the user wasn’t pressing any button, the Firefly would be sending the character “n”, so that the Firefly would continuously send streams of characters no matter what. Because of the order the code is set up, it is biased for the A and B buttons: if the user pushes both a directional button along with one of the A and B buttons, the Firefly would register the A or B button first. Additionally, we set pin PA3 (Debug_0) to output high whenever the button A would be pressed as to turn on the rumble pack, and to turn back low whenever A isn’t pressed.
Pololu 3Pi Robot Unit
Tentacruel
Hardware Description
The crucial design hurdle for Tentacruel was to power 8 SuperBright LEDs with sufficient voltage and regulated current. The LEDs had a current rating of 20 mA, and had sufficient voltage above approximately 1.5V. Our design used a common cathode along with two resistors in series, 51 kOhms and 100 kOhms, to limit the current at approximately 19.5 mA, while each of the anodes was connected to a common Vcc (5V). The total voltage difference across the LEDs became approximately 1.8V. Since the characteristic design of Tentacruel was to have 8 LEDs around the circumference of the robot, this required multiple locations for both the cathode and the anode.
We then integrated the photoresistor into the system. A photoresistor is a variable resistor, so we needed another resistor to create a voltage divider. The photoresistors we used ranged from approximately 5 kOhms to 15 kOhms with a negative orientation – this meant that it was 5 kOhms at full ambient light and 15 kOhms when without light (thus, our corresponding voltage output was positively related the amount of light). We had Vcc attached to the photoresistor which was then connected to a 1 kOhm resistor which was then connected to ground. We intercepted the signal in between the photoresistor and the 1 kOhm resistor, and connected this to ADC7 on the robot.
We then had to attach the Firefly to the robot. This Firefly did not have batteries, so we had to supply it with Vcc and a common ground from the robot. To enable serial communication between the Firefly and the robot, we connected UART1_TX of the Firefly to PD0 on the robot. The robot would receive action commands from the Firefly through this method. The Firefly on the robot would concurrently be receiving wireless commands from the GameBoy’s Firefly.
Charizard
Hardware Description
Charizard and Tentacruel held a number of similarities, but there were significant differences as well. Charizard only had 5 LEDs – 2 primary and 3 secondary. This meant that the primary LEDs were on at all times and were thus connected to Vcc. The secondary LEDs were connected to the PC5 GPIO – this was set as an output that would be high-asserting (5V) in response to the A button command. All this while, we had to maintain the 20 mA current rating – all 5 LEDs share a common cathode along with two resistors, 47 kOhms and 100 kOhms, just as with Tentacruel. The voltage difference was also approximately 1.8V across all the LEDs.
Otherwise, Charizard the same photoresistor and Firefly configuration as Tentacruel.
Software Description – Firefly on 3Pi Robot
Each Firefly on each 3Pi Robot were first initiated to their respective channels (10 and 20), the same channels that the Fireflies on the Gameboys were initiated to. Additionally, because we set the 3Pi Robots to accept serial communication at the baude rate of 9.6k, we also had to set each of these two Fireflies to a baude rate of 9.6k as well. Each Firefly would then be stuck in an infinite loop, where all each has to do is to receive each character that is being sent over BMAC from the Fireflies on the Gameboys, and then send the same character that they received through serial communication to the 3Pi Robot. Coincidentally, printing a character or a string on the Firefly directly sends it over serial communication anyways, and so whenever one of the Firefly on the 3Pi Robot would receive a character, we just had to use the function putchar() to send that character over to the robot. Because the Firefly on each of the robot does the exact same thing, the same code was used for both of the Fireflies.
Software Description – 3Pi Robot
As mentioned above in the software description of the Firefly, both of the 3Pi Robots had their baude rate set to 9.6k. Additionally, each robot also had to initialize some variables, such as health and speed, which hold information about that specific robot’s health remaining as well as how fast the robot can go. Besides initiating those, each robot was then stuck in a permanent loop where for each iteration of the loop, each robot would first wait to receive a command from the attached Firefly, and the robot would then run certain functions depending on what character was received. For example, if the robot received a “u”, it means that the user pressed the UP button on the Gameboy, which then tells the robot to moves forward at a certain speed as determined by the variable each robot has called “speed”.
In addition to reacting to commands given to it, the robot would also check for whether it was hit. If the ADC value returned by the photoresistor attached to each robot was above a certain threshold, the robot registered it as a hit, which would cause the robot to decrement the amount of health it had left as well as have the on board buzzer play a sound whose frequency was determined by how much health the robot had left – the frequency decreased with decreasing health. Each time a robot would get it, that robot would also check whether it was dead or not. If the robot wasn’t dead, the code would continue to proceed. If its health however was less than or equal to 0, the code would then proceed into a new function where the robot’s onboard buzzer would play the Pokemon Blue and Red Victory Music, and then proceed to be stuck in a different loop where it can never get out, signifying that that Pokemon has lost.
The codes for Charizard and Tentacruel have many similarities: the basic functions for each Pokemon were the same. Each Pokemon had to initialize some variable and then proceed to continuously check for commands, react to the commands and check for whether the Pokemon was hit or not. However, both Pokemon also had noticeable differences between the two of them. For one, most of the variables for each Pokemon were different, as they each moved at different speed. Additionally, unlike Charizard, when Tentacruel is first activated, Tentacruel would have its onboard buzzer play the Pokemon Blue and Red Introduction Music. Finally, because each Pokemon had different moves mapped to button A and B, each Pokemon would perform different tasks whenever A or B are pressed.
No comments:
Post a Comment