swerve drive

[Aslihanokur]

Hi teams,
This year we want to use swerve drive thus we tried it but there is a problem: We used the codes from team 1640. On the 1640's programme, cables are wired from encoder to analog. We cannot wire the cables to analog because cables have 8 outputs but the roborio has 4 inputs in the analog part. Therefore we searched it on the internet and found that we should wire the cables which come from encoder to roborio's dio part. We did it in this way but the code didn't work. In the programme that we used, the wheels don't move synchronously.
We cannot determine the source of the issue. Is it because of electronics or programme? What should we done? Can you help us please? Thank you

[GeeTwo]

I'm not familiar with 1640's code, but if it is written for analog inputs and you're wiring it to DIOs, you will need to (at a minimum) modify the code so that the tracking info comes from that source; I would also expect that some sort of rescaling would be required.

Also, I don't really know how to say this, so I'll just rip the bandage off. If no one on your team understands the control system well enough to have already realized what I wrote above, you're a long way from getting swerve working right; you really ought to reconsider putting this on the shelf until after STEAMworks is done and do a different drive chassis this year.

[Ether]

Originally Posted by Aslihanokur

We cannot determine the source of the issue. Is it because of electronics or programme? What should we done? Can you help us please?

Apply a forward, strafe right, and rotate clockwise command and look at what speed and steering angle your code is sending to each wheel.

Look at those 4 pairs of speed/angle (one for each wheel) to see if the computation is being done correctly in your code.

And then take GeeTwo's advice in the previous post.

[rich2202]

I'm guessing there are 2 encoders per module, thus the 8 outputs (4 per encoder).

While the RoboRio has 4 labeled Analog Input ports, the MXP Port provides 4 more Analog Input ports.

If you use something like the NavX board, it will translate the i/o ports available on the MXP to traditional plug compatible connections.

[page2067]

Originally Posted by Aslihanokur

Hi teams,
This year we want to use swerve drive thus we tried it but there is a problem: We used the codes from team 1640. On the 1640's programme, cables are wired from encoder to analog. We cannot wire the cables to analog because cables have 8 outputs but the roborio has 4 inputs in the analog part. Therefore we searched it on the internet and found that we should wire the cables which come from encoder to roborio's dio part. We did it in this way but the code didn't work. In the programme that we used, the wheels don't move synchronously.
We cannot determine the source of the issue. Is it because of electronics or programme? What should we done? Can you help us please? Thank you

It sounds like your encoders are Quadrature encoders - given that they have 2 outputs per. Quadrature encoders do wire to 2 DIO's each, however You want to have Analog or Absolute encoders for most swerve codes, I am pretty sure including Sabotage's code - this is also what we have
used in past. If not familiar - search on the many threads on CD on this.
Typically also with absolute encoders on a swerve the encoder is reading 1:1 the steering output - depending on your set up you may need an auxiliary gear, agin there are several CD posts that cover this that you can search on.

It is possible to use quadrature, (relative) encoders that you have - but I do not recommend. It involves different code of course to read and use the quadrature readings, and other considerations (initialization) and is not favored by most teams (at least by my informal observation) that run swerve. Though I believe 973's old off-season swerve may have used relative encoder.

Good Luck!

[laura1640]

Hello,

On our swerve modules, we use two different sensors. One is to determine the angle that the wheel is pointed to. Like others have said, this is an absolute analog sensor. This is helpful because regardless of what angle the swerve modules are facing when the robot is powered on, they will still read the correct angle. Each of these sensors gets plugged into one of the 4 analog IO ports on the roborio.

The second encoder is used to determine the distance that the pivot has moved, similar to other drivetrains. This is mostly useful in autonomous, where the distance the robot travels needs to be exact. These sensors can be plugged into the digital IO ports on the roborio.

Also, may I ask what version of our code you are looking at (as in what year)?

~Laura

[Aslihanokur]

Originally Posted by laura1640

Hello,

On our swerve modules, we use two different sensors. One is to determine the angle that the wheel is pointed to. Like others have said, this is an absolute analog sensor. This is helpful because regardless of what angle the swerve modules are facing when the robot is powered on, they will still read the correct angle. Each of these sensors gets plugged into one of the 4 analog IO ports on the roborio.

The second encoder is used to determine the distance that the pivot has moved, similar to other drivetrains. This is mostly useful in autonomous, where the distance the robot travels needs to be exact. These sensors can be plugged into the digital IO ports on the roborio.

Also, may I ask what version of our code you are looking at (as in what year)?

~Laura

We used the codes that you wrote at 2012-Rebound Rumble. I wonder if we can set the swerve drive without absolute encoders. We reshaped our codes and made some replacement on our electronics. Actually it worked.However, ıt got the point that start at the begining as zero so that we need to make all 4 wheels at the same position before we send codes the robot. Are there any solution except using an absolute encoder?

[laura1640]

If you wish, you can get some more recent code from https://github.com/frc1640. The past few repositories also have Java code for swerve if you are interested.

Using an absolute encoder will save a lot of trouble. You could try saving the value of the encoders to a file and use the last values to initialize the position the next time you power the robot on. However, if someone moves the pivots while the robot is off, it will cause problems. I would advise looking into adding an absolute encoder to your swerve for convenience.

~Laura

[asid61]

Originally Posted by Aslihanokur

We used the codes that you wrote at 2012-Rebound Rumble. I wonder if we can set the swerve drive without absolute encoders. We reshaped our codes and made some replacement on our electronics. Actually it worked.However, ıt got the point that start at the begining as zero so that we need to make all 4 wheels at the same position before we send codes the robot. Are there any solution except using an absolute encoder?

Some teams use a magnet and a hall effect sensor to set the "zero" position for the module. Or, you could use a jig of some kind to align all the wheels at the start of the match.