INFO305

Recording: After we had implemented the changes, we went out and recorded 4 minutes of each of the 5 states and took it back to the lab to analyse. We quickly realised that our data looked strange. Instead of our data being separated into 5 distinct different states and in the order we recorded, there was a fair amount of muddle and cross over. We realised this may have been due to us accidentally clicking buttons and recording data when using the app. This meant that our data was inaccurate, resulting in us having to record again. To avoid this happening again we implemented a few safety measures. Firstly, we got rid of the write button and made it so we automatically write to file every time we stopped recording. We also added a confirmation box that forced us to confirm the selected state before the app started recording. After this was done Sam, Celine and Oli went and re-recorded the data. After a final inspection, we were happy and ready to start prediction.  Pred...

Update - Bad Predictions: When it came to recording the states, we chose to keep the recording time across each state the same (two minutes) for consistency purposes. However, we then found that recording someone falling for two minutes was not very practical. This was because it took less than a second to “fall”, making it difficult for us to tell the app exactly when the fall started and stopped. Because of this, we decided to make a last-minute state change from falling to skateboarding. This didn’t require much change to the code as it was mainly just changing variable names and UI elements.  After we made this change, Sam and Al went home and recorded the skateboarding state for two minutes. With this done, we could train the models and start making some predictions. What we noticed straight away was that all the models were predicting very inaccurately. After realising all the models were performing poorly, the team sat down and had a much-needed whiteboard ses...

Update: Since our last blog we have updated the app in two ways. We now train models using both K-nearest neighbour and a bayes network. We also added a point system so we can evaluate and visualize the different training methods and filters. New training method The last version of the app only used the K-nearest neighbour method for training models. We decided as a team that it would be interesting to compare different learning algorithms to see which performed better and thus have an app with the greatest chance of correctly predicting your state. This meant that the app had to be updated to also train bayes network in parallel. This was relatively trivial because we could use the same data we recorded for K-NN as an input for the Bayes Net. Additionally the prediction part of the app had to be updated to show all eight, separate prediction methods (Figure below). Prediction Screen. Displaying eight separate models and state selection for testing. A points system for mode...

Update The last post we had a fully functional app, so naturally, we decided to fully rework it and get the weka training working on filtered data. We chose to filter data using three separate transforms: mean, median, root-mean-square (RMS). We made the assumption that removing outlying data will improve both our trained models and our ability to predict the state. Recording The record class of the app now filters the data in three separate ways and outputs the data in separate files along with the raw sensor data. This gives us four files in total to train our predictor: raw, mean, median, and root mean squared. Basic recording format. A file is created for each of the four types of data output. Filtering the data presented some new challenges programmatically. A new parameter was introduced to the recording class, which is the number of samples required before the transforms were performed. We called this parameter the ‘batch size’ and we set its default value to five. T...

Update Last night Sam, Alex, James, and Oliver finished writing the code for the majority of the app. We have completed recording functionality, Weka training functionality, and have completed the code to receive predictions from Weka. Our next step is to choose a feature (i.e Mean, RMS, Median) to help filter our data so that we can process fewer readings but more significant ones. Once we start playing with features, we will have to record highly controlled data so that we can build a comparison that allows us to measure the accuracy of our prediction feature by comparing the filtered data versus the raw data. Doing so will allow us to choose the best feature to operate on our data. Initial App Finished Now that the basic code for the app is finished, we decided to take the app for a spin and do some training. To begin we recorded some data for walking and sitting (sitting consisted of just being in a seat and using your phone, not the act of sitting down. After some playing around...

Weekly Update With the app now working for recording, we understand the direction we need to take to complete this project. We have 3 different functions that can be split into 3 separate apps or can be combined into one. The 3 functions are recording data, training data, and predicting the state. Our goal is to take the 3 functions and combine them into a single app. To do this successfully we will have to get classifier and state predictor code working. Then we can rearrange our app with a main menu that lists the functions: Recording, Training, and Predicting. Functionality The first menu item is recording, this part of the app has already been written and all we have to do is shift all the functionality down the navigation hierarchy so it is no longer on the main screen. The purpose of this function is to record data from the two chosen sensors at very similar intervals, then output the recorded values to the ARFF file followed by the state. Clicking the button will take us thr...

Weekly update: This week, we wrote a basic skeleton code app for Android OS. The focus of the app is to pull sensor data from our chosen device, reading from our list of chosen sensors. We started by building an app with 5 buttons: one button is linked to record each scenario we tell it to. So for example: when a button is pressed, the app begins recording the data from the sensors, the user then performs the action, and when the action is finished, the user pushes the button again and the recording stops. While the app is recording, the code locks the recording to that action, so you can't press multiple buttons as it would confuse the sensors and corrupt the data. The final step of our initial app is to take the data we have recorded from our session, and then write the output to a file, specifically an ARFF file (Attribute Relation File Format). Before writing to the file, we must first output the data in a format that ARFF accepts and that Weka (our statistics program) can u...

Overview Today we met during the assigned lab time to make a start on the second assignment. We started by discussing the assignment specification and clearing up a few of the details of what was required with Jacob. Our understanding of the assignment is to train an application to be able to classify 4-5 potential user/phone states based on two (or more) sensors on a phone. This will require generating a training/testing data set. To do this we will need to write an application that can log sensor values and their associated state. We can then use this data to train our application to predict what a user’s state is based on the current readings from the sensor. The Sensors The first two sensors we have chosen to use to train our model is the gyroscope and the accelerometer. The accelerometer and gyroscope are both considered orientation sensors. The accelerometer measures the amount of acceleration an object has in relation to gravity and other objects and is measured meters per secon...