I’ve been working on making the wpi swerve work for falcons and their integrated sensors, and I ran into a weird problem. The azimuths turn to the positions that they are supposed to, but they do it at different times, instead of being synchronized like they should. What am I doing wrong? Drivetrain and swerve module are the only subsystems that we are using.
https://drive.google.com/drive/folders/1dGFL-MVK54yPLYVEmYeGnNyi3iyrfZQm?usp=sharing
Given only a description of the symptom (I can’t see what at’s at the google drive link), there are a lot of possible root causes.
Do you have plots of the commanded (target) azimuth angle, versus the actual (measured) azimuth angle?
That could help reveal whether the issue upstream or downstream from from how angle targets are assigned.
I’d suggest uploading the same files to a Github repository, it can allow people to view your code in browser as opposed to having to download your project to take a look.
You may get some more help this way.
I’ve been having some problems with uploading stuff to github, but I’ll try it out; thanks.
https://drive.google.com/file/d/1aHkynGZ_qJGp8p_tQX58yCV5c5ThhryN/view?usp=sharing
Video of the robot. I also have some regular PID issues, but I’ll have to work on those later. The wheels also turned to that position when the robot turned on, and I don’t know why.
I can’t say I’m all that clear on the exact nature of the problem. The wheels seem to be a bit sluggish to hit the defined setpoint (even appear to be getting “stuck” sometimes), but I guess I’m not seeing them start moving at different times.
Can you produce data plots which illustrate the unexpected behavior, or additional description of which behavior you were not expecting (and why)?
I think this link illustrates the problem better. https://drive.google.com/file/d/1n7hL868VhW1tn7-tZ8Mgt0QemqAp5pDp/view?usp=sharing
When the wheels turn back to their original position, the top wheels take significantly longer than the bottom wheels to go back, even though they have the same PID values, and should be going back to the same positions.
That appear to be a TTB swerve module with some mods. What ratio are you running on the Azimuth? You may have a code problem, but it could also just be your Azimuth is too slow, or not tuned well enough to get to the position quick enough.
We are using 20:1 for the azimuth. I haven’t started to do PID tuning yet because of this issue, could they be related?
So a few things to poke at:
- Is the command for position actually going to all modules at the same time? Can you produce logs or plots to demonstrate this?
- Have you eliminated enough mechanical variation between the modules to be confident that the PID constants should be the same?
- Is the same command going to each motor during that “return to top” maneuver? Why or why not?
I don’t know how to do number 1, but for number 2, I’m fairly certain that mechanical variation isn’t large enough to account for this problem.
Take a look at Glass and NetworkTables. They are invaluable tools while driving control-system symptoms to root cause.
Thanks, I’ll be sure to check it out.
Yep. From my view, it kinda seems like your response is very sluggish. On our TTB swerve there are some sticky points. If you gains aren’t very high, the response may just be sluggish. You probably don’t need to go crazy with the tuning just yet, but try turning up the gains (specifically Kp) and try again. You may find that it starts to fix the problem.
@gerthworm 's suggestion of trying to do better debugging is also very good.
Some other mechanical things: What motor are you using on your azimuth? Also,is the 20:1 before the ring gear, or after?
We use Bag motors, and I think the 20:1 comes before the ring gear.
I also increased the Kp, but all it did was make it oscillate more, it did not fix the sluggishness.
Okay. That will be a little slow (I calculate 123rpm free speed), but it will be 100% fine to get started. We ran a setup similar, and it functioned okay to get started. I don’t think that is your current problem.
And bummer making the PID more aggressive didn’t help. That rules out one of the easy solutions 
I think I still want to see plots of what’s going on. The nomenclature “Sluggish” or “oscillation” is mutually exclusive to me:
Green is desired, orange is actual.
I’m not certain how a step response could be both “sluggish” and “oscillatory” simultaneously.
I’ve never used Glass before, so it might take me a while before I can get graphs running. What I meant by both sluggish and oscillatory is that some of the wheels start turning after the other wheels, but start oscillating once they reach the desired end state.
2 Likes