Progress Report for Erin Hill
Week 1:
Date: 8/25/17Total hours: 3
Description of design efforts:
As a team, we completed the final project proposal and setup a Google Drive for sharing files, and a git repo for code.
Week 2:
Date: 9/1/17Total hours: 5
Description of design efforts:
This week I created a preliminary BOM for out project based off discussion we had the previous week. This BOM contains information about the necessary parts, basic operating characerstics, and price. Although prelimary, it provides a better scrope for how much time hardware design will take and the necesary components of the firmware. In addition, for the document due this week, I completed the computational constraints, thermal/power constraints, and economic constraints sections.
Week 3:
Date: 9/8/17Total hours: 6
Description of design efforts:
This week I worked on setting up the environemnt for our STM32F0 Discovery board. After setting up all the necessary programs, I was able to successfully run the example code to turn on the onboard LEDs. After that, I worked on understaing how the IDE, microvision 5, worked, as well as how to work with the STM32CubeMX in order to easily add peripherals to the design. I was able to once again turn on/off the onboard LEDs, but through the means of creating and specifying GPIOs with STM32CubeMX like a normal project. In addition, I went through the datasheets for the STM32F0 to read about the different peripherals and memory management of the micro. For next week, I will look at what parts we have preliminary selected and work to understand and write initial interfaces for these components. Although I won't be able to test the parts, I will have a better start for when we actually get the parts.
Week 4:
Date: 9/15/17Total hours: 6
Description of design efforts:
This week I worked on interfacing with our 16x2 LCD. Part of our project is to display the status of the recognition to the user via an LCD. The plan was get the 16x2 LCD working as it is part of our PSSC's, and then move on to try to configure our more complex LCD (a 2.8 TFT 240x320 graphical LCD). The 16x2 LCD was successfuly configued by using the RX port of the USART peripheral on the microcontroller. Initially, I had thought to use the SPI bus from the microcontroller, but only the UART could be configured to match the baud rate of the LCD at 9600 baud. As we now have a means of succesffuly using an LCD, I will use next week to work on figuring out how to utilize a GPIO pin as a PWM signal in order to interface with our servo motor. With any extra time at the end of the semester, I will go back and try to configure the more complex LCD.
Week 5:
Date: 9/22/17Total hours: 8
Description of design efforts:
This week I worked on configuring the PWM in order to control the servo for automatically locking/unlocking the door. For the STM32F0, I used pin PC8 as my PWM output meaning I utilized the TIM3 peripheral. Using CubeMX, I set Channel 3 to the setting "PWM Generation CH3". Based off the specs of the servo, to turn 90 degrees back and forth, it requires pulses of 1.5 ms and 2 ms. The equation I used for determing the correct prescalar and resolution values was: Prescalar = (Micro Clock)/(PWM Frequency * Resolution). The micro clock runs at 48 MHz, and I chose my resolution to be 100 as it made the calculation eaiser. As for the PWM frequency, I used the longer pulse width of 2ms (500 Hz). Since the servo needs a pulse of 2ms, I divided the 500 Hz by 2 and used 250 Hz as my PWM frequency so the signal would be high for the full 2 ms. These values resulted in a prescalar of 1920 for the 2 ms pulse.
In the code, I used HAL_TIM_xx functions to control the signal. Since the resolution is set at 100 aimed for the 2 ms pulse, I use the function
>__HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_3, 50); where the first parameter is my handler for using TIM3 functions, the second paramter is which channel I'm using of TIM3, and the third parameter is the max count value. Since I set the resolution to 100, a count value of 50 will have a 50% duty cycle resulting in the 2 ms pulse. For the 1.5 ms pulse, I use the same settings, but change the maximum count value to 38.
Although we do not have the specific servo of the project, we did have access to a smaller servo with similar timing parameters. I utilized the on-board pushbutton to change the PWM output for the 2 ms and 1.5 ms pulses and was successfully able to move the servo accordingly.
I also wrote the product 1 analysis for the Mechanical Overview document. As for next week, large parts are expected to arive on Monday. I will test that my PWM functionality works correctly on the actual servo the project is using. In addition, I will write an interace to communicate with the keypad and validate inputs.
Week 6:
Date: 9/29/17Total hours: 8
Description of design efforts:
This week our large components were delivered: the servo, keypad, PIR sensor, and LEDs. I started by making sure the code I wrote last week still worked for the actual servo we're planning to use. The servo worked correctly for about 30 seconds before killing the dev board. In the future, I will isolate the power to not come from the dev board to avoid this issue. In addition, I worked to interface with the keypad. This included utalizing GPIO registers as both inputs with internal pullups, and outputs. Instead of using HAL functions, I utlized the actual GPIO registers so, when setting an output on the keypad, I could do it atomically instead of waiting for the RMW process to finish. Once I was able to detect key presses, I wrote an implementation to decode the key press and save the sequence. I made the arbitrary password "1234" and wrote to the LCD when the user input matched or didn't match the password. As for now, there is a 4-digit limit on the password, but next week I will work to create a more flexible way for the user to set their own arbitrarily lengthed pincode.
Next week I will work on interfacing with the PIR sensor to wake the microcontroller from a sleep state and work to figure out how to use the I2C peripheral in order to communicate with the Raspberry Pi.
Week 7:
Date: 10/6/17Total hours: 8
Description of design efforts:
This week I worked on the Software Formalization Document as well as the Midterm Design Review Presentation. I also worked on utalizing the PIR sensor as an interrupt to wake the micro up from a sleep mode. I first set the appropriate GPIO pin for the PIR sensor as a rising and falling edge interrupt so the micro will have the ability to go back to sleep once a person is not infront of the door. I then used HAL functions to test the IRQHandler() for the STM32F0. After I had the interrupt working, I then figured out how to send the micro into sleep mode. This is done by modifying the System Control Register. There are three parameters to change: SLEEPONEXIT, SLEEPDEEP, and SEVONPEND. The first parameter defines if the micro should return to Thread mode (ie mode out of reset) or go back to sleep once exiting an interrupt. SLEEPDEEP defines if the micro should enter sleep or deepsleep mode. For these purposes, wake up time is not as imperative so deepsleep mode was used, which disables the CPU clock. The last parameter defines whether enabled and disabled, or only enabled interrupts are able to wake the micro. It is currently set for both enabled and disabled as it is the default and there is only the one interrupt in this project. I was then successfully able to initially put the micro into a deepsleep mode, and once the PIR sensor went high, the micro was able to return to normal operation. For next week, I will work on putting the micro back to sleep once the PIR sensor goes low again. Also for next week I will continue to work on the Design Review Presentation.
Week 9:
Date: 10/20/17Total hours: 8
Description of design efforts:
This week I worked on communicating to the Raspberry Pi via I2C. I utalized the first I2C bus on the micro at 100 kHz. I was then able to successfully send and recieve a message to the Pi using the HAL I2C transmit/recieve functions at address 0x40. After the I2C had been determined to work, I then added to the code so the user is able to indicate they want to take a picture to be used as their recognition. The process for this included pressing * and # on the keypad simulatneously to enter into the "take a picture" functionality where the user would then be asked to provide their pincode, and then be able to take a picture by pressing any key on the keypad. Once the user had entered the correct pin and pressed any key, a message is sent to the Pi indicating to take a picture to add to the data set. I also worked on getting the larger servo to work by utalizing a 5V supply from a power supply intead of the microcontroller. The servo was able to slowly move, but more testing is needed.
Week 10:
Date: 10/27/17Total hours: 8
Description of design efforts:
This week I worked on finishing interfacing with the servo, and combining different components to work in tandom with each other. The servo took longer to get working than expected, but was successfully able to rotate when being powered off an external power supply as the current usage can sometimes be a maximum of 2A. After that, I worked to combine the PIR sensor, keypad, servo, and LCD. When the PIR sensor wakes the micro, the keypad is polled for input. When the keypad receives the right sequence, the LCD indicates success and the servo rotates to unlock the door. In addition, code has been written for waiting for a response from the Pi indicating the facial recognition status. The response is tied to the same response as a correct keypad input so the door will unlock accordingly. Pressing the # key on the kepad will lock the door if it is unlocked, and the door can also manually be locked as well.
Week 11:
Date: 11/3/17Total hours: 8
Description of design efforts:
This week I worked on soldering the PCB and writing the Safety and Reliability document. For the team document, I looked into possible failures with the micro and and its peripherals, and how these failures would effect the system. For the PCB, I began by soldering the resistors and capacitors on the board. As this was my first time soldering, it was a very slow process in learning how to solder surface mount parts. We also learned that we will need to use solder paste and the reflow oven to solder our voltage regulators, which is another learning curve to tackle. Noticeably missing is the micro, which I will also need to learn how to solder correctly next week. The pin headers should be the easiest part to solder as they are through-hole. In addition, while soldering, I tested connections to make sure I soldered accurately.
Week 12:
Date: 11/10/17Total hours: 8
Description of design efforts:
This week I worked on soldering the surface mount parts of the PCB and the Environmental and Ethical document. The stencil for soldering was delivered Tuesday and we were able to begin on Wednesday during lab. I was in charge of spreading the solder paste and placing all the surface mount components. The hardest placement was the micro. After the PCB was put in the reflow oven, we were able to test connections. The micro had many bridges had to be taken off and re-soldered. Then, we were able to verify the connections on the micro. When testing the PCB connections on the board, I noticed a mistake with the power line to the LCD and we will fix this issue next week. Also next week, I will work on soldering the final through-hole components in order to finally try and turn the board on. If all goes well, I will then work on programming the micro and verifying that functionality is still the same as in the prototyping phases.
Week 13:
Date: 11/17/17Total hours: 10
Description of design efforts:
This week I worked on bringing up the board and verifying all the firmware prototyping on the actual PCB. First, I fixed the voltage regulator issue by noticing that the resistors determining the output voltage were not grounded. After that, we noticed that the micro was not able to pull any signal down. After looking at the micro under a microscope, we saw that some pins were bridged and fixed that issue. After that, I realized that the Rx line from the micro was connected to the Rx input on the LCD, instead of the signal coming from the Tx output. I also found the problem that the LCD was connected to 3.3V instead of 5V. To fix these problems, the 3.3V trace was cut and I soldered the power connection to 5V. Then, I was able to find a UART setting such that the Rx and Tx signals are switched on the micro. This way the actual trace on the board would not have to be modified. Next, I tested the keypad and the LED's. For the keypad, I had to increase the debounce period in order to have a more stable input. After that, we tested the I2C transactions and were successfully able to send data to the Raspberry Pi. After that, I tested the servo. An issue I found with the servo was that it would not rotate counter-clockwise completely at any 1 ms, 1.5 ms, or 2 ms pulse widths. To fix this issue, I experimented with different duty cycles until I was successfully able to rotate the servo counter-clockwise and lock the door. Finally, I tested that the PIR sensor worked. To test this, I wrote temporary code that after the keypad was pressed four times the micro would fall asleep and not wake up until an input from the PIR sensor. With this code, I was able to verify that the PIR sensor still worked as an input and that I was still able to put the micro to sleep and wake it up again.
Week 15:
Date: 12/1/17Total hours: 10
Description of design efforts:
This week I worked on the I2C communication between the Pi and the micro, as well as finalizing the implementation of the PIR sensor to wake the micro from a sleep state. Originally, the plan was for the I2C to work an an interrupt to the micro so the user could use the keypad at the same time the facial recognition is happening. To simplify debugging, I made it so first the facial recognition will run, and then after the result of success or failed facial recognition, the user can use the keypad. For future optimization, I can work to debug the original implementation. Once we were able to succesffuly send and recieve info to and from the Pi and micro, I finalized how the code would loop. This is to say I finished writing how the micro starts to send data, what happens when it recieves information from the Pi, and what the user can do to either try facial recognition again or use the keypad. After that, I worked on finalizing the PIR sensor to work as a wake up to the micro. I finished the implementation of the micro going to sleep if there has been no input to the micro, from either the Pi or keypad, and the PIR sensor detects no user. Once the PIR sensor does detect a user, if the micro was originally in sleep, the micro will wake up and begin the facial recognition process. Finally, I finished the code for the LEDs so that they will turn on when there is a user present, and turn off when the micro is about to go to sleep.
Week 16:
Date: 12/8/17Total hours: 8
Description of design efforts:
This week I worked on bringing up the design in the final packaging. This mainly involved finding the necessary wires and mounting the 3D printed casings on the door. Mounting all the pieces and wiring them to the PCB took the longest time as the spacing of the headers on the PCB did not allow for easy use of ribbon cables. For testing purposes, I also added to the code so that a user can manually restart facial recognition after success, instead of waiting for the device to go to sleep like normal. As an actual product, only restarting facial recogntion after success on wakeup makes sense, however for quickly demo-ing this project, I changed some of the functionality. Most of the time this week was spent verifying facial recognition with the mounted casing and lightings. This involved retaking pictures to improve the data set since we had consistant lighting and position of the camera.
