My team has been manually turning the wheels on each swerve module to their starting position, I want to change that this year and have the modules automatically align themselves to the starting position in the programming using the encoder offsets. I noticed other swerve teams not having to manually align the modules. Can someone give me an idea of how I can do it?
One thing to remember is that encoders work like counter. They start at 0 when the robot starts and counts rotations.
With this in mind, it is quite impossible to auto align an axis to a starting position using an encoder only. To do this you will need another sensor or a different sensor.
For example, if you use an encoder for an elevator you might add a limit switch at the bottom which reset the encoder value to 0, then at the start of the program you can tell your elevator to go down until the switch is pressed and you are sure now that your encoder count is at 0 (bottom most position for the elevator).
Another way, is using a potentiometer (maybe a multi-rotation one). The advantage of a potentiometer is that it is not a counter but rather an voltage divider read by an analog input. This way, a potentiometer can report the “real” location even after a Rio reboot.
Of course each sensor has it advantages and disadvantages. Choosing the right ones for your system is the key.
Hope that gave you some idea about how to auto align. Good luck!
What you are trying to do is certainly possible with just one encoder, but you have to use an absolute encoder to do it. As @Omer_Huly said, incremental encoders only measure the difference in angle traveled; they can’t tell you what angle you started at. On the other hand, absolute encoders work differently and can tell you what angle you start at relative to an absolute frame (hence the name). This encoder will also have to be either directly attached to the module or at a 1:1 gear reduction with it. Otherwise there will be multiple module angles that will give the same encoder reading, so you can’t determine with certainty what angle the modules are pointed.
With this absolute encoder, you can start the match with the modules pointed in any direction and the robot can compensate for that on startup. If you look at the many models posted here on CD and sold by various FRC suppliers you will see most of them have this absolute encoder to measure module angle.
For an example of a dual output encoder, check out the SRX Mag Encoder, it’s what we use on our swerve.
Our swerve design uses limit switches placed on each swerve module, with a small piece of Lexan placed such that it will trip the limit switch once per complete revolution. We then call a method in our code that rotates each swerve module until the limit switch is tripped, then resets the encoder counts.
As others have said, you can also use an absolute encoder. We’ve used these ones from US Digital with success in the past.
If you have talons srx’s to control rotation I can’t see a reason to NOT use a mag encoder. They are so simple to integrate into the talon. They have absolute and relative. I know 2767 and our team “seed” our relative encoder with the absolute position at startup. I don’t even know if the speed of reading the relative vs absolute is worth it but it works well for us.
Here is another good absolute encoder option that has been used for a long time.
We are currently using The SRX Mag Encoders only in their relative positions. I want to know if their is a way to use the absolute position in the programming.
Heres links to the docs: https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html
Something like this…
I asked some teams at Detroit championships about their swerve and they said they were using offsets in their code for their alignment. How does that work?
- Get the absolute encoder value when module is in home position.
- On startup, get absolute encoder value of starting position.
- Subtract home value from starting value. This a distance from home position.
- For incremental encoders, then convert that distance (angle difference) to relative values (4096/angle difference, often).
- Add the incremental count to the initial difference from home position. Feed that sum to the PID for your process variable.