Swerve drive with automatic rotation?

[connor.worley]

I've been looking at different drivetrains, and it seems like full omni swerve drive doesn't offer any huge advantage over left/right linked crab drive. I can see the benefits of being able to turn and omni drive at the same time, but it seems like too much work for the driver if they have to manually control the turn.

But if you put a gyro/compass on the robot, you'd be able to automatically turn to the direction you're driving in. i.e. you'd be able to score a tube, then back up and automatically rotate 180 degrees at the same time.

If you wanted to you'd be able to drive the robot off of a single joystick, although you'd probably want another that uses classic arcade drive so that you can make precise adjustments for scoring.

Are there any teams that have implemented this functionality into their swerve systems? Is gyro drift an issue? Anyone have experience with non-MEMS (such as fiber optic) gyros? Do compasses work?

Thanks,
Connor

[big1boom]

We have something like this implemented with our mecanum drive this year. Instead of going full field oriented due to the different travel speeds (forward is faster than sideways), we have a gyro snap to angle function. We are using an xbox 360 controller. To snap to 0 degrees (direct towards the rack), the driver just has to hold the 'A' button. To snap to 180 degrees (feeder slot), the driver just holds the 'Y' button. Whenever one of those buttons is held, the robot disables the rotation joystick and will try to maintain that heading. It is actually pretty cool to watch, and fairly simple to drive.

We have not encountered too much gyro drift, but we do have a reset button that reinitializes the gyro.

I have a feeling this could be implemented with swerve in a similar way

[AllenGregoryIV]

We didn't have swerve but we had a fully omni-directional drive with driver centric control software. It was a very intuitive way to drive the robot. Our driver could pick up a tube and while driving back to the base either manually turn the robot with his right joystick or hit a single button and have it swing around to face him, all while just pulling the left joystick back to keep it moving towards the rack. A PID loop is running constantly to hold the orientation of the robot so even if it is hit it will turn back to the correct orientation. This could very easily and I believe has been implemented on independently steered swerve robots.

Having the robot automatically turn to the direction of travel would not be difficult but I don't think it would be all that beneficial. When you wanted to strafe the robot would turn to that orientation instead of sliding sideways.

Initially our design process lead us to believe that a fully omni-directional swerve drive train would be best for this years game, manufacturing and cost limitations prevented us from attempting to build it.

[connor.worley]

The reason I think the auto rotation would be effective is because it would enable you to quicly and easily pick up tubes around the robot. All the driver has to do is drive towards the tube. I agree that classic strafe/arcade would be better for scoring though.

[AllenGregoryIV]

We have the 4 top buttons of the joystick act as rotation setpoints. It makes it very easy for our driver to get our collector to the right orientation for the tube. A drive mode that moved in the direction of travel could be pretty easy to implement and could be another option for tube pickup.

Also note that we don't use the arcade and strafe control interface instead we have our left joystick do robot x and y velocity and the right one controls rotation.

[Ether]

Originally Posted by AllenGregoryIV

we don't use the arcade and strafe control interface instead we have our left joystick do robot x and y velocity and the right one controls rotation.

I think that's often referred to here as "Halo" drive.

[The Analog]

Team 79 has always done this with our swerve drives (03,04,05,11). In years past we used modules with the drive motor attached, and the front and rear were steered separately. This year we have a coaxial design, each wheel is driven independently, and the front and rear are steered separately. we only use one stick to drive, but have different driving modes.

Crab Mode: standard Crab driving, robot translates in any direction while maintaining the robotics original orientation.

Power Caster: rear wheels rotate 90 degrees, while front stay straight. works similarly to car drive

Hurricane/Tank: standard tank drive, allows robot to rotate along its center axis.

all driving modes use a gyro and accelerometer. I'm mechanical and don't fully understand it, but I can put you in contact with someone who does.

[Ether]

Originally Posted by The Analog

rear wheels rotate 90 degrees, while front stay straight. works similarly to car drive

Perhaps a better analogy would be a fork lift drive?

[Chexposito]

last year we had crab drive and had this really complicated function that allowed you to move the robot in the direction you move the joystick. no matter how the robot was oriented it would drive that direction in a straight line. it made it extremely easy to drive. the only time we had problems was when the steering chain came off. we just had to reset the "tophat" encoder for the steering when that happened though. no problems with the gyro drifting...

[Ether]

Originally Posted by Chexposito

last year we had crab drive and had this really complicated function that allowed you to move the robot in the direction you move the joystick.

what made the function so complicated ?

[Chexposito]

Originally Posted by Ether

what made the function so complicated ?

well the wheels had to turn to 90 to make the long side as the forward for Z our iri robot was made long side first, which took out this need. our crab-drive couldn't turn forever, so we had to be sure not to twist off of cim wires, thus we had to count to a certain point before our wheels would twist back to where there was no wrap. we also had to create a function that converted the counts from 0 to 360 no matter what the count. then a pass that into another function that decided the closest way to get to the heading determined by the joystick. then had to do vector addition from the joystick to create a magnitude from 0 to 1 along with a degree for the heading. on top of that, using the gyro to correct to where you where "pointing with the joystick" is where you where going. also the pid used on the steering... it was a huge head ache that pretty much created a mentor programmed robot... which was pretty much trying to make a crab drive have the ability to maneuver like mecanums...
this year was different... however some people on the team that had no idea what went into creating all of the stuff above, which may not be all of it, wanted something similar with this years robot which is a 6 wheel drive... i told them no, because there was no reason to do so with such a simple drive system.

[Ether]

Originally Posted by Chexposito

we also had to create a function that converted the counts from 0 to 360 no matter what the count. then a pass that into another function that decided the closest way to get to the heading determined by the joystick. then had to do vector addition from the joystick to create ... a degree for the heading.

Since you are a programmer you may be interested in this. The following 2 lines of C code will do everything mentioned above. Try it with any gyro angle (positive, negative, greater than 360, etc) and any Joystick coordinates:

error = atan2(Xj,-Yj)*180/pi - gyroAngle;

error = error-360*floor(0.5+error/360);

"Xj,Yj" are the "uncorrected" joystick coordinates (Yj = -1 is full forward)

"gyroAngle" is in degrees clockwise

"error" is the clockwise angle error in degrees. It is the shortest path to the target.