5205 has been developing a Differential Swerve design for the past 2 years.
Mechanically, it’s a very mature design. The issue has been programming and finding the correct algorithms to control the differential swerve. After 2 years of development, I feel like we grasp the math and PID programming. The challenge stems from the differential swerve concept itself. Because both motors control drive and steering, there is no perfect way to independently gear the motors. Traditional swerve allow for separate gear ratios and that allows for good steering response and good speed. Our traction swerve does not. We thought we had mitigate that issue by spacing the two drive wheels further apart but width constraints did not allow us to fully take advantage of that strategy.
The result is that at low speeds, the robot performs relatively well. At high speeds, about 8ft/s, drive pods tend to dive inward or outward and the system becomes fairly unstable. I believe the low gear ratio for steering, about 10:1, coupled with the lag of the RIO, is the cause of this instability. What makes it worse potentially is the low encoder CPR on the NEO’s we are using. Trying to control in closed loop velocity control mode using the controls built into Spark Max results in either too much overshoot and oscillation or not enough stiffness. D gains seem to not be helpful because of the lag and low gear ratio. So there is no good way to damp out the oscillation. (Max velocity commands are on the order of 500 to 800 RPM)
We have placed it into smart motion mode. That results in much improved steerability. We had thought this was going to be our solution. But still when moving at higher speeds, the swerve pods still want to dive in and out.
Perhaps our algorithm is wrong. We are essentially commanding a position by reading current position and adding to that with two components. First component is for steering. That is based on absolute encoder reading, Target Angle - Current Angle multiplied by a gain, essentially P, in PID. The gain is just the gear ratio * the wheel spacing/wheel diameter and a little bit to account for wheel slip. The second component is the hypotenuse of the X and Y axis of the joystick * another gain. We find that the higher the gain, the faster the max speed is. You add those together to get the combined command position.
Here is a video showing just the steering command. It is spritely and responsive with little overshoot. And the stiffness of the system is fairly adequate.
(You’ll notice a jitter when it gets to target. I think that is another issue to solve. )
I don’t have any video of our test bot in motion. I can provide that if someone wants to see it. I think the diving is caused by the fact that controlling position via this combined signal doesn’t guarantee the pod will turn and go straight at the same time. Honestly, I’m not really sure why this doesn’t work.
My question is, is there a smarter way to do this? Is there another type of algorithm that would provide much better control.
This post seems to suggest that position control is possible:
We are in possession of 2 falcon 500’s and we will be installing it on one of the pods to see if that improves control-ability. We are also going to attempt to measure physical differences in each pod to create a offset table for each wheel to attempt to counteract slight variations in wheel OD. I don’t have a lot of faith in either avenues.
Looking for any thoughts, advice or help.
Lastly, we do have a backup plan in case this drive system does not succeed, just for all of you thinking right now that I’m crazy not to have a operational drive design at week 5.
Appreciate all who have read to the end of this thread. See you in competition.