With 5687 recently getting the Innovation and Controls award at worlds this year and multiple teams asking how we control / overcame some of the issues teams were having I would like to create a post on the current situation of our teams differential swerve modules.
The Diff Swerve
Our modules use a LQR controller to control the states of our swerve module
x = [\theta_a, \omega_a, \omega_w]
Where \theta_a and \omega_a represent the azimuth angle and azimuth angular velocity, respectively, and \omega_w represents the wheel angular velocity. At the beginning of the season, we used a voltage-based model that had worked well in previous years but proved ineffective at higher speeds (>3.0 mps). After extensive debugging, we discovered that the LQR control outputs were extremely small, which meant that the feedforward controller was doing most of the work. While we could have compromised to get the system working as intended, we decided to switch to a torque/current-based model. Our rationale was that this new model would allow us to implement more complex logic to assist with module control and limit the current being passed to the motors directly.
This put us in a situation where we needed to purchase CTRE’s Pro API to easily control the current and synchronize sensor frames (which I will explain later).
Using the Pro API worked out great for us. It allowed us to lower our modeled inertia of the modules closer to what we believe it should be, as opposed to the voltage-based module that struggled with discretizing the model at lower inertia. This discovery of lower inertia drastically improved the current draw of our machine, which is a max-weight robot capable of accelerating fairly quickly (the modules can become traction-limited while accelerating, which you can hear as the wheels spin).
Current draw of robot:
This was the current draw of our machine before we discovered the inertia change
This is after
We saw a huge improvement of almost 100 amp difference in current draw leading to brownouts a thing of the past, we were able to run a 12.2V battery for a practice match with no issue.
Control Issues
Since all the modules are controlled by the RoboRIO 2.0 at 200Hz, we encountered consistent loop timing issues. This was mainly due to the computational expense of CAN bus calls. Without CTRE’s frame synchronization for sensor acquisition, we would not have had as consistent loop time deltas as we did. Prior to implementing the fix described above, we were burdened by constant loop overruns, which led to some undesirable effects. Although we still don’t have consistent 5ms loop timing, we experience ringing around the 5ms delta-time and rare peaks of up to 10-20ms.
Our module’s azimuth control is not perfectly smooth without the damping effect of the robot. If you were to drive the robot in a straight line while it’s dry docked, you would see angle jitter from the modules. At this time, we are not sure what causes this. Our current assumption is that it has to do with the inconsistent delta-times and potential sensor delay. However, this does not affect the performance of the robot while driving. We are still looking for ways to improve this issue.
This project has been a fun and interesting engineering problem since we started it back in 2020 while I was a Junior. The team is looking to keep improving the modules control to make to just as good or better than your traditional swerve.
Here is our current version of our modules
And our CAD release from last year which should contain our latest module.
I definitely didn’t cover all aspects of our modules here but would be happy to answer any questions.