Fixed ## headings for IPython 4.0 changes.

08-Designing-Kalman-Filters.ipynb

@@ -1985,7 +1985,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "##Evaluating Filter Performance\n",
+    "## Evaluating Filter Performance\n",
     "\n",
     "It is easy to design a Kalman filter for a simulated situation. You know how much noise you are injecting in your process model, so you specify $\\mathbf{Q}$ to have the same value. You also know how much noise is in the measurement simulation, so the measurement noise matrix $\\mathbf{R}$ is equally trivial to define. \n",
     "\n",
@@ -2195,7 +2195,8 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "###NIS"
+    "### NIS\n",
+    "todo"
    ]
   },
   {
@@ -2923,6 +2924,13 @@
     "The code is fairly straightforward. The `update()` method optionally takes R as an argument, and I chose to do that rather than alter `KalmanFilter.R`, mostly to show that it is possible. Either way is fine. I modified `KalmanFilter.H` on each update depending on whether there are 1 or 2 measurements available. The only other difficulty was storing the wheel and PS measurements in two different arrays because there are a different number of measurements for each. "
    ]
   },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Control Inputs\n"
+   ]
+  },
   {
    "cell_type": "markdown",
    "metadata": {},
@@ -3409,8 +3417,6 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "**author's note - I originally had ball tracking code in 2 different places in the book. One has been copied here, so now we have 2 sections on ball tracking. I need to edit this into one section, obviously. Sorry for the duplication.**\n",
-    "\n",
     "We are now ready to design a practical Kalman filter application. For this problem we assume that we are tracking a ball traveling through the Earth's atmosphere. The path of the ball is influenced by wind, drag, and the rotation of the ball. We will assume that our sensor is a camera; code that we will not implement will perform some type of image processing to detect the position of the ball. This is typically called *blob detection* in computer vision. However, image processing code is not perfect; in any given frame it is possible to either detect no blob or to detect spurious blobs that do not correspond to the ball. Finally, we will not assume that we know the starting position, angle, or rotation of the ball; the tracking code will have to initiate tracking based on the measurements that are provided. The main simplification that we are making here is a 2D world; we assume that the ball is always traveling orthogonal to the plane of the camera's sensor. We have to make that simplification at this point because we have not yet discussed how we might extract 3D information from a camera, which necessarily provides only 2D data. "
    ]
   },
@@ -3829,7 +3835,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "##References\n",
+    "## References\n",
     "\n",
     "[1] Bar-Shalom, Yaakov, et al. *Estimation with Applications to Tracking and Navigation.* John Wiley & Sons, 2001."
    ]

12-Particle-Filters.ipynb

@@ -1094,7 +1094,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "##Importance Sampling\n",
+    "## Importance Sampling\n",
     "\n",
     "In the filter above I hand waved a difficulty away. There is some probability distribution that describes the position and movement of our robot. This might be impossible to integrate analytically, so we want to draw a sample of particles from that distribution and compute the integral using MC methods. \n",
     "\n",