Due to the COVID-19 pandemic, people may need to keep social distance. So we may not be able to visit our friends and interact with each other physically. What if we still want to gain some joy through the interaction with our friends? Try our IoT version “Simon says” game! “Simon says” game is a simple game that tests one’s memory. One should always repeat the sequence by the other player and add a new move to the sequence. In the PVP mode, once there’s a mistake in the sequence, the game ends. The one who makes the mistake loses the game and the other wins. Let’s see who is good at memorizing sequences! What if your friends are not available? What if you have such a good memory that no one can beat you? Try the PVE mode of our game to see if you can beat the computer! No matter where you are or what time it is, you can always enjoy the IoT version “Simon says” game as long as battery and connection to the network is available. Just enjoy it!
What it does
This project builds a “Simon Says” Game based on the IoT platform. The game involves two players, either human player versus computer or two human players play against each other. Players connect to the cloud through terminals to play the game. Game Rule: Each player has a 4x4 keypad with RGB LEDs for input and movements display. At the beginning of each round, players can choose one of three game modes (keypad, joystick or gesture sensor) on the cloud dashboard. The player's task is to remember the sequence entered by the other player, reproduce it, and add a new action at the end of the sequence. The game ends when one player inputs the wrong sequence, or when the length of the sequence reaches 20.
How it works
- System Architecture
- Hardware: Development boards prototype and final custom PCB board
- Firmware: Bootloader and FreeRTOS architecture
- Front-end: Node-Red dashboard supported by IBM cloud
- Circuit Design
- Design tool: Altium Designer
- Basic information: 80.00mm x 80.00mm four-layer board
- Power supply: The system can be powered by the micro usb interface or by battery. Linear Battery Chargers BQ24075, Boost Converter TPS61032 and Buck Converter TPS62082 are used for 3.3V and 5V power supply.
- Peripherals on board: APDS-9960 (connected to MCU with I2C), Thumbstick (connected to MCU with ADC), USB connector and FTDI chip, SD card reader
- Interfaces: connector headers for OLED and Keypad (both connected to MCU with I2C), Audio amplifier (connected to MCU with DAC)
- MCU + Wifi module: SAMW25 board
- IO: 4x4 keypad (3954), Adafruit Mini 2-Axis Analog Thumbstick (2765), gesture sensor (APDS-9960), OLED screen (14532), Audio Amplifier (3885)
- Memory: SD card
- Cloud Construction
- Cloud UI: Node-Red on IBM Cloud
- Buttons for game method & mode selection and game initiation
- LED boards for game sequence movement display
- Text boxes for game sequence movement display in debug mode and game result display
- Data Exchange: HiveMQ as the MQTT broker
- Firmware Implementation
- FreeRToS: Schedule the tasks to achieve concurrency
- CLI Task: Command Line Interface between the user and the embedded system
- Wifi Thread: Handle the tasks related to Wifi connection and message transmission
- Control Thread: Handle the state of the game
- UI Thread: Handle the user interface tasks of the game
Challenges we ran into
- Part selection: Due to the need to consider parameters, sizes, inventory and many other factors, we had a hard time dealing with part selection. In particular, the inventory of many components often changes dynamically, forcing us to keep updating our BOM.
- Audio amplifier: We’ve built up the driver for the audio amplifier and it can be initialized properly. However, the sound effects that we’d like to play when the devices receive the game result are very long uint16_t arrays. Since the RAM for MCU is limited, it cannot hold such long arrays. Errors will occur if we build the project with these long arrays. Therefore, the audio amplifier cannot work properly now. We’ll try to store these arrays in NVM like the SD memory in next steps.
- Custom PCB: Components and wires placements when designing the PCB is relatively complex and needs several revisions. Due to the covid pandemic, there’s a huge delay in producing the PCBs. Besides, we also find some components are missing on the PCB and some components are not fully soldered. As a result, new components should be ordered and we need to solder them by ourselves. Some components are relatively difficult for us to solder and set barriers for debugging on our own PCBs. Some essential hardwares for downloading the firmware to the PCB is temporarily not available to us. We’ll try to download it to the PCB in future steps. Until now, we’ve tested some critical voltages on the board. The voltage supply and conversion circuits work well.
- Task scheduling: The use of FreeRTOS involves the scheduling of a large number of processes and the allocation of resources, leading to difficulties in programing and debugging. In the process of debugging, we often encounter problems such as stack overflow and task conflicts. For example, when debugging the gesture sensor and joystick, the LED display was confused by thread conflicts. We solved this problem by adding a delay for movement display.
- MQTT topic: our 2 devices subscribe to the same MQTT topic that transfers the game method message. During the period that we were developing and debugging the system with only one device, the only device can receive the message correctly. But only one of those 2 devices can receive the message from that topic when we try to run the whole system with 2 devices, that is play Simon says game in PVP mode. Therefore, we cannot start the game properly in PVP mode. According to the professor, we tried to change the MQTT user ID to fix it. It works when these two devices have different MQTT user IDs.
What we Learned with the prototype
- Custom footprints and silkscreen indicators should be carefully checked. We drew a smaller hole for a through pin component and drew a silkscreen indicator in the wrong direction for a polarized capacitor when designing the PCB. These lead to extra work for fixing them.
- Using more common pins instead of connectors will benefit debugging the custom PCB with common cables.
- Using more informative text indicators for components on the PCB. We simply use common indicators like B1, B2 for buttons and J3, J4 for connectors. It’s hard to recall what these components are used for unless we check the schematic. If we use some text like “reset”, “Keypad”, it’ll be more informative for both the developers and the users.
- Pins allocation for the dev board may vary from the custom PCB. More reviews and adjustments should be performed.
What we learned
- Start a project with a general function diagram and power supply
- Use TI Webench for power module design
- Draw schematic and PCB symbols for components in Altium
- Draw circuit schematics and route PCB in Altium. Perform rule check after routing
- Generate BOM and place PCB orders online
- Implement FreeRToS for task concurrency
- Develop firmware code, including drivers for different components and task functions, based on Microchip Studio
- Use Node-RED for building the online UI
- Basic knowledge of how MQTT works
- Basic soldering skills
What's next for Simon says game
- Deal with the audio amplifier. We may try to store the sound effect uint16_t arrays that should be played when the devices get the result from the cloud as files in the SD memory. We’ll adjust the code regarding playing the sound effect by reading it from the SD memory when the sound effects should be played
- Download the firmware to our custom PCB. After we grab the hardware that is required for downloading the firmware to the custom PCB, we’ll test if the FW works properly on our PCB and make some updates according to the specific result.
Node-RED Link: Simon says