# Kalman Filters

```
/*
Explaination of Kalman Filters
By: Zachary Sasser

A kalman filter is basically a fast way to find a real value for a sensor.
(A fast way to find averages in a way but don't mistake it as a way to find a mathematical average)

We could just take a ton of data and take the average and remove outliers and it probably would give you the true value you want.
But taking the average method usually requires a lot of data to get accurate and
on timing intervals like acceleration that means inaccuracy and timing issues.

A kalman filter can converge to a value with much less data than a simple average
and when combined with things like a low pass filter you can get pretty good accuracy
on pretty inaccurate hardware.

*/

//Use pathagorean theorum to get the magnetude of acceleration.
//If the values are negative the value will come out negative (because CS != math) and so use abs(); (absolute value)
int getAccel(){
return abs(sqrt(pow(accel_x(),2)+pow(accel_y(),2)+pow(accel_z(),2)));
}

double KG; //The kalman gain (a coefficient explained later I'm just defining it here)
double change; //You normally don't use this I'm seperating the variables to explain things easier

int main(){

//Get an inital guess at what we think the number probably is.
//You can actually set this value to pretty much anything random because the kalman filter will narrow down the value very fast anyway.
double estimation = getAccel();

//Print our initial estimate so its tangeble for us to understand
//NOTE IF YOU DON'T DO %f you'll get giant values because we are working with doubles not ints
printf("Initial Estimate: %f \n", estimation);

//This is what the error in each of our measurements probably is.
//If this value is large it will have slower performance and the error takes longer to reduce
//However if the value is too low you might get completely wrong values or you won't end up with as accurate of values
//(because the formula thinks that you're measurements are more accurate than they are)
double measurementError = 50;

//This is how much error we think is in the current estimate (in this case our initial estimate)
//It can be used as a general measurement of how much error our estimation is so far
//This value can also be pretty much anything but if it's too low you might get bad values
double estimationError = 50;

double targetError = 10;
//how much error we'd like to have in our estimate after
//(note you might want to do iterations instead of a error)

while(estimationError<targetError){

//STEP ONE: Kalman Gain
//The kalman gain is a measurement of how close to the true value we probably are.
//In other words it takes into account how much error we have compared to the error in the measurement.
//We will use this later to make sure that new values don't change the current one as much.
KG = estimationError/(measurementError+estimationError);

//STEP TWO: Update Estimation
//This is how much our estimate needs to change taking into account the new data (getAccel())
//Note as our program goes on the value of KG goes down
//If KG is small (close to zero) this change value will be almost nothing because new data shouldn't change our estimation by much
//At the beginning KG is larger (close to 1) and so the new data has a lot more pull on what our next estimation should be.

//Basically if we are already pretty certain about our guess, we don't want noise or a measurement to change our guess
//to a completely different value.
change = KG*( getAccel()-estimation);

//We add this change to our estimation to update what we think the value should be.
//NOTE: Normally you don't split up the variables like this you'd just add them in one go to preserve speed and memory.
//I split it up here to help explain that it is a CHANGE to the estimation when new data is added.
estimation = estimation + change;

//STEP THREE: Update Reported Error
//Now that our estimation should be more accurate we need to update our reported error as such.
//If KG is close to 0 then we should be at a fairly low error or high accuracy so the error wont change as much from this new data
//If KG is close to 1 then the error should change by more because the new values are updating the value a lot more
estimationError = (1-KG)*estimationError;

}

}

```

# GCER 2017

• Matt Peck

Members:

• Chris Albert (programmer)
• Jennifer Albert (programmer)
• Davis Cochran (builder)
• Pranav Jayachand (programmer)
• Ryan Kelly (builder)
• Abdul Lele (builder)
• Kenneth McCann (programmer/builder) *Kipr Open*
• Adam Pruitt (programmer/builder) *Kipr Open*
• Zachary Sasser (programmer)
• Jon Scott  (builder)
• Josh Stenis (programmer)
• Tanner Stillman (builder)
• Gene Stejskal (builder)
• Nick Spens (builder)
• Meg Thung (documenter/builder)
• Ellie Thurston (builder) [GCER Paper]
• Reza Torbati (programmer)
• Nathan Wesson (builder)
• Lennit Williams (programmer)
• Richard Xiao (programmer/builder)
• Derek Yu (programmer)
• Andrew Zhang (programmer/builder)

Pictures:

# Regionals 2016

Norman Advanced went to Regionals here in Norman, Oklahoma. We competed mainly using two of our Double Elimination bots Milikan and The Denier. The Denier hopped the PVC and knocked off the opponents potato bin. Milikan drove up the ramp on our side and knocked off the poms. We made fourth place overall in Double Elimination.

# GCER 2016

Norman Advanced Robotics competed in GCER (Global Conference on Educational Robots) from July 6th through July 10th. GCER was held in St.Augustine Florida. Teams from all over the world attended this massive conference. Norman Advanced lost in our two first games of GCER but still made a good effort. Overall the team was still happy we went because it was a great learning experience for us all!