Overview: complex motor controllers
Currently the vast majority of our controllers are just PID with fancy filtering or limiting applied on top of them. While these work fine and are very robust and easy to tune, they come with a number of limitations.
-
The chassis power is strictly monitored by the referee system. If we go over some power limit and eat into all of a power buffer (this year the base power limit is starting at 40 W and the power buffer is ~80 J), the referee system takes damage. For the chassis controller, RPM PID is applied and then limiting is applied proportional to the current draw, total power consumed, and power buffer. While this works OK and is better than the 2019 season, the soldiers from the 2019 season were horribly slow because our power draw was not optimized. Speed and acceleration plays a huge role in the competition, so it is our best interest to look to improve this aspect of our robots.
-
The turret code is also currently running a position PID controller. While there are no power constraints to worry about, optimal turret control (IMHO) is comprised of the following:
- Quick time from an aim request angle to the turret pointed in the correct direction.
- When tracking a moving target, minimal position error.
A trademark of a very well tuned turret controller is one that can activate the damage rune. This very short first person video shows an example of a well tuned turret controller that snaps to a requested position and then tracks the target very well. While this is a bit unique since the rune game is a unique targeting challenge, it still gives a pretty good idea of what I am talking about above. Very well tuned PID can provide a very good solution for both of these categories. That being said, a PID controller alone can only do so much. Last year, we briefly looked into a solution that combined simple trajectory path planning on top of a base PID controller but we never made a ton of progress (on robot at least) AFAIK. There might be some simulation stuff lying around that might be useful. This is one solution, though there are other controllers that we could look into as well.
-
Also related to the turret, "wiggle drive" is a mode where the chassis rotates back and forth while the user is still able to normally aim the turret and control the robot. While we greatly improved the turret's error while wiggling, there should really be no error at all while in this mode, otherwise wiggle drive is generally unusable. We are currently utilizing a simple feed forward controller proportional to the rotation of the chassis that attempts to "cancel out" the rotation of the chassis. This is not well tuned since the amount of slop in the chassis makes this feed forward approach almost useless. While this is less pressing of an issue since there's a decent chance the simple feed forward control we do now works, thinking of more innovative ways to take into account the rotation of the chassis in the turret controller is definitely something that could be looked at.
I am proposing that we invest a large amount of time this year into attempting to improve the above shortcomings as much as possible. Looking into controllers that allow one to optimize current draw and improving turret control are the two big tasks.