# Programming Crab Drive

As a off season team 1525 is working on crab drive. We have gotten working on the design but ran into a problem, how do we drive it. it is simple for when the wheels are all facing forward but how do you turn when your wheels are turned and how do you program that.
Additionaly we are thinking steering to be almost as if it was a FPS. one stick to control frontward and backwards motion as well as moving on an angle, and have the other stick for physically turning the face of the robot.
Froggy

This is a problem that will take some time and patience to think through. I don’t want to deprive you of that learning experience, but I’ll give you some insight as to how we do crab.

Our left stick is our crab stick and the right stick is the drive stick. Up until last year, we mainly only looked at the X-axis of the crab stick to determine the desired crab angle. Centered meant an angle of 0 (straight ahead) and full left/right represented ± 90 degrees. Last year and this year, we took the approach of treating the crab stick as a polar coordinate system. We look at the angle component and map that directly to a crab angle (i.e. point the stick 45 forward right and the crab angle becomes +45). The trick here is to also look at the magnitude component and treat the angle as 0 unless it’s outside of some deadband.

It gets slightly more complicated with the drive stick. We will behave differently depending on where the crab stick is. If the desired angle is between ± 30 degrees we treat the drive stick as a standard arcade stick. Once we get beyond the 30 degree mark, we only look at the Y component of the drive stick to get a desired speed for all wheels. This is because if you were to allow a tank turn while crabbed, the wheels will oppose each other. Once we get to ±30 degrees around ±90, we allow tank turn again, however we have to do some logic to make sure the wheels are driving in the right direction instead of opposing each other. We usually don’t allow tank turn when crabbing, but this year had some benefits (we also had something similar in 2003).

Beyond that, you can do some cool things based on what buttons are pressed on the controller. For example, last year, we had buttons to do car steering (front wheels crab, back wheels fixed at 0) and monster steering (front and back crab opposite each other to get a tighter turn radius).

The biggest thing that you need to do is think through exactly what you want the behavior to be. Once you know that, it’s just a matter of piecing the program logic together.

You guys are close enough where if you have problems along the way, have Herb get a hold of us and we can try to walk you through your issues.

I agree with Dave - it’s a worthwhile exercise to think through the whole of this problem with the particulars of your drive system. This is the first year our team has attempted a swerve/crab system so I’ll say a little about how we approached it. But first I’d like to put in a plug for not using standard kit joysticks.

We have had some success in using the Logitech Dual Action Game Controller (~\$20 from Target) to control the crab/swerve drive system we developed this year. The Logitech device gives you a pair of thumbsticks along with numerous buttons, and our drivers seem to prefer it to traditional full-size joysticks. Being hand-held you can stand slightly away from the team station and also stand at full height which helps a little in seeing the action on the field.

The original idea was to use the control sense of video games such as Halo, where the left stick controls forward/reverse left/right movement (translation) and the right stick controls rotation http://halo.wikia.com/wiki/Halo_Controls
We changed that a bit during development, and ended up with a control model where the left stick controls speed and the right stick controls the various forms of steering.

This year was also our first year with a crab/swerve type drive.

We had the left stick controlling CIM power, and the right stick controlling various types of rotation.

If the driver pointed the right stick +45 degrees, all the wheels pointed to +45 degrees, etc (Translation)

However, if the driver pulled the trigger, and twisted the stick full right, then the front wheels pointed 45 right, the back pointed 45 left
If the driver twisted full left and pulled the trigger, the front pointed 45 degrees left, the back 45 degrees right. (Rotation)

With this, we were able to “Warthog” our drive system for turning

Make sure that you have quality sensors for your wheel rotation. If your program doesn’t know where your wheels are, crab or swerve is going to be VERY hard on your driver.

We’re strongly considering doing an off-season swerve/crab drive this year.

We have some questions about the programming as well. Namely:

Does your joystick relate to the field, or to the robot? For instance, if you push to the left with your “crab” joystick, does your robot go to it’s left, or does it go to the left on the field?

If it goes to the left on the field, I assume you’re using a gyro to keep track of absolute angular orientation versus the field: do you have any problems with collisions throwing your gyro readings off?

Thanks!

All of our desired crab angles have always been relative to the robot. It’s the simplest, most intuitive solution in my opinion.

We’ve thought about making it relative to the field, but a good driver will beat out a noisy gyro reading any day. Unless you do some processing to keep it in check, gyros can be more and more unreliable the longer that it is being used because of the noise being included in the double integration.

Other than noisy data, a major downside to being relative to the field is starting position. If you don’t line up exactly right, you’re going to be off for the entire match.