{"id":526,"date":"2024-05-22T15:57:58","date_gmt":"2024-05-22T15:57:58","guid":{"rendered":"https:\/\/peterklemperer.com\/blog\/?p=526"},"modified":"2024-05-22T15:59:22","modified_gmt":"2024-05-22T15:59:22","slug":"out-of-control-pids","status":"publish","type":"post","link":"https:\/\/peterklemperer.com\/blog\/2024\/05\/22\/out-of-control-pids\/","title":{"rendered":"Out of Control PIDs"},"content":{"rendered":"\n

This week’s post is less of a how-to and more of a “how-to?” I’ve got some ideas about the basics of PID controls, but this system is giving me trouble. I updated the PID control system on Egg-Bot Version 2. V2 currently holds a single position okay, but changes in the target are wild and guaranteed failure.<\/p>\n\n\n\n

Control Loop Upgrade<\/h2>\n\n\n\n

First thing I did this week was add a non-linear adjustment to the PID loop to more accurately map the pendulum angle to the geometry of the robot. In this way a change in the output angle would reflect the center of gravity of the robot, rather than the center of rotation of the pendulum.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

I think the reason for the failures is that the controller relies on the integral term to reach the target position. In a previous iteration of the controller, whenever I changed the target, I could observe a pretty wild perturbation where the integral term “unspooled” and had a big time delay until it could start moving towards the new target.<\/p>\n\n\n\n

To combat this “spooling”\/”unspooling” delay, in today’s PID version, I reset the integral term whenever a change in target was entered. This had a new effect where the robot would suddenly fall over on target changes due to the rapid change in that term. I want to investigate what’s done more commonly to address this challenge.<\/p>\n\n\n\n

\n