The Kalman Filter is something while completely alluded me and my peers during undergrad, and even took me some time in graduate school to really understand. I’ve since implemented variations of this estimator countless times for a variety of different problems. Despite having been formulated about half a century ago (!!), I feel it’s a tool that every engineer and scientist should keep in their back pocket.

I plan to spend a few blog posts introducing the concepts of data fitting, least squares estimation and finally the Kalman Filter because they’re so fundametially important in robotics and controls overall. This might take some time to build up to, but I feel it’s good to have some background in simpler estimation problems beforehand.

Suppose you have a mobile robot like the one shown below. You wish to move the robot from the start point (in green) to the goal point (in red) along the line between the two points, starting at time and ending at time .

To accomplish this, you need to parameterize its path with respect to time in order to sample the line at each control cycle and send the target position to a lower-level controller. We thus need to find constants which define the line

such that

In the first constraint above, substituting the initial condition at immediately revealed ; substituting this into the final condition yields

So the path parameterized in time is simply

Assuming we have some controller which takes 2d position as an input and computes motor commands, we can now control the robot position at any control frequency. Let’s take a second, though, and reexamine this problem posed in matrix form:

If you multiply this out following matrix multiplcation rules, you’ll end up with exactly the boundary conditions we stated above. To solve it, let’s take the inverse of the 2x2 matrix. Recall that

Applying this to our path-finding problem, we have

which, as expected, simplifies to the same answer as before:

Now, what if we desire - for example, in order collect images of something in particular - the robot to pass through some waypoint at time as it moves to the goal position?

We clearly can’t parameterize its path with a line anymore. We increased the number of constraints (desired positions at desired times) by one, so intuitively we need to increase the number of *degrees of freedom (DoFs)* (variables which define our trajectory) by one as well. Sticking with polynomials, this implies a quadratic function

such that

Again, we know from the initial condition that , and we can use the midpoint and end conditions to solve simultaneously for the other constants . Let’s rephrase the problem in matrix form:

We can again see that , but solving for is now more complicated to do by simultaneous equations. We know from before, though, that we can just invert the “timing” matrix to get the answer. You can look up the closed-form expression for the inversion of a 3x3 matrix, but who cares what it looks like? The point is that **we need a polynomial of order to interpolate (exactly pass through) points, and it can be written in the form .**

For points including waypoints the problem in general becomes:

Based on what we worked through above, we can solve for the interpolating polynomial **as long as the matrix is invertible**. When does this break down?

We can see in the single waypoint case that choosing or , among other singularities, clearly makes non-invertible; see below for :

Why is that? Choosing the waypoint timing in such a manner means that a diagonal element of becomes zero, and since the product of the diagonal elements of a square matrix is equal to the product of its eigenvalues, one of the eigenvalues of must be zero. This is proves (in one of many ways) that has no inverse!

Obviously, it makes no physical sense for the waypoint times to be equal, so we don’t have to worry so much about this edge case. Unfortunately, we have a couple more fundamental issues: first of all, the matrix in our problem is a Vandermonde Matrix which is a form of matrix known to have poor *conditioning*. It’s beyond the scope of this pose to get into what the *condition* of a matrix means, but suffice to say that taking the inverse of a matrix with poor conditioning (a high *condition number*) can lead to huge numerical errors.

Second, as the number of points grows, we need higher and higher order polynomials. If we choose our waypoints roughly equidistant in time - a common choice when working with sampled data - then we run into another stability issues known as Runge’s phenomenon.

How do we deal with the fact that our problem as posed has poor numerical stability? The truth is that interpolation using high-order polynomials of the above form isn’t a great idea. It can help to use different *basis functions* like the Lagrange or Netwon polynomials, but the truth is that interpolation as we’ve posed it isn’t really the best way to fit a function to these points - let’s take a look at a better method.

We can avoid the issues inherent in fitting a single, high-order polynomial to points by instead **fitting a set of N-1 low-order polynomials** to the data.

For example, if we instead use *piecewise linear interpolation* between the same points at respective times we get the path shown below:

Solving for the equations of each line is exactly the same as the very first problem - just repeated a number of times from start to goal, enforcing that **the value at the beginning of a line segment is equal to the value at the end of the previous line segment**. These are called *continuity conditions* because they ensure that the segments are continuous (have no jumps in value) where they meet. Let’s take a look at these conditions for the multiple waypoint interpolation problem below.

For many simply planning a position path, this works well enough. The problem is that many robots are controlled by specifying desired *velocity* and/or *acceleration* rather than position! Let’s take a look at one position dimension (say, ) and its derivatives (velocity and acceleration):

The position is continuous, but the *velocity* is not - there are discrete jumps at each waypoint. Even worse, there is no acceleration reference to follow - it’s zero the whole time, and at the waypoints it’s undefined due to the *jump discontinuities* in velocity!

Sending a discontinuous command to a controller - in particular, the derivative (D) portion of a PID controller - can easily cause instability if gains are too high, forcing you to reduce the *bandwidth* of your controller to be robust to such jumps. Now we see that **the interpolation strategy you choose has a direct impact on how well you can track the desired motion!**

For controlling a physical system, we usually desire an interpolation scheme which at least guarantees continuity up to acceleration. Why? I’m glad you asked.

Because ! Let’s assume that the low-level control command we send to a robot is a force - think the lift force per rotor in a multirotor drone - then tells us that if we know the desired acceleration of the center of mass of the robot and the robot’s mass , then we know how much total force we need to send. This is a *second-order* system, meaning that its dynamics are written on the level of accelerations (some form of ) - which is the case for many physical systems. Of course, it all depends how we want to model the system, which depends on what the low-level control command we send is; for example, in a multirotor system we might send force commands at some level, but beneath this is a controller which maps force to motor current. If we model our system with current as the input, we’ll get a higher-order system than second-order, but typically we would choose to stack a force controller on top of a motor current controller rather than build the dynamics of the rotors themselves into our system model. This is a discussion about control system design, which we’re not going to go into any further for now.

The mathematical term for second-order continuity of derivatives is *smoothness*, meaning that two derivatives of are continuous. The minimum order piecewise polynomial that we should consider is then *cubic*. Enter the cubic spline.

You’ve probably heard of splines before (anyone else remember SimCity 2000’s mockumathematical *reticulating splines* loading step?) but maybe you don’t understand what they are. You may have even used them for something (they’re very popular in graphics as well) but all the math was hidden within the library you used. It turns out that (a) they’re fairly simple (b) they avoid all the issues with interpolation we’ve encountered thus far and (c) they can be solved for very efficiently using linear algebra.

As discussed above, instead of a single interpolating polynomial of order , we can find a set of *piecewise* interpolating polynomials of lower order. The order of polynomial to be used depends on the desired properties of the interpolant; typically, this means continuity of derivatives of up to a certain order. For example, the piecewise linear trajectory we introduced above is smooth; a piecewise quadratic is smooth; a piecewise cubic is smooth and so on. Since physical systems are usually second-order, piecewise cubic polynomials are often a good choice - though for higher orders of smoothness piecewise quintic (fifth-order) polynomials are sometimes used.

A *spline* is nothing more than a collection of piecewise polynomials of a certain order (cubic, quintic, etc) with derivative continuity enforced at interior waypoints and boundary conditions enforced at the ends. We won’t go through the full derivation here, but instead set up the problem and discuss the solution.

A piecewise cubic function interpolating waypoints at times can be written as a set of cubic polynomials

This piecewise interpolating polynomial is subject to continuity constraints of zeroth, first and second orders at all interior waypoints (called *knots*), resulting in a total of constraints, as well as interpolation constraints which ensure the function passes through the waypoints at the specified time (resulting in more constraints). This yields a total of constraints with a total of coefficients - two more constraints are needed!

There are a number of different ways to specify the remaining two constraints required to solve the interpolation problem, but among the most popular are:

- Natural boundary conditions - end knots have zero second derivative
- Specified boundary conditions - the second derivative at each end knot is a specified value
- Not-a-knot - the first and last interior knots have further continuity of third derivatives, which for a cubic polynomial means that and and hence these knots are effectively
*not knots*, since the functions surrounding them must be identical - Clamped boundary conditions - the first derivative at the end knots is zero
- Complete boundary conditions - the first derivative at each end knot is a specified value

Given the interpolation and continuity constraints plus additional boundary conditions, the cubic spline interpolation problem is written in matrix form as a *tridiagonal* matrix which can be efficiently solved using a [TDMA (Tridiagonal Matrix Algorithm)}(https://en.wikipedia.org/wiki/Tridiagonal_matrix_algorithm) solver. Thus, not only are splines very flexible, but they’re very fast to compute!

For in-depth details on putting the above problem into the form of a tridagonal matrix system (lots of algebra!)see this paper for an excellent summary. Also, keep in mind that this is just one way (probably the most straightforward to understand) to set up the spline problem; in practice, many libraries use B-splines which are *basis functions* for splines of a particular degree (meaning that any spline of that degree can be respresented as a linear combination of B-splines). This reduces the problem to solving for the coefficients in the B-spline basis, but the result is the same.

The way in which we specify splines as waypoints at specific times (which implicitly imposes derivative information) means that the resulting trajectory is a function of time. This may not be the desired goal - for example, consider the problem of moving through waypoints at a desired (and even variable) *speed* rather than at specified times. This is somewhat like an amusement park ride in which the vehicle follows rails but allows the rider to control the speed. Not super common in practical applications, but it’s something I’ve encountered and the solution is interesting.

The speed and acceleration along a spline determined by waypoints at specific times are certainly non-constant; these derivatives vary along the trajectory to ensure smoothness in interpolation. How do we instead generate a smooth trajectory to be followed at a specified speed without explicit timing information?

The proper way to accomplish this is to re-parameterize the spline in terms of *arclength* (distance traveled along the spline) rather than in terms of time. The spline can then be followed at a constant, desired *arclength rate of change* aka speed along a trajectory. Unfortunately, this re-parameterization cannot be done in closed-form; there are a number of ways to accomplish this (see this paper for a great explanation) but the general algorithm is as follows:

- Build a spline without specified waypoint times, for example spacing waypoints apart by one second nominally
- Sample the spline at many times in the nominal range
- Compute cumulative arclength along the curve by computing distances between the sampled points (assuming they are line segments)
- Fit a piecewise linear (or higher order) function relating arclength to sample time points
- For an input time and desired speed along the curve , compute the desired arclength as and use the linear fit to find the corresponding time
- Return the spline sampled at which, for a series of times, should yield an arclength rate of change of

This method is seen to work quite well, and will work even better if the spline is sampled at a finer resolution and higher-order piecewise fit is used in the fourth step. Alternatively, a simple method is to build a spline normally but first determine the waypoint times from the specified in such a way that the *average* velocity along the curve per segment is . This can be combined with the more exact approach above by using this idea to build a spline in the first step (rather than using nominal waypoint timings). This improvement should help ensure that sampling the spline at regular intervals in step two will yield a good approximation for the fit in step four.

Feel free to share!