As described in the figure below, I have successfully logged accelerometer data on the Keil debugger. We are now able to send the data to the STM32F4 microcontroller over an I2C interface. I did not set the device address alignment correctly last week and that was why I was not able to retrieve the data. The entire breakout board testing is completed. Moreover, Lingke also has finished designing and ordering the accelerometer PCB. We will start doing the soldering work as well as testing our customized accelerometer PCB as soon as we receive the board.

Table 4-1 Accelerometer Testing Status

Story	Status
Log the accelerometer data on a serial port using an Arduino UNO	Completed
Log the accelerometer data on a debugger watch window using STM32F4 microcontroller	Completed
Design and order a customized PCB for the accelerometer	Completed by Lingke
Test the customized PCB for accelerometer	Wait for Shipping

Figure 4-1 Successfully log the accelerometer data on Keil debugger's watch window

This week I also went through the Bluetooth API datasheet and designed a Unity app that does the basic data transfer between my iPhone and an Arduino UNO. Below is a screenshot of the app I designed. I can log the accelerometer data from Arduino. I can also send a command from my app to instruct the Arduino UNO to toggle an LED. An issue I found is that the HM-10 module does not support the write-with-response mechanism. This means the mobile app itself will not get notified after the write success. It will not receive a feedback indicating if the write transfer is completed or not. However, this shouldn’t be a serious problem that will affect the design as my Arduino UNO does receive the correct message. The next step is to test the Bluetooth LE device and the debugging Unity App with an STM32 microcontroller.

Table 4-2 Bluetooth LE Testing Status

Story	Status
Use the LightBlue app to test the connection between an Arduino UNO and an iPhone	Completed
Design a Unity app that communicates with an Arduino UNO over HM10	Completed
Communicate the Unity app with an STM32F4 microcontroller	Ready for Development

Figure 4-2-1 A screenshot of the Unity app

Figure 4-2-2 Toggle an LED from the app I designed

I also tested the DRV2605 Haptic Driver and the vibration motor with an Arduino UNO. The haptic driver is a chip that uses I2C to communicate with a microcontroller and PWM to drive a vibration motor. According to its datasheet, the haptic driver is able to send over 100 types of pulses to a vibration motor. We can also adjust the vibration duration by updating the waveform sequence registers. There was an Arduino library available but I did not want to use it, as configuring the library with an STM32 microcontroller could be difficult. Therefore, I decided to carefully follow the datasheet and write my own functions that perform the equivalent tasks. The vibration motor is now able to provide a various types of haptic feedback through the DRV2605 chip. Hengyi will continue playing around with the touch feedback mechanism and find the waveform combinations that best simulate the sense of collision for our project. Meanwhile, I will transfer the Arduino code to embedded C and test it with the STM32 microcontroller. I am planning to complete the code conversion work by this weekend.

Table 4-3 Haptic Driver Testing Status

Story	Status
Test the haptic driver with an Arduino UNO	Completed
Convert Arduino code to embedded C for STM32 microcontroller	Under Development
Test the haptic driver with an STM32F4 microcontroller	Analysis

Figure 4-3 Testing Haptic Driver with an Arduino UNO

Lastly, I also helped Hengyi test the linear servo with an STM32 microcontroller. I adjusted the timer CCR registers using the HAL library and the microcontroller is now able to slide the servo back and forth. The next step is to integrate the mechanical component (contact handle) with the linear servo. Hengyi and Yutao will take care of this part.

Table 4-4 Linear Servo Testing Status

Story	Status
Test the linear servo with an Arduino UNO	Completed by Hengyi
Test the linear servo with an STM32F4 microcontroller	Under Development
Integrate the mechanical components	Analysis

Figure 4-4 Testing Linear Servo

Last week I built an Arduino prototype that communicates with the Unity app I designed over the HM10 Bluetooth module. This week I built another prototype using the STM32F4 microcontroller. I used CubeMX to set up the baud rate configurations and routed the UART pins to the Bluetooth module. I successfully transmitted the accelerometer data from the microcontroller to the debugging Unity app I designed. I can also toggle an LED from the app. The Bluetooth communication testing is completed.

Table 5-1 Bluetooth LE Testing Status

Story	Status
Use the LightBlue app to test the connection between an Arduino UNO and an iPhone	Completed
Design a Unity app that communicates with an Arduino UNO over HM10	Completed
Communicate the Unity app with an STM32F4 microcontroller	Completed
Route the Bluetooth LE module to the main PCB socket	Not Ready Anytime Soon

Figure 5-1 Bluetooth and STM32F4 Testing

As I mentioned in last week’s progress report, I was working on the Arduino to STM32 code conversion. I used the HAL library to perform I2C communications. I also wrote functions that decode commands coming from a serial port and send collision pulses to a vibration motor. The STM32F4 microcontroller is able to provide a various types of vibration feedback. The haptic driver testing is completed.

Table 5-2 Haptic Driver Testing Status

Story	Status
Test the haptic driver with an Arduino UNO	Completed
Convert Arduino code to embedded C for STM32 microcontroller	Completed
Test the haptic driver with an STM32F4 microcontroller	Completed
Solder the chip on the main PCB	Not Ready Anytime Soon

Figure 5-2 Control the DRV2605 chip using I2C

The GS1502 linear servo we were testing last week seems to be too fragile to slide a contact handle. The sliding mechanical portion gets stuck easily. We decided to use an SG90 Servo with an alternative mechanical structure to apply the haptic torque cues. The new mechanical structure will be described in the revised Mechanical Overview documentation. I was testing the SG90 Servo with an STM32 microcontroller this week. I used the function generator to send pulses to the servo and the oscilloscope to track the waveform. Then, I used the STM microcontroller to duplicate the same pulses and tested it with the servo. We are now able to rotate servo to the desired angles. The next step is to design a contact handle prototype and to slide the mechanical prototype with servos.

Table 5-3 Servo Testing Status

Story	Status
Test the linear servo with an Arduino UNO	Completed by Hengyi
Test the linear servo with an STM32F4 microcontroller	Completed
Testing the alternative servo with function generator	Completed
Testing the alternative servo with an STM32F4 microcontroller	Under Development

Figure 5-3 Debugging Servo Using Function Generator and Oscilloscope

We received the OKI-78SR voltage regulator from Digikey and started testing it with some of the firmware components. This is the voltage regulator recommended by Professor Mithuna. According to its datasheet, the regulator is able to provide a constant 5V output at a 90.5 % efficiency. However, we were having trouble testing the voltage regulator with the servo. The voltage drops significantly after the servo is attached. After consulting the course staff, we learned that the battery we used was not able to provide enough current. We switched the battery and servo is now able to function properly. The next step is to put the voltage regulator and the other firmware components together and to build a complete prototype.

Table 5-4 Voltage Regulator Testing Status

Story	Status
Solder the voltage regulator chips	Completed by Yutao
Test the Voltage Regulator output using DMM	Completed by Yutao
Test the voltage regulator with firmware components	Under Development

Figure 5-4 Voltage Regulator

The firmware component testing is pretty much completed. The next step is to design a mechanical prototype. I used Blender to draw a conceptual design layout. Below is a screenshot of the model. After consulting Yutao’s friend, who’s been working with 3D printer extensively, we learned that there were many restrictions in 3D printing model design (e.g. curved surfaces, geometry, holes, size). The model I drew in Blender was actually not suitable for 3D printing. The printed model is likely going to have strange artifacts. Therefore, we decided to use an existing model from an open source site for our preliminary prototype. We went to a friend’s place and print out a model that seems to be suitable for our design. It turned out that the printed model is also too small. The conclusion is that we will have to re-design another prototype that better fits with the digital components.

Table 5-5 Design Package Status

Story	Status
Drafting the Design Package Layout	Completed
Make a prototype using a 3D printer	Under Development
Re-design the design package model	Ready for Development

Figure 5-5-1 Drafting design layout using Blender

Figure 5-5-2 preliminary 3D printed model

This week I also started designing the VR app. I downloaded Google Cardboard SDK and updated Unity settings so we could utilize the iOS Virtual Reality capabilities. Additionally, I also set up the rigid body, collider, mesh renderer, hinge joint, and fixed joint properties of the hitting target objects and started coding the sword rotating logic. The next step is to visualize the sword movement in a Unity simulation.

Table 5-6 VR Development Status

Story	Status
Download VR SDK and basic Unity setup	Completed
Design the Bluetooth Controller Block	Under Development
Test the sword movement in a Unity simulation	Under Development
Test the sword movement using the accelerometer data sending from Arduino UNO	Analysis
Design the haptic manager block	Not Ready

Figure 5-6 Design VR app in Unity

I applied the algorithms described in the “Software Overview” document and designed a VR app that uses the accelerometer data to rotate a digital sword. I connected my Arduino prototype to the Unity Game Engine over a serial port, calibrated the accelerometer data, and made a simulation in Unity. After ensuring the sword was able to rotate to the correct orientation, I transferred the Bluetooth scripts I wrote earlier to the current project scope and deployed the app to my iPhone. We are now able to retrieve the data from the microcontroller wirelessly over a Bluetooth module. We can also use the tilting angle data to visualize the sword movement. The tilting orientation of the digital sword matches the perceived touch feelings. This should satisfy the minimal requirement for our first two design specific criterion. Additionally, I also tutored my teammate, Yutao, about how to use C# scripting to manipulate prefabs and objects in Unity. I had him review and understand the code I wrote as well as the setup I made. The next step is to design the haptic manager block, which logs the collision information from the Unity physics engine and uses conditional statements to determine the types of haptic feedback the hardware needs to provide.

Table 6-1 VR Development Testing Status Testing Status

Story	Status
Download VR SDK and basic Unity setup	Completed
Design the Bluetooth Controller Block	Completed
Test the sword movement in a Unity simulation	Completed
Test the sword movement using the accelerometer data sending from Arduino UNO	Under Development
Design the haptic manager block	Not Ready

Figure 6-1-1 Designing the VR App in Unity

Figure 6-1-2 The second scenario I designed

Figure 6-1-2 Deploying the App to iPhone using Xcode

This week I also tested programming the microcontroller from the SWD pins. This is a critical step we need to complete before drawing the PCB layout. I was trying to use the programmer on the first discovery board to program the microcontroller on the second discovery board. I removed the jumpers at the CN3 pins to isolate the programmers from the micros. Then, I routed the external SWD pins from the first discovery board to the corresponding microcontroller header pins on the second discovery board. However, I was not able to program the micro from the Keil debugger because the reset pin was held down by a solder bridge. Even after consulting the course staff and removing the solder bridge, I was still having problems programming a micro from a separate programmer. For some reason the micro wouldn’t make any response. Therefore, I decided to borrow a ST-Link V2 from the course staff and tried to use it to program the micro over SWD. It was finally working.

Figure 6-2-1 Programming the STM32F407VG microcontroller from the SWD pins

Besides testing the SWD interface, I also assisted Lingke in designing the schematic. I consulted the course staff about some of the confusions we had in the STM32F407 datasheet and took notes on the parts we need to be cautious about (e.g. The oscillator has be to located as close as possible to the micro and the length of the two traces has to be equal). The next step is to design the PCB layout and to verify the work with the course staff.

Figure 6-2-2 Taking notes on the schematic

Additionally, we also received the accelerometer PCB Lingke designed couple weeks ago. Yutao and Hengyi took care of the soldering job under the help of the course staff. I used the STM32F4 discovery board to test the chip. We are able to log the accelerometer data on the Keil debugger. The accelerometer testing is completed.

Figure 6-2-3 Testing the accelerometer PCB using STM microcontroller

I downloaded a linear servo mechanical structure from an open source site and printed out the model at Purdue BoilMAKER Lab. The 3D model is a perfect fit with the SG90 servo. I assembled the mechanical parts and used the STM32 microcontroller's PWM features to drive the servo. It was working perfectly.

Figure 6-3-1 Linear Servo 3D Printed Model

Figure 6-3-2 Linear Servo 3D Printed Model

Figure 6-3-3 Linear Servo 3D Printed Model

I also started drawing the second version design package prototype using Google SketchUp. Below are some of the photos. We still need to adjust the size and dimensions to ensure that all the electrical and mechanical components would fit it.

Figure 6-3-4 Preliminary Design Package Model

Figure 6-3-5 Preliminary Design Package Model

Figure 6-3-6 Preliminary Design Package Model

Figure 6-3-7 Preliminary Design Package Model