From 8618c2c6856a4ba78054bcde9d9805ef2bfab05e Mon Sep 17 00:00:00 2001 From: Sylwester Arabas Date: Fri, 5 Jan 2018 13:13:54 +0200 Subject: [PATCH 1/4] typo --- 02-Discrete-Bayes.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/02-Discrete-Bayes.ipynb b/02-Discrete-Bayes.ipynb index cdc187d..807d5b7 100644 --- a/02-Discrete-Bayes.ipynb +++ b/02-Discrete-Bayes.ipynb @@ -1616,7 +1616,7 @@ "\n", "The *system* is what we are trying to model or filter. Here the system is our dog. The *state* is its current configuration or value. In this chapter the state is our dog's position. We rarely know the actual state, so we say our filters produce the *estimated state* of the system. In practice this often gets called the state, so be careful to understand the context.\n", " \n", - "One cycle of prediction and updating with a measurement is called the state or system *evolution*, which is short for *time evolution* [7]. Another term is *system propogation*. It refers to how the state of the system changes over time. For filters, time is usually a discrete step, such as 1 second. For our dog tracker the system state is the position of the dog, and the state evolution is the position after a discrete amount of time has passed.\n", + "One cycle of prediction and updating with a measurement is called the state or system *evolution*, which is short for *time evolution* [7]. Another term is *system propagation*. It refers to how the state of the system changes over time. For filters, time is usually a discrete step, such as 1 second. For our dog tracker the system state is the position of the dog, and the state evolution is the position after a discrete amount of time has passed.\n", "\n", "We model the system behavior with the *process model*. Here, our process model is that the dog moves one or more positions at each time step. This is not a particularly accurate model of how dogs behave. The error in the model is called the *system error* or *process error*. \n", "\n", From c04c693202e7c8602f35004482fca08fd7642147 Mon Sep 17 00:00:00 2001 From: Sylwester Arabas Date: Fri, 5 Jan 2018 17:54:34 +0200 Subject: [PATCH 2/4] Update 04-One-Dimensional-Kalman-Filters.ipynb --- 04-One-Dimensional-Kalman-Filters.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/04-One-Dimensional-Kalman-Filters.ipynb b/04-One-Dimensional-Kalman-Filters.ipynb index e999d51..6e1e83a 100644 --- a/04-One-Dimensional-Kalman-Filters.ipynb +++ b/04-One-Dimensional-Kalman-Filters.ipynb @@ -2164,7 +2164,7 @@ "source": [ "## Comparison with g-h and discrete Bayes Filters\n", "\n", - "Now is a good time to be understand the differences between these three filters in terms of how we model errors. For the g-h filter we modeled our measurements as shown in this graph:" + "Now is a good time to understand the differences between these three filters in terms of how we model errors. For the g-h filter we modeled our measurements as shown in this graph:" ] }, { From 626e73c6e2d4886d8a8d0fe5d035211c9b384fa4 Mon Sep 17 00:00:00 2001 From: Sylwester Arabas Date: Fri, 5 Jan 2018 18:03:53 +0200 Subject: [PATCH 3/4] Update 04-One-Dimensional-Kalman-Filters.ipynb --- 04-One-Dimensional-Kalman-Filters.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/04-One-Dimensional-Kalman-Filters.ipynb b/04-One-Dimensional-Kalman-Filters.ipynb index 6e1e83a..005ec92 100644 --- a/04-One-Dimensional-Kalman-Filters.ipynb +++ b/04-One-Dimensional-Kalman-Filters.ipynb @@ -2319,7 +2319,7 @@ "source": [ "Now we need to write the Kalman filter processing loop. As with our previous problem, we need to perform a cycle of predicting and updating. The sensing step probably seems clear - call `volt()` to get the measurement, pass the result into `update()` method, but what about the predict step? We do not have a sensor to detect 'movement' in the voltage, and for any small duration we expect the voltage to remain constant. How shall we handle this?\n", "\n", - "As always, we will trust in the math. We have no known movement, so we will set that to zero. However, that means that we are predicting that the temperature will never change. If that is true, then over time we should become extremely confident in our results. Once the filter has enough measurements it will become very confident that it can predict the subsequent temperatures, and this will lead it to ignoring measurements that result due to an actual temperature change. This is called a *smug* filter, and is something you want to avoid. So we will add a bit of error to our prediction step to tell the filter not to discount changes in voltage over time. In the code below I set `process_var = .05**2`. This is the expected variance in the change of voltage over each time step. I chose this value merely to be able to show how the variance changes through the update and predict steps. For an real sensor you would set this value for the actual amount of change you expect. For example, this would be an extremely small number if it is a thermometer for ambient air temperature in a house, and a high number if this is a thermocouple in a chemical reaction chamber. We will say more about selecting the actual value in the later chapters.\n", + "As always, we will trust in the math. We have no known movement, so we will set that to zero. However, that means that we are predicting that the temperature will never change. If that is true, then over time we should become extremely confident in our results. Once the filter has enough measurements it will become very confident that it can predict the subsequent temperatures, and this will lead it to ignoring measurements that result due to an actual temperature change. This is called a *smug* filter, and is something you want to avoid. So we will add a bit of error to our prediction step to tell the filter not to discount changes in voltage over time. In the code below I set `process_var = .05**2`. This is the expected variance in the change of voltage over each time step. I chose this value merely to be able to show how the variance changes through the update and predict steps. For a real sensor you would set this value for the actual amount of change you expect. For example, this would be an extremely small number if it is a thermometer for ambient air temperature in a house, and a high number if this is a thermocouple in a chemical reaction chamber. We will say more about selecting the actual value in the later chapters.\n", "\n", "Let's see what happens. " ] From 8b755e36a203f7a5c85b5b503850717d52088497 Mon Sep 17 00:00:00 2001 From: Sylwester Arabas Date: Fri, 5 Jan 2018 18:10:40 +0200 Subject: [PATCH 4/4] Update 04-One-Dimensional-Kalman-Filters.ipynb --- 04-One-Dimensional-Kalman-Filters.ipynb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/04-One-Dimensional-Kalman-Filters.ipynb b/04-One-Dimensional-Kalman-Filters.ipynb index 005ec92..eec1ac3 100644 --- a/04-One-Dimensional-Kalman-Filters.ipynb +++ b/04-One-Dimensional-Kalman-Filters.ipynb @@ -2402,7 +2402,7 @@ "\n", "Spec sheets are what they sound like - specifications. Any individual sensor will exhibit different performance based on normal manufacturing variations. Values are often maximums - the spec is a guarantee that the performance will be at least that good. If you buy an expensive piece of equipment it often comes with a sheet of paper displaying the test results of your specific item; this is usually very trustworthy. On the other hand, if this is a cheap sensor it is likely it received little to no testing prior to being sold. Manufacturers typically test a small subset of their output to verify that a sample falls within the desired performance range. If you have a critical application you will need to read the specification sheet carefully to figure out exactly what they mean by their ranges. Do they guarantee their number is a maximum, or is it, say, the $3\\sigma$ error rate? Is every item tested? Is the variance normal, or some other distribution? Finally, manufacturing is not perfect. Your part might be defective and not match the performance on the sheet.\n", "\n", - "For example, I am looking at a data sheet for an airflow sensor. There is a field *Repeatability*, with the value $\\pm 0.50\\%$. Is this a Gaussian? Is there a bias? For example, perhaps the repeatability is nearly 0.0% at low temperatures, and always nearly +0.50 at high temperatures. Data sheets for electrical components often contain a section of \"Typical Performance Characteristics\". These are used to capture information that cannot be easily conveyed in a table. For example, I am looking at a chart showing output voltage vs current for a LM555 timer. There are three curves showing the performance at different temperatures. The response is ideally linear, but all three lines are curved. This clarifies that errors in voltage outputs are probably not Gaussian - in this chip's case higher temperatures leads to lower voltage output, and the voltage output is quite nonlinear if the input current is very high. \n", + "For example, I am looking at a data sheet for an airflow sensor. There is a field *Repeatability*, with the value $\\pm 0.50\\%$. Is this a Gaussian? Is there a bias? For example, perhaps the repeatability is nearly $0.0\\%$ at low temperatures, and always nearly $+0.50\\%$ at high temperatures. Data sheets for electrical components often contain a section of \"Typical Performance Characteristics\". These are used to capture information that cannot be easily conveyed in a table. For example, I am looking at a chart showing output voltage vs current for a LM555 timer. There are three curves showing the performance at different temperatures. The response is ideally linear, but all three lines are curved. This clarifies that errors in voltage outputs are probably not Gaussian - in this chip's case higher temperatures lead to lower voltage output, and the voltage output is quite nonlinear if the input current is very high. \n", "\n", "As you might guess, modeling the performance of your sensors is one of the harder parts of creating a Kalman filter that performs well. " ]