New Prediction Models
Update
Currently, there is a time restriction on sample collection which makes sure that accelerometer and gyroscope readings are collected within 100 ms of each other. This restriction and batch size are new tuning parameters which may affect how well our models can be trained and how well the state is predicted.
Training
The trainer class of the app now trains four separate models using their respective data.
Predicting
The predictor class has undergone the most obvious change as it predicts the state using four different models and displays all of this information on the screen. We wanted live updates for both the transformed data and the raw data so we could compare them. We thought this would allow us to evaluate which model was more accurate based on if we saw the correct state when we were performing that action.
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. This actually reduced the number of total data points compared to the raw data because we were turning five points into one. This means in the case of recording something like falling there may only be one or two data points in total per fall for mean, median and RMS. We will have to keep this in mind when training the app and make sure we have sufficient data to train the app well.
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. This actually reduced the number of total data points compared to the raw data because we were turning five points into one. This means in the case of recording something like falling there may only be one or two data points in total per fall for mean, median and RMS. We will have to keep this in mind when training the app and make sure we have sufficient data to train the app well.
Currently, there is a time restriction on sample collection which makes sure that accelerometer and gyroscope readings are collected within 100 ms of each other. This restriction and batch size are new tuning parameters which may affect how well our models can be trained and how well the state is predicted.
Training
The trainer class of the app now trains four separate models using their respective data.
Predicting
The predictor class has undergone the most obvious change as it predicts the state using four different models and displays all of this information on the screen. We wanted live updates for both the transformed data and the raw data so we could compare them. We thought this would allow us to evaluate which model was more accurate based on if we saw the correct state when we were performing that action.
Testing the update to app
We then recorded data for walking, running and going down the stairs and then trained the model for testing. Upon testing, we noted that the median and root-mean-squared models appeared to predict the state the most effectively. This revealed a problem, we ‘thought’ the app worked most effectively this way but had no way to prove it. This gave us the idea to add another feature to the app to record whether the app predicted the state correctly and put this in a file so it can be graphed.
Something that came up while discussing features was whether to also filter the data that is used to predict the state; like the training data. Filtering both makes sense because the purpose of filtering the data initially is to remove outliers that are negatively affecting model building and predictions. Therefore, we decided to filter the data used for predictions.
Written by James and Sam and proofed by Celine and Oli.
We then recorded data for walking, running and going down the stairs and then trained the model for testing. Upon testing, we noted that the median and root-mean-squared models appeared to predict the state the most effectively. This revealed a problem, we ‘thought’ the app worked most effectively this way but had no way to prove it. This gave us the idea to add another feature to the app to record whether the app predicted the state correctly and put this in a file so it can be graphed.
Something that came up while discussing features was whether to also filter the data that is used to predict the state; like the training data. Filtering both makes sense because the purpose of filtering the data initially is to remove outliers that are negatively affecting model building and predictions. Therefore, we decided to filter the data used for predictions.
Written by James and Sam and proofed by Celine and Oli.
Comments
Post a Comment