Mid-game display
Seth sleuthing
Final products
Preliminary circuitry design

Hear Me Out: A Bruin Espionage

Context

USC Operatives have activated an EMP device on a short timer that could take out UCLA's power grid indefinitely. As expert spies, you and your partner have been tasked with finding a way to find and deactivate EMP devices to prevent a catastrophic event! USC has strategically placed personnel on campus that wish to stop you from accomplishing this task, allowing you only to communicate at certain intervals to avoid eventual suspicion and capture. Using your superior campus knowledge, you and your partner must guide one another to these checkpoints and simultaneously interact with the EMP devices to stop the blast in time. A critical flaw of the Trojans is that they doubt we will send multiple spies, leaving them to abandon devices which require synchronous interaction to deactivate. Come together to stop USC from hurting our school and students!

What it does

A team-based game with the primary focus of engaging players in activities around UCLA and to learn UCLA lore by stepping outdoors and into nature. Players gather together and separate into two teams. They must split up and find randomly selected “EMP” devices hidden at well-known UCLA spots. Each team is given clues via a main display that also shows a countdown timer and the number of EMP devices left. They must race to find these devices as soon as possible with the quirk that the clues they receive are not their own clues but the other team’s. Using a faulty radio (one that intentionally flips on and off to make communication more difficult), they have to communicate with the other team to lead them to their destination. After the first clue, each team can hold onto the button on their gadget to reveal a hint. Once both teams have made it to their respective device, they must both swipe their spy gadget over the device at the same time (within a certain threshold) in order to deactivate it and move onto the next EMP device. After all devices are deactivated, the players (spies) win the game. If time runs out, they lose to USC.

How we built it

The backbone of our idea was to build personal handheld devices that would allow teams to play our game. We chose the ESP32 family of system on a chip microcontrollers because of its onboard WiFi and Bluetooth capabilities, giving us easy access to wireless device-to-device communication. The microcontroller communicates with the display and RFID reader through a Serial Peripheral Interface, and a relay was used to program the transmission of the walkie talkies. For inter-device communication, we decided to have one of the devices be the “controller” device which sends and receives information to the other device through web servers. This way, both devices can keep track of which locations have been visited, what the total elapsed time is, and when to start/stop the game. Each ESP32 is equipped with a 2.8" LCD graphical display, an RFID reader, and a walkie talkie for communicating with the other team. We used relays to implement the one-way walkie talkie toggling feature to allow for limited communication between the teams, and unique rfid tags for the “EMP devices” that are verified upon scanning.

Challenges we ran into

As a team, we fought through many challenges during this project. We all came into the hackathon with a general idea of what we had wanted to gain from the experience, but none of us had a specific idea in mind that we wanted to create. As such, we spent most of the first couple hours brainstorming ideas together. We struggled to settle on a concept that would not only incorporate some interesting pieces of hardware, but also bring together communities and friends in its implementation. The game that we present today is the culmination of many rounds of revisions, edits, and changes to our original design.

From a technical standpoint, we encountered many more issues that resulted in hours of troubleshooting and engineering workarounds. One notable example being that we initially wanted to use direct device-to-device communication over a common LAN network. However as we soon realized, our ESPs were only allowing for one-way communication, which made synchronization impossible. As a workaround, we hosted a web server on each of the devices, used HTTP post requests to send game-critical data to the web, and read the website information with HTTP get requests. This way, both ESPs could both send and receive any information they needed. This ended up being more reliable than sending information between the 2 devices directly as it decreased interference significantly and removed the need for a central wifi connection that was shared between the 2 boards, allowing them to be used anywhere.

During development of the various components of our devices, our team split up to work on the individual parts of the final handheld device. But when we attempted to combine the LCD display and RFID reader together, we ran into another issue. Both devices were configured to communicate through SPI, and we initially wanted to let them share a common SPI bus. However, we soon found out that the wrapper libraries we were using to configure our devices would intrinsically control the Chip Select pin, not allowing us to determine when each device would use the bus. Ultimately, we hit a stroke of luck and were saved by the capabilities of the ESP32: there was a second, lesser known SPI bus that we configured to drive the LCD display.

Accomplishments that we're proud of

We are proud that we planned and implemented our primary idea to the best of our abilities. Within the hardware realm, we are proud to have brought a variety of interworking components together into one device. Those being the ESP32, LCD display, RFID, and radio. From there, we’re proud to have made a compact and usable design where we could play the game together–it was a lot of fun running around and attempting to communicate with each other over the faulty radio system.

What we learned

Within our team, we learned a lot from each other. Each of us came into the event with different skills which we were able to share with the team. We learned to solder, breadboard, program wireless communications, write to graphical displays, build timers for voltage relays, hack radios, and much, much more. We also learned that the ESP32 is an amazing development board for a wide variety of applications.

What's next for Hear Me Out: A Bruin Espionage

For starters, we’d like to add more locations to our roster, each with their own set of clues. Because the walkie-talkies and ESP32’s had limited range, we would implement a new way of communication between each ESP32 so that each team could speak and deactivate their respective EMP’s at opposite ends of the campus–which was not possible with our current setup. Still in development is a leaderboard system in which teams with the fastest times are placed at the top of the ranking. An implementation of this, we hope, would lead to more involvement from the community across UCLA. Another feature we would love to add would be images of locations that teams would need to describe to each other. Rather than a written clue, these images would serve as marking locations that would slowly lead teams to the final destination, given that the other half of the team is talented at communication.