Team 2471 swerve drives

[Bryce2471]

Could you provide more detail about your software? e.g. Does it have 3 independent degrees of freedom (X, Y, and rotate) or just X and Y?

Yes. It has full 2D motion capabilities. All of these should be visible in the posted video.

What does the Driver Interface look like? Is it field-centric or robot-centric? etc.

The software is new. We have never programmed a swerve robot before so we kept it simple with a robot-centric driving system.
The code is made up of two, somewhat simple parts right now. First, the left analog stick input gives an X-Y heading. That vector is directly applied to each wheel. This gives us our translation or strafing ability. Next, the X component of the right analog input gives a turning value. This value is set as the length of a vector on each wheel for orienting the robot. The angle of this vector is defined as being perpendicular to a line between the wheel and the the center of robot rotation.
Then, one problem is that each wheel has two vectors that it is supposed to accomplish. The solution is simple: you just add the two vectors together. This presents a second problem. If you try to turn at full power and drive at full power at the same time, each wheel will try to drive at >100% power. This is solved by dividing each wheel's power by the power of the highest power wheel if that is greater than 100%.

Was the problem related to the gyro?

No,
This code, as I mentioned earlier works quite well, but it is somewhat difficult to drive. So before the off-season ends, we will be implementing a field-centric drive code. To get our sense of bearing, we will be using both gyro and compass sensors. To filter these inputs together we considered using a Kalman filter, but we decided it was not a good solution because it has a lot of tuning involved as well as not having a lot of information available on the details of how to tune them. We have decided to implement our own filter that is much more simple and gets directly to the solution. It essentially works by taking the height of the compass sensor on a graph and applying the curve of the gyro input to that.
We had a problem in the beginning: a small syntax error that caused a lot of very odd outputs and symptoms.

[Ether]

Originally Posted by Bryce2471

First, the left analog stick input gives an X-Y heading. That vector is directly applied to each wheel. This gives us our translation or strafing ability.

Next, the X component of the right analog input gives a turning value. This value is set as the length of a vector on each wheel for orienting the robot. The angle of this vector is defined as being perpendicular to a line between the wheel and the the center of robot rotation.

Then, one problem is that each wheel has two vectors that it is supposed to accomplish. The solution is simple: you just add the two vectors together. This presents a second problem. If you try to turn at full power and drive at full power at the same time, each wheel will try to drive at >100% power. This is solved by dividing each wheel's power by the power of the highest power wheel if that is greater than 100%.

Very clear explanation. Did you guys use resources on CD (papers, posts, etc) as a starting point, or did you work from first principles to figure out the physics and math?

[Bryce2471]

Did you guys use resources on CD (papers, posts, etc) as a starting point, or did you work from first principles to figure out the physics and math?

Originally, in 2012 at the championships on Newton field, I was inspired by the maneuverability of 1717. We were on an alliance with them in the elimination rounds. Unfortunately, they weren't functional for most of the quarter and semi final rounds, but I still wanted to make a drive train like theirs.
Partly because 1717 doesn't publish their designs or code, we took into consideration the resources that are available from team 1640. They are very generous to offer years worth of experience. While their detailed cad designs helped me get off the ground, their software papers were more complicated than I was hoping. So, essentially all of the ideas that went into this version of software came from the minds of the people involved in the project. We already have most of the ideas compiled for the field-centric version as well, but I'm sure we will run into some challenges that we have not yet foreseen.
After the field-centric version is complete, we will try out a new concept that is specific in solving the challenges involved in this years bunny-bot off-season event. the main challenge to the game is collecting and herding 6" foam dodge balls, while only using a three sided corral.
After bunny-bots, we will do our best to publish a white paper about several aspects of the project as well as post the designs so that others can use them.

Edit: Here's a link to us playing with 1717
http://youtu.be/X-Jm1vQ_bSk?t=24m26s

[Joe Ross]

Originally Posted by Bryce2471

Partly because 1717 doesn't publish their designs or code,

http://forums.usfirst.org/showthread...used-code-1717
http://forums.usfirst.org/showthread...re-season-code