Swerve Drive

[DuskProgrammer]

This year my team is thinking of using swerve drive for the first time. We are planning to use the ones off AndyMark since we can't make our own.
http://andymark.biz/swervemodules.html

However, since this will be our first time (if we use it), I don't know much about how to program it. I would appreciate help in knowing if I need to get any other sensors for it. Additionally (and the main reason I'm posting it here), I would like some help in figuring out how to program it in Java/C++.

I would like sample code if you can provide, as well as different ways I can implant the driving while trying to keep it simple enough that the drivers can figure out how to drive it.

Thanks.

[DonRotolo]

A swerve drive is the most challenging kind of drive to implement. You might want to consider that if you've never done it before.

Here's a hint on the programming: Use polar coordinates for your joystick inputs. The direction of the joystick determines the direction of motion for the robot; the distance from the center 'neutral' position determines the magnitude of the motor speed.

Easy to drive, very intuitive. Programming, not so easy.

[Dave McLaughlin]

I might also recommend a three axis joystick on the control side of things. Off the top of my head I know that Team 1983 and Team 179 implemented a single three axis joystick for control of there respective swerves last year.

[James Tonthat]

We had a similar system designed before the season and didn't look like we'd be able to use it wouldn't be able to climb a ramp, look at the approach angle of the Team 221 swerve module you're looking at. It doesn't look like it will clear the ramp.

[DuskProgrammer]

Thanks for the quick replies.

I was wondering if I would need to get sensors if we use swerve drive. If so, what kind of sensors do I need?

Also, it would be nice if one of the teams that use swerve drive could provide a sample of the drive code. It would be helpful in showing me how to implant it and saving me time. Otherwise, I'll probably end up writing code that doesn't work as well and not having much time to improve it.

[EricH]

Originally Posted by DuskProgrammer

Thanks for the quick replies.

I was wondering if I would need to get sensors if we use swerve drive. If so, what kind of sensors do I need?

That's NOT a question--if you're doing swerve and you don't have at least one sensor monitoring module rotation per set of independently rotating modules, you're probably doing something wrong. You need a sensor that can tell what angle the modules (and therefore the wheels) are at relative to the robot. Backups are also a good idea for redundancy. I think a lot of teams use encoders or pots; exactly which one depends on the team.

Oh, and for the programmer: Have an "emergency" tank drive mode that can be used if rotation fails or if you simply want to drive tank style, if your mechanical design will allow for it. With those, yes, you should be able to do it.

[Guopeter]

Originally Posted by DuskProgrammer

Thanks for the quick replies.

I was wondering if I would need to get sensors if we use swerve drive. If so, what kind of sensors do I need?

Also, it would be nice if one of the teams that use swerve drive could provide a sample of the drive code. It would be helpful in showing me how to implant it and saving me time. Otherwise, I'll probably end up writing code that doesn't work as well and not having much time to improve it.

Hi there,
I was the programmer for team 2609 last year and I coded the their swerve drive system that worked very well.

Programming could be simple, if you can understand the main concepts. It's NOT that scary.

The goal of the program is to keep all four wheels in the same orientation. The programming depends on how you link the swerve modules.

There are three ways to link:
1. Use two chains to link the four modules into two systems (left and right)
2. Same as 1, but add a third chain to link the two systems (left and right) to "synchronize" them
3. Use no chains (have the four modules individually driven by a motor)

With BeaverworX last year, we used Method 1; TWO quadrature encoders were used, one for the left side, one for the right side.

1. Set the "setpoint" for the encoders as the "Axis-X" of the joystick
2. Do some math to find a conversion factor so that at the left-most (or the right-most) value of Axis-X becomes the setpoint for a 90 degree turn to the left (or to the right, if you're using right-most value from x-axis)

The math is this:
Conversion factor = (Leftmost value of X-Axis) / (Number of pulses per 1 revolution/4)

*watch the brackets
*the conversion factor is an absolute value
*make sure at the original position, all wheels point straight ahead (not angled), at this point, the encoder reading is set to 0.
*The values of X-Axis should be from -128 to +128 or a range of numbers from negative to positive. If not, convert it so it is, this makes programming smooooooooooooooooooooooother

SETPOINT = (Value of Axis-X) / Conversion Factor

3. Once you have a setpoint, use that number as the SETPOINT for your PID motor control to turn the module.

4. Tune your PID constants

Now, if you want to control the wheel rotation speed as well as well its swerve using one joystick with two axes (x and y), it is possible (2609 used last year). The algorithm is a bit more complicated in which I wont get into if it's not something you'd like to have.

I hope you're using Labview. You can create some panels to make the tuning part fairly easier.

First time programming this could take around 5~10 hours, including tuning.

Good luck,
Pie Man

[virtuald]

Our team did swerve drive last year, the math for doing it isn't too bad. We found that the harder problem was that we ended up with (essentially) 4 custom servos, and getting them all to line up properly was the harder problem since we were using 2 different sets of motors, and we weren't using absolute encoders (dont ask).

Our C++ code from last year is available at my website: http://www.virtualroadside.com/FRC/

I hope you're using Labview. You can create some panels to make the tuning part fairly easier.

I created a tool in C++ called WebDMA (http://code.google.com/p/webdma/), that installs a webserver on the robot, which integrates easily with your code and allows you to do tuning tasks. Its quite nice. Theres a demo of the interface on the project site.