To my knowledge, when you write code for a Swerve Drive, you will need CAN motors that have integrated sensors, like the Falcon500’s or CAN Spark Max’s.
Is it possible to program swerve without those sensors?
As for my second question, is it possible to code a swerve without the absolute encoder? Can’t you just point all the wheels on the drive straight/forward in the same direction?
Our team is new to swerve, and so I’m not so experienced in programming it.
Any help is greatly appreciated.
You do not need a CAN based motor controller however if you don’t use one you will end up using more sensors not less. In order to control the velocity (as speed meters per second) and angle of each module you need to know where the wheel is in someway or another. You do not need an absolute encoder as long as you trust the encoder for the steering/azimuth/angle motor will not drift during a match and you have all of your wheels aligned at startup correctly.
It is more annoying to realign the wheels during startup every single time than to just use a absolute encoder and you cannot take drift into account when you do this too.
So in short, yes but it won’t work well.
If you’re interested in learning more i wrote some documentation on the fundamentals of a SwerveDrive (not a complete guide) here.
Forgive me if I’m reading between the lines too much, but it sounds like you need to consider the difference between open loop and closed loop control before you dive into the swerve implementation. Without sensors, you’re operating in an open loop where you tell the motors to move to a location and hope they get there. Reality will creep in and eventually you’ll have a lot of error between where you wanted to be and where you are. The sensors close the loop so that the robot can correct the errors between your desired positions and the reality.
Only some combinations of wheel steering directions will allow the robot to move, which is very much unlike a differential drive, where any speed for either side causes predictable motion. For example, if you point swerve wheels in an X-pattern, the robot will not want to move in any direction for any drive motor percentage. Or, if you point three wheels forward and one backwards, the robot will try to spin in a circle…poorly. In order to get a swerve drive to move predictably, the wheels need to be pointed in the correct directions, and the drive motors need to apply torque in the correct directions.
You must have either a steering-motor encoder (relative steering encoder) or a module position encoder (absolute steering encoder) – with neither, the modules will quickly end up pointing in the wrong directions, even if you home them manually.
If you omit the absolute encoder, you will need to home the wheels after each power-off before driving. Either the roboRIO or the internal controller of your motor will need to keep track of the deviation from the home angle, since there’s no absolute reference. If the homing is lost (e.g., roboRIO reset, brownout), you might be unable to drive until rehomed, or end up dragging one or more wheels.
If you omit the steering motor encoder (the one built into the motor), it’s less consequential. Typically, this results in poorer resolution for the steering, but you’ll probably be able to write a control loop that uses the absolute encoder instead and drive normally. WCP’s SwerveXS modules allow you to use a brushed motor for steering, for example, using the absolute encoder to achieve the correct steering angle.
If you omit the drive motor encoder, you don’t lose the ability to drive – at least not in teleop. Swerve works pretty decently without controlled drive motor velocity. However, you do lose odometry; you won’t be able to move as accurately in auto, and you may need to use alternative sensors (e.g., vision). This used to be the default in the pre-brushless era – you’d need to add encoders to the drive motor shafts or wheels in order to use odometry.
Note that there is often one additional sensor in each swerve drivetrain: a yaw gyro. Without this, the drivetrain can’t be controlled with respect to the playing field; it has to be controlled with respect to the chassis (e.g., joystick forward → chassis forward instead of joystick forward → robot goes down-field).
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.