eh699-er553-md2265

View on GitHub

Autonomous Rock-Paper-Scissors Hand

Authors: Endri Hoxha, Marcelo Deras, Eduardo Rodriguez

System Introduction

Traditional Rock Paper Scissors requires two people to play. Thus, a single person cannot play it alone. Our embedded system solves this problem, enabling single player gameplay of Rock Paper Scissors. By wearing a glove with the FRDM-Kl46z, a person can play Rock Paper Scissors against a 3D-printed hand that randomly generates a gesture. Our on board game program compares the user’s gesture against the board’s and makes the appropriate updates.

Hardware

•Resistor divider circuit for the flex sensors

•Power circruitry for the servo motors

Firmware

•Accelerometer data readings

•LCD screen updates

•ADC channel readings

•UART communication to an Arduino Nano ESP32

System Overview

In the diagram below is a general idea of the logic flow for our embedded system. The ‘final strike’ is indicated by an accelerometer reading less than -3g in the z-axis.

diagram_3140_fp_er_eh_md

System Description (technical overview)

For the analog to digital converter, first the clock needs to be turned on using the ADC0 clock mask. Then, the ADC is configured for how much precision we need. We only use 12 bits in our ADC since we do not need much precision. The flex sensor when unflexed has a very high impedance, and when flexed it is very low. We use a voltage divider with the flex sensor in series with a 24 kOhm resistor. There is also another voltage divider from the battery pack to feed roughly 2 volts into the flex sensor voltage dividers. The voltage is read from the 24 kOhm resistors and it would either be roughly 0 volts or roughly 600 millivolts. We chose not to use the built in averaging and instead make an averaging function because we wanted to start averaging from the moment we wanted to read instead of relying on the past data. This is because the MCU would read the voltage after we throw the hand sign, so using previous data would lead to our result being wrong. In the freedom board there are multiple pins that have analog to digital converter functionality, in the data sheet one can see if a pin has that functionality. There are many different channels for the ADC, which is shown in the data sheet and must be used. We used channel 2 and 23 for our project.

For the IMU, we used the SDK example to extract the accelerometer reading in the x-direction. We decided to use polling over interrupts for monitoring accelerometer activity as we wanted to monitor if the acceleration ever went below a threshold, not just basic movement. We utilized the functions from one of the programs that we created, gameprogram.c, to initiate a game when the accelerometer in the x-direction is less than -1g. We call game_function() to initiate the game, which then calls on hand_position() from adc.c to interpret the user’s hand sign. The computer’s hand sign is generated randomly using the random_number() function, and the two options are compared to each other to determine who won using win_conditions(). To drive the motors for the 3D-printed hand, we communicate to an Arduino Nano Esp32 over UART. Using a baud rate of 9600 and PTE22 from the MCU, we communicate a character that includes the number representing the computer’s hand signal. In the UARTservodriver.c file, we use the MCU UART message (1,2 or 3), to determine how the servos should be positioned, which should demonstrate rock, paper, or scissor. We utilized UART communication to an Arduino Nano Esp32 because of the built-in libraries in Arduino IDE supporting PWM generation functions for servo positioning. For the LCD, we initialize it by enabling the clocks for port peripheral base pointers B, C, D, and E and then setting the pin muxes to correspond to their appropriate pointers, pins, and muxes. This will be used to initialize the LCD. We also have a clear function for clearing the LCD which uses the SDK example. For displaying a digit on the LCD, we take in two-two digit numbers, one to represent the player score which is on the right and the other to represent the computer score. The computer is randomized within the ADC files to get a value of either 1, 2, or 3 and compares with the measured flexed positioning from the pressure sensors. For the actual display of the digit, we take in a two digit value and for the 1st digit we divide by 10 and find the remainder when dividing by 10. For example, 99 would be 9 and the remainder is 9. For the ones digit we just take % 10 of the ones digit. We use the displayDigit function to either display the number on the leftmost screen which corresponds to 1 or the rightmost screen which corresponds to 4. Once we calculate which is the winner, so if the player has scissors but the computer has rock, then the computer wins and we increment the saved computer score by 1 by using the increment function which displays the score. In the future, we want to change this from an endless game mode to cap off at some value, like best of 3, 5, or 7. unnamed

unnamed

System Testing

Given that our embedded system comprises many smaller subsystems (LCD screen, accelerometer, etc), we tested each subsystem individually before testing our embedded system.

Accelerometer

For the accelerometer, we used a program to print the readings of the accelerometer data in each axis (X,Y,Z), and ensured that they detected increasing acceleration in each axis.

LCD Screen

For the LCD screen, we used a program that displayed a given number and ensured that we could update the number (for score tallying) and reset it (for game resetting).

ADC Channels

For the ADC channels, we used a program to verify that it was correctly reading the voltage at the channel node.

After testing individual subsystems, we tested them together to continue ensuring correct functionality.

Accelerometer + LCD Screen

We wrote a program that polled the accelerometer and, if the accelerometer went below a threshold, it would call a game function where a set constant gesture (rock, paper or scissor) would be compared against the board’s randomized gesture and correctly update the LCD (depending on who won).

Flex Sensor + ADC Channels

We designed an external resistor divider circuit using the flex sensors and resistors. We then had the ADC channels read the voltage across the sensors. We then created a program to identify the three gestures via voltage thresholding and used it to ensure that the MCU could correctly identify the hand gesture based on the voltage readings.

UART Communication

For the UART, we ensured that there was proper communication between the Arduino Nano ESP32 and the FRDM-Kl46z by having the FRDM MCU send numerical data to the Nano and having the Nano drive servo motors if it received the correct data.

We finally tested the whole embedded system by wearing a glove with the MCU and playing rock paper scissors. The system correctly identified the last hit, the gesture we were making, and identified that we had either won, lost, or drawn against the board’s randomly generated gesture. Additionally, it correctly updated the LCD screen to show who won and represented the randomly generated gesture with the 3D-printed hand.

Resources

For the LCD, we used the fsl port file, fsl clock file, a TechForum response, the Kinetis KL46 reference manual, and the given lcd.c/h files as well. On the TechForum, it says to enable clock ports B,C, D, and E and we enable the clock by searching through fsl clock and on line 309 it says what the masks names are for enabling the clock. In fsl port on line 371 there is a function that applies the port pcr mux masks and has comments before on what to pass in for the mux. The rest is about initializing and clearing which can be found in the given lcd.c/h files.

TechForum: https://forum.digikey.com/t/using-the-segment-lcd-controller-on-the-kinetis-kl46/13277

For the ADC, we used the reference from Canvas on how to setup and read voltage, then from the manual we found what channel to use for which pin. For the accelerometer, we used the SDK example code for the FRDM-KL46Z development board (i2c_read_accel_value_transfer.c), provided to us in MCUXpresso.

Work Distribution

All 3 members, Endri Hoxha, Marcelo Deras, Eduardo Rodriguez, contributed equally to the project.