Just some random stuff on using PID controllers on my quadrupedal robot.

Over the summer, while working with my quadrupedal robot, I finally reached the tricky problem of finding a suitable control system for the robot. Contrary to the belief of most amateur quadruped-builders, creating a walking gait is not as easy as making the motors repeat a motion on each leg… this could never work due to error in the system. Without the ability to respond accurately and effectively to unexpected issues, which are inherent to any imperfect system, it is more than likely that the error will be effectively amplified. This means that a (strictly) static gait can never work for a quadrupedal robot. Rather, a dynamic control system is required i.e. a PID controller (or, of course, something more complicated). To measure the error, the robot can use an IMU or feedback from compliant motors/a pneumatic system… I talk more about this is my fancy blog here. For now, that is irrelevant. Anyway, to respond to error, you can use a PID controller watching the error that provides feedback to the walking gait. This requires dynamic control of the walking gait, mainy the ability to control the rotation and translation axis of the robot, which means that a stable body positioning system is required. I explain the way that I figured out and implemented this system in another fancy blog post, which I haven’t released yet because I’m deciding whether I want to write a research paper about it… who knows, that might take too long, since I have another (secret) project that I’m working on. Anyway, during the summer, in parallel with developing the walking gait configurator (I made a completely configurable walking gait system), I set up a stable body positioning system. To pursue this further, I added a PID controller to allow the robot to position itself. I have an instagram post of this. This includes two PID controllers: one for rotation around the x-axis, and one around the y-axis (roll and pitch). I tuned this simply by disabling on controller while testing the other on it’s respective motion, and vice versa. This is incredibly easy, since it is very easy to isolate the error in the PID in order to tune it… there is nothing else to analyze. When it comes to walking, however, this is not so simple. Since walking error involves both x and y axis rotations, it is incredibly difficult to observe which controller is working correctly and which isn’t. This is even more difficult when the error is large, since then the robot-plane axis are no longer parallel to the ground axis i.e. rolls and pitches will result in x and y rotations relative to the ground. This means that the PID controllers will be affecting each other. All in all, this creates a system that is very difficult to troubleshoot. So how did I try to solve this problem? I hadn’t solved it yet, and then school started, which is bad (I’m actually writing this post in winter break). My first hunch was that it was necessary to quantify the problem for both pid controllers. Humans are horrible at deciding when something is objectively good or bad, better or worse, when they look at things like this. Numbers, however, are easy. They are black and white. If one number is bigger than another, then it is very easy to tell, because they’re numbers! My first idea to quantify this problem was to allow the robot to walk, with the controllers running, for a set period of steps (cycles). Then, I’d calculate the average of the rates of changes (derivatives) of the error. Basically, I’d find the difference between the previous cycle’s error and the current cycle’s error, divide by the time between both cycles. This is a derivative of the error. Then I’d average this derivative across the time that the quadruped was “walking” for both controllers. It is important to use the derivative of the error and not the error itself since the PID controllers should not only reduce error, but they should stabilize the error that exists. To put it another way, if the robot flopped back and forth, it would not be exibiting a stable system… but the average of the error might be low (note that the derivative would be high). Thus, analyzing the derivative allows me to prevent this activity by figuring out when the system has more stable error, which might allow the robot to walk. Granted, this means that large steady-state errors will not be picked up. For this, I also integrated the error. Unfortunately, by the time that school started, I realized that I actually had a bug in this portion of the program, which messed up the output values… which meant that the tuning didn’t work and this did actually get me anywhere. At the same time, I was having difficulties with my control board, which wasn’t working great (the same day I discovered the bug, the relay on board”blew out”). Once I have the new board up and running, I should be able to run a faster PID which will also help. For now, I’m just recording this stuff before I forget.