Hi guys, I’m lead programmer of FRC9501
We try to use Swerve drive at 2024 and 2025
Our robot code use Java
and when we test the swerve we encounter some difficulties.
When the swerve drive moves while rotating, it forms an arc-shaped trajectory.
And when Swerve in move it will rotate
EX:intake face to 0• when swerve go straight 5m intake will face to 30• - 40•
I don’t know what happened on robot or code
So I need some suggestions. THX
PS: English is not my native language, so there may be some grammatical and word choice errors. I apologize for any inconvenience.
This is likely not a code issue, or maybe more precisely this could easily be something other than code.
The likely cause is the command vector from a wheel (angle and velocity) is not being replicated in reality.
A couple mechanical things that should be checked.
Are the wheels aligned (when up on blocks and you command a direction with no rotation do they all point in the same direction?
Is the wear on the wheel/treads all identical? (Different diameters on wheels due to wear can will result in different distaces for one rotation)
When on a flat surface (floor/table) is the frame flat/square? (Do all the wheels touch the ground? Even better do they all bear the same weight?)
Now based off of your explanation, I am not positive your field orientation from your gyro is working/being applied correctly. From an elecrical standpoint make sure they gyro is behaving.
From a code stand point ensure your gyro is giving the results you expect. Then you need to make sure the control loop is being closed with the gyro information.
If you can actually check weight, nirvana is equal weight on each wheel but that’s not always possible.
I road raced pretty seriously for almost 20 years and spent a lot of time with scales. There are a lot of things you just can’t move that impact weight - in a car that’s engine, transmission, battery, gas tank, even the driver. Same with robots - they are rarely symmetrical.
So what is balance? What are you aiming for? Every car has a “heavy” side and a “heavy” end. What you look for in terms of balancing is the diagonal weights - you try to get them as even as you can.
Imagine a 4 legged table - if you put a brick on it anywhere but the center, the weight on the legs will be different. If the legs are all the same length, the weight on the diagonals will be equal even though the table has a heavy side and a heavy end. Now cut a mm off of one leg - now that diagonal goes light because more of the weight is being borne by the other diagonal. That table is not going to handle well.
Bringing this back to robotics - many years ago, my team had a U-shaped robot - completely open on one side. During competition, one of the programmers noticed that almost all the drivetrain current consumption was on the front left and rear right motors - the other two were literally drawing something like 10A each - tops - while the others were drawing something like 60A each. This was a very early AndyMark swerve drive if I recall correctly (that was a breakthrough drivetrain at the time).
I didn’t find out about this until it got really bad but as soon as I saw this, I figured that our robot had bent and was no longer square to the floor - there wasn’t much we could do at the competition but we verified this at the shop and tried to triangulate as best we could to help reinforce the chassis. If I recall correctly, we were twisted something like 3/4" (almost 20mm) when measured to the floor from corner to corner.
Tying it into this exact discussion, that robot did not drive well - that robot tended to twist while driving because it the traction and power being put down were very uneven.
I think all of @Skyehawk suggestions are very worthwhile - check the mechanicals first. If anything is off there, the code will have a hard time compensating for it. The code has to assume the mechanicals are good before being able to do it’s part.