Journal for CREU 2016

Week 1: August 29 - September 4

I began my first week of the CREU program by meeting with my PhD advisor Brittany English. We discussed the current direction of this project based on work that we had done in previous semester's. Currently, we have one modified car that so that it can be controlled using a joystick. In addition to the the modifications that allow this control, we also added a system that will allow us to monitor the actions of the child driving the vehicle. The movements of the joystick are also saved to a text file.

However, there were some issues with the modidfication that were made. Though the controls work, there are some inconsistencies in the operation. At times, the car does not respond as expected when the joystick is moved. Also, there are issues with the storage of the text files created while driving the car. We would like to correct these issues before beginning work on the car that will be controlled using the Microsoft Kinect.

Week 2: September 5 - September 11

My second week of CREU was focused on determining the issues with inconsistent control issues with the joystick controlled vehicle. My first concern is cleaning up the wiring of the vehicle. The final wiring of the vehicle was somewhat rushed due to deadlines. Also, the use of an Arduino microcontroller increases the difficulty of clean wiring because it is not easily mounted to a breadboard or perfboard. To improve upon this, I would like to build an Arduino directly onto a perfboard. This will allow me to clean up wiring and solder it directly to the perfboard. I submitted an order list for parts this week to make sure that I can start this as soon as possible.

While the parts are being ordered, I wanted to get a better understanding of the code used to record the driving of the car. This code was created by a team member that I worked with in the previous Fall and Spring semester. This code is run on a Raspberry Pi 2. I would like to get a better understanding of what was done so that I can modify it to improve the data recorded into a text file. Initially, we planned to do this using the Arduino microcontroller, but we do not have enough pins on the device to allow this. Instead I would like to send the data from the Arduino to the Raspberry Pi 2, then save it onto the hard drive where video recordings will also be stored. I have schedulued a meeting next week to get a better understanding of why things were done in the manner that they were.

Week 3: September 12 - September 18

During my third week of CREU, I continued to look into fixing the exisiting data collection methods. After meeting with Philip Wolfe, my previous team member who created the data collection system, we were unable to think of an effective way to send the text data to the Raspberry Pi 2. This is an issue because we are only able to transmit data using the I2C communication protocol. To communicate in this manner, we need to make sure that only one thing is using this at a time in our system. However, when the Raspberry Pi is attempteing to recieve the text from the Arduino, the Arduino is also using I2C to read the time from a clock that we are using. Because the Arduino's pins are mostly filled, we can not use another means of communication to send the text to the Raspberry Pi.

However, our system also allows a parent or caregiver to control the vehicle using a bluetooth application. Currently, this application is only responsible for sending signals. However, before this applicaiton was created, I utilized a Bluetooth Terminal application on android for texting. This allowed me to send data to our system to move the car, and see text printed out by the Arduino. Because of this, I believe that we would be able to read in the data via bluetooth, and save it to the phone or tablet of the caregiver or parent. This would mitigate the hardware issues that we were having. I will look into this next week.

Week 4: September 19 - September 25

I have began looking into updating the application that we have so that it can read data in and save it to a text file. Firstly, I want to determine the best way to make the user aware of whether or not the data is being recorded. I believe that beneath the buttons, that allow the user to control the car, I could put a green check, or a red x which states whether or not the vehicle is connected. Once the vehicle is connected to the phone, it should automatically create a text file, and start recording.

I will begin looking into implementing this in code next week.

Week 5: September 26 - October 2

By examining the code, I was able to determine that there is exiting code that should partially handle incoming messages via Bluetooth. I do not remeber seeing this values being displayed when using the app in the past, but others seem to remember it. This could mean that the messages are received inconsistently, or just not displayed properly. To monitor this, I am looking into modifying this code so that the received messages are also saved to a text file. This will allow me to determine if all the data is being received even if it is not displayed on the screen. This will also be necessary for the data we need to validate our hypothesis.

This week I also received some of the parts needed to construct an Arduino Uno on a protoboard. I will continue to work on the bluetooth issues while waiting for the missing parts.

Week 6: October 3 - October 9

I have found some examples that will help me take the necessary steps to save the bluetooth data to a file. I began by getting functionality that just created a generic text file and saved it to the phone to make sure that it works, and to determine if the desired directory was created on the phone. Once this was completed, I began working to manipulate this code so that the incoming messages from the bluetooth device are saved to the same file one line after the other. Currently, I was able to get the initial string to save to the text file, and am working on a few bugs.

I also received the missing parts that were mentioned last week. This will allow me to build the Arduino Uno onto a perfboard and improving upon the loose wiring in the car.

Week 7: October 10 - October 16

This week I was able to move from a generic text file. With the changes to the code, when the application is opened, a new text file is created with the date and time that the application was opened. These files are saved in a folder on the device called "Trials". Once this is done, the app connects to the car via Bluetooth and waits to receive messages from the device. Each message is appended to the file on a new line. Initially I ran into issues with saving multiple lines of data, but this was caused by closing the file too soon. Messages from the car provide information on who is controlling the car, which direction the car is moving, and what time this event occured. This information is useful because it wil be matched up with video from the trials. When this information is synced, we will be able to determine if the child is improving in their ability to use the vehicle, and if they are carrying out goal oriented movements. When a child is controlling the car, and they are moving it in the direction of an object or person that they are looking at, this is considered a goal oriented movement.

With this issue handled, I will focus on creating an arduino on a protoboard next week to improve the reliability of the wiring in the vehicle. I will also look into determining how to give the user of the app the ability to create a new file when they desire to do so. This could be useful if they want to start a new recording without having to close the application.

Week 8: October 17 - October 23

With the bluetooth data collection method working, I began working to build the Arduino Uno onto a protoboard using instructions provided here. Following these instructions I was able to get all of the parts soldered onto a breadboard as instructed, but I ran into an issue when attempting to program the Atmega chip. I decided to utilize the Sparkfun FT232 as recommended to program the chip. However, when connecting this device to both a Mac and PC, I neither computer was able to recognize the connection. To make sure it wasn't the chips that I purchased, I removed the Atmega chip from an Arduino Uno and replaced it with one that I had purchased. In doing this I was able to program the chip without an issue. Following this, I disconnected the wires from the Sparkfun FT232 to make sure that it wasn't being shorted, but the device was still unrecognizable. The website provides alternatives to programming the chip that I may utilize until I am able to order a new device from Sparkfun. I can program the device by placing it onto an Arduino Uno. This will allow me to connect the Uno Board and program the chip, then place it onto the protoboard. The only issue with this approach is that it prevents changes in code once the Atmeaga chip is soldered to the board. However, I could use the approach provided at this link. to program the chip using an Arduino Uno board with the Atmega chip removed. This is the most favorable programming alternative.

Week 9: October 24 - October 30

This week, I decided to order knew chips to allow serial communication between the Atmega chip and a computer so that these chips can be programmed. While waiting on this, my focus was on working with the existing setup of the car to prepare it for a demonstration that would take place on Tuesday, October 25th. In doing this, I ran into an issue with a library that I had been utilizing to read time from a real time clock. When opening my existing program in the Arduino IDE, one of the data type for one of the variables utilized for reading time was not recognized as a type. Because this would not affect the demonstration, I decided to comment out the portion of the code that was preventing it from compiling and address this at a later time. With this code commented, my focus was on issues with the motor controls. With the way that the code is structured, if the joystick is not being moved, the actuator is supposed to center the wheels. If the joystick is moved to the left or the right, the wheels should be turned in that respective direction. However, the wheels consistently pointed to the right. Debugging allowed me to determine that this was due to issues with the battery. The program utilizes the reading from the actuator's potentiometer to determine whether it is extended, or retracted, and how far it has gone in either direction. The value is dependent upon the battery being used. When the battery is working properly, the values for extension and retraction ranged from around 200 - 600. However, in the current state of the battery, the values range between 200 - 230. This prevents the existing algorithm from working properly and being able to determine whether to extend or retract the actuator. In hopes that this was an issue of the battery simply being drained, I charged the battery overnight. This improved the values some, but did not provide enough variation in the values to allow them to be utilized to correct the algorithm. I am not currently sure what may have caused these issues with battery.

Week 10: October 31 - November 6

With the demonstration in the past, I went back to focusing on building the Arduino Uno onto the perfobard. I also looked into the issues that I was having with libraries utilized for reading the current time from a real time clock. I was able to correct this issue by downgrading the Arduino IDE from version 1.6.12 to 1.6.10. This allowed the Time.h library to be used in the code along with a variable of type tmelements_t. This variable type was not recognized with the update. This week, we also recieved the new chips to allow serial communication between the computer and the Atmega chip. While the computer recognizes these new chips, I was unable to program the Atmega chip connected to the perfboard. However, I was also unable to program an Arduino Uno using my computer. I am under the impression that a software update may have caused this issue as I have had issues with software update making software function improperly in the past.

Week 11: November 7 - November 13

This week, I wanted be sure that my computer was the issue by attempting to upload programs to the perfboard and origianl Arduino Uno using Windows devices. In doing this, I ran into issues with older model Windows devices. In an attempt to update the Arduino IDE to 1.6.10, the installer failed repeatedly. When moving to another windows laptop, I recieved sync errors which prevented the chip from being able to program the perfboard. I also recieved this same issue with the normal Arduino. However, I realized, that the issues with the normal Arduino was simply user error. When testing the new Atmega chips that I purchased, I removed the chip from the normal Arduino to make sure that the chips I purchased were already bootloaded, and would work as expected. However, when placing the original chip back into the device, I placed it in the wrong orientation. When I fixed this, I was able to upload programs to the Arduino Uno as expected. This week I also wanted to look more into the battery issues. In the lab, we have two batteries. Both batteries are 12v, but one has a 2.8A max current draw while the other is around 3.6A. I wanted to test the battery with the 2.8A current draw because it had not been utilized in the vehicle, which means that it should not be degraded. I charged this battery for a day, and then tested it. When testing this battery, the motor was unable to turn fast enough to move the car. The front wheels were able to turn. I wanted, to continue testing the 3.6A battery by charging it over the weekend.

Week 12: November 14 - November 20

This week, I focused mainly on applying for the Ford Foundation Fellowship. With this task completed, I revisisted the tests with the 3.6A battery. After charging it for two days, the battery was finally able to drive the car forward. However, it was not moving at the max speed of the car's motor. To make sure that the battery is the issue, and not a burnt out motor, or poor circuitry, I am ordering a new battery. If this proves to be the issue, there is no justification for continuing to attempt to build an Arduino on a perfboard. Working towards this task would take away from time that could be used to clean up the existing design to ensure that it can be used by anyone who comes into the lab and is curious about the capabilities of this vehicle.

Week 13: November 21 - November 27

This week, was spent at home with family and friends for the Thanksgiving holiday. The new battery has been ordered, and I am waiting for it to arrive.

Week 14: November 28 - December 4

With the semester coming to a close, I am focused on putting the vehicle back together in the most effective way possible. In the context of this project, this means that I want the car to be easily utilized by anyone in the lab. The Arduino and Raspberry Pi should also be easily accessible for programming. Most importantly, movement of the car should not cause wiring to become loose, and produce erratic results for the user. To accomplish this, I have been shortening excessively long wires, and tucking them in the car where possible. I am also cutting out channels in the car to allow the hard drive used for video storage to fit securely in the car .