Tips for a good swerve code

Hi, so my team and me are workning on programming a swerve drive. We already did the basic swerve code drive and it works pretty great, but I was wondering if there are any tips for making a better swerve code, in a way that the robot itself moves better/faster.

Thank you!!!

  • Armando (Imperator 5887)

It would certainly help if we could see your code to see what you’ve already done but here are some good practices for increased speed/reliability:

  • Control both turning and driving with position and velocity PID, respectively.
  • Current limit your motors as high as you reasonably can, as this will increase peak power and thus acceleration and speed. 60 for each drive motor is a good starting point, but if your batteries are in good health (internal resistance <=0.015) you could easily go up to 70 or even 80.
  • Ensure you have a skew limiter on your joysticks to slow down acceleration a bit. This will lessen the likelihood of tipping by a LOT.
  • Try to use onboard PID for the turning motor if possible. This will generally be much more reliable and react significantly quicker than using your absolute encoder as a feedback device.
2 Likes

A wheel has a motor, and something to measure its rotation. The wheel can be pointed along its azimuth by another motor and rotation measurement sensor.

Those four things come together to form a “swerve module”.

A drivetrain is made up of four swerve modules.

A drivetrain may be commanded by a human, or by an autonomous routine.

Your code’s structure and naming conventions should reflect this.

image

5 Likes

A small thing is based on driver preference you can pass joysticks through a function so velocity isn’t directly proportional to how much you push but instead nonlinear (eg x^2)

A bigger thing is doing drive characterization for feedforward values in auto

3 Likes

Add a gyro and code to the basics to use field orientation for the driver.

1 Like

Actually I don’t understand quite well how feedforward affects the robot movement, I know how to do it but I Don’t know its pros and cons, so does feedforward only improves its drive on autonomous or is it also better in teleop?

Thanks so much

When talking about feedforward are you talking about the modules themselves specifically or factoring in the overall robot acceleration/velocity as a whole? We tried doing a regression on the velocities of our individual modules and their velocities this year, and simply put, it didn’t work.

Thanks!

  • “Latency compensate” your gyro angle so that your robot translates in the correct direction when rotating.
  • Implement intelligent snap to angles for common game actions.
  • Properly compensate your gyro yaw reading so if your bot spins in circles a bunch of times there is no drift.
3 Likes

It’s usually only used for autonomous movements because it helps keep a targetted velocity/acceleration. (pid helps correct a little bit but feedforward should be doing some heavy lifting)

In teleop most teams just run open-loop control but you can do either (doesn’t hurt)

Usually, you do it for the robot as a whole

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.