An interface is designed to give you a way to interact with some other code. It creates a way to simplify, or make more consistent, different underlying systems to make them behave the same way, like all of the types of motor controller mentioned. Refer to the following block diagram:

It also provides a way to cleanly separate parts of code into layers. Different layers means that you are able to change one part of some code, without it making huge changes in another. In the previous diagram, panel 1 shows a block of code that has different systems mixed together. It will be hard to change; adding a new behavior or swapping the motor controller in this code would be quite tricky.

The code represented by panel 2 shows two separate systems interacting. They have a relationship where the Path Following Behavior is in control of the Robot hardware setup and control code. 

If we write a new behavior, we can use the hardware control library again. We will be writing many behaviors, and we will be able to reuse the robot object throughout, perhaps extending it occasionally.  After all, who wants to keep writing the same code? 

This common interface means we could make an object that looks the same from the outside on other robots, and our behaviors will still work. So, if the motor board changes, we won't need to modify the behavior code.

The Robot hardware setup/control block in the second panel of the previous photo and Mecanum wheels on the Uranus Pod by Gwpcmu will be our Robot object. It is a real version of our interface. It will hide the quirks of our "full function Stepper Hat" board.