Robotics 501: Mathematics for Robotics

As a somewhat related example, our engineering college required a calculus based probability course that probably 95% of the engineers dreaded. Conditional probability, multivariable PDFs etc. A few years after college, I had the (dis)pleasure of needing to generate random values from an unknown PDF, given only the cumulative distribution. To a statistician, the obvious answer is to use the inverse CDF (a simple interpolated lookup table based on the known CDF) and a uniform random, but an engineer who didn't fully grok the probability basics would probably have just hacked around it, trying different approximations until something stuck.

Neither approach is right or wrong, but sometimes simply understanding the essential material and methods gives you unforeseen insights later on.

For instance, you'd like to know that when a state-space matrix is not full rank, you lose some control. In practical terms, a robot arm can usually move in any arbitrary Cartesian direction. A fully outstretched robot arm cannot.

For computing inverse kinematics... It's much simpler for a processor to have a slow update cycle that computes how every motor's changes will affect the position of the end effector (robot "tip") and then take a numerical inverse and use that to figure out a time-local, space-local approximation of getting to your eventual goal. It's a helluva lot easier than solving exactly.

I also recall some of the mathematics being relevant to collision detection (both in planning and execution stages), but the details are hazy. Basically, computation is expensive and convex hulls and precomputation can save a lot of cycles until it matters.

Yet other linear algebra lands in the realm of computer vision, optimization, and finite-element analysis.

- Most people have probably solved systems of equations by hand in school. G-J basically just systematises this process by abstracting away the unnecessary details and it has a clear sequence of steps (although you can still choose different pivots). I think it would not be satisfying to never see that.

- G-J can be done by hand on simple systems.

- It is a rather simple algorithm, but it still has some edge cases to consider (what if you have a 0 in pivot position?). I've seen a number of people try to implement G-J (we used it as a coding challenge and, yes, this was actually job-related in this case ;)) and fail on particular examples, e.g. stopping iteration too early after skipping a column.

- The algorithm runs in polynomial time (assuming floating point arithmetic; it's unfortunately not polynomial for arbitrary precision integers), so it's efficient. Knowing that a system of linear equations can efficiently be solved is, I think, rather important.

- you can discuss numerical stability in the context of different pivot strategies

- other algorithms use it as a building block or are basically a variation of it (LR factorisation, matrix inversion, simplex algorithm, etc.)

Of course, you could probably just tell people that instead of teaching them the algorithm, but I would think that it sticks better if you've actually seen it and it's not that hard of an algorithm (and I don't think you need to require people to memorise it either).

If you'd ask about teaching Jordan decomposition to engineers I would agree. :)

(But I've also never taught anyone, especially not engineers. So this is just what makes sense to me personally.)

One needs to know the math to be able to understand how to transform the physical world to math so as to solve the problems.

Example: Travelling salesman used to repair document gone through the document shredder. There isn't a book you can find this, either you understand the math principles or not. https://news.ycombinator.com/item?id=27713441

Do you need to know the proofs though? Most of the time no, but sometimes you need to know more.

Many proofs for example invert tables and in real code you better avoid it. Buy you need to know the Gauss Jordan to avoid the wtf when you crash into its common numerical instabilities.