Tuesday, May 10, 2011
Source Materials
Oh yes, and if ya'll are interested in our source code and miscellaneous materials, you can find all of our materials here http://www.seas.upenn.edu/~zhangka/PokemonStadium350/
Pokemon Stadium 350 Retrospect
We did run into a couple of obstacles on our way to the finish line. Most of these obstacles involved the Firefly however. The first sign of trouble came when out of our dozen or so Fireflies, only about a third of them actually worked: the rest would refuse to sync with the computers in Detkins. However, the biggest trouble we’ve had with Fireflies is that they refused to have multiple tasks running together: every single time, when we try to turn on the Fireflies, they would produce errors.
Because of these obstacles we had to change some previous ideas as well as completely scrape others. For example, the original idea was to have multiple Pokemon per player, to make it more authentic to the actual Pokemon games. However, that required the Fireflies to have 2 way transmissions in order to know which Pokemon is active when: something we felt needed more than just 1 task, and so was undoable. Additionally, we also wanted to have some kind of centralized scoreboard that would display the remaining health of each active Pokemon. However, we ran into the same problem as the multiple Pokemon plan: it required 2 way transmissions for each Firefly, which would then require multiple tasks, something that wasn’t working out for us at that time. There were some problems that we ran into that we were able to work around though. For one, we initially wanted to have the rumble pack go off whenever a Pokemon gets hit. Because of the problem we ran into with 2 way transmissions that was described above, we decided to settle with the rumble pack going off when the button A was pressed on the GameBoys. Another problem we ran into was that we first planned on having the entire “game” itself run on the Fireflies attached to the 3Pi Robots, and have the 3Pi Robots only respond to commands. However, we found that there was quite a bit of delay with that setting. We then decided to instead switch the game to the robots themselves. This actually turned out well, as the game ran much smoother, with the 3Pi Robots having ATmega328 processors @ 20MHz while the Fireflies only having ATmega1281 processors @ 7.4 MHz.
Having completed this project, there were some things that we would have done different if we were to do this again. For one, we decided that using BMAC to transmit wirelessly wasn’t such a good idea. Even when it was the only task running, there was still a noticeable 0.25 second of delay between pressing a button and when the robot would actually respond, which made it a bit hard to precisely control the robots. That is why next time; we should maybe try the RF wireless protocol on the Fireflies, which apparently is much faster. Additionally, we would have liked to do a bit more research on photoresistors, and see if we can get more sensitive ones, as it was difficult to calibrate the ones that were in Detkins: if we set the threshold a bit too much one way, the Pokemons would register ambient light as hits, while setting the threshold a bit too much the other way would make it nearly impossible for the robots to hit each other. Besides getting more sensitive photoresistors, we could also look into IR emitters and IR capturing cameras to serve as weapons/hit boxes.
Though we ran into those troubles, through many days of hardwork in Detkins, we were able to complete our project into a game that is not only pretty darn fun, but also brings back nostalgia for the good old days.
Because of these obstacles we had to change some previous ideas as well as completely scrape others. For example, the original idea was to have multiple Pokemon per player, to make it more authentic to the actual Pokemon games. However, that required the Fireflies to have 2 way transmissions in order to know which Pokemon is active when: something we felt needed more than just 1 task, and so was undoable. Additionally, we also wanted to have some kind of centralized scoreboard that would display the remaining health of each active Pokemon. However, we ran into the same problem as the multiple Pokemon plan: it required 2 way transmissions for each Firefly, which would then require multiple tasks, something that wasn’t working out for us at that time. There were some problems that we ran into that we were able to work around though. For one, we initially wanted to have the rumble pack go off whenever a Pokemon gets hit. Because of the problem we ran into with 2 way transmissions that was described above, we decided to settle with the rumble pack going off when the button A was pressed on the GameBoys. Another problem we ran into was that we first planned on having the entire “game” itself run on the Fireflies attached to the 3Pi Robots, and have the 3Pi Robots only respond to commands. However, we found that there was quite a bit of delay with that setting. We then decided to instead switch the game to the robots themselves. This actually turned out well, as the game ran much smoother, with the 3Pi Robots having ATmega328 processors @ 20MHz while the Fireflies only having ATmega1281 processors @ 7.4 MHz.
Having completed this project, there were some things that we would have done different if we were to do this again. For one, we decided that using BMAC to transmit wirelessly wasn’t such a good idea. Even when it was the only task running, there was still a noticeable 0.25 second of delay between pressing a button and when the robot would actually respond, which made it a bit hard to precisely control the robots. That is why next time; we should maybe try the RF wireless protocol on the Fireflies, which apparently is much faster. Additionally, we would have liked to do a bit more research on photoresistors, and see if we can get more sensitive ones, as it was difficult to calibrate the ones that were in Detkins: if we set the threshold a bit too much one way, the Pokemons would register ambient light as hits, while setting the threshold a bit too much the other way would make it nearly impossible for the robots to hit each other. Besides getting more sensitive photoresistors, we could also look into IR emitters and IR capturing cameras to serve as weapons/hit boxes.
Though we ran into those troubles, through many days of hardwork in Detkins, we were able to complete our project into a game that is not only pretty darn fun, but also brings back nostalgia for the good old days.
Subscribe to:
Posts (Atom)