Team 2471 swerve drives

[gpetilli]

Originally Posted by yash101

This is partially off topic, but if you were trying to lock direction/orientation using a gyro or accelerometer, would you use a coprocessor or would you use the cRIO? Don't you need to continuously monitor it to make sure that the results are accurate? Also, what about some mechanism that works like an array of optical mice? I guess that the FPS would be a tad high for the mice sensors, but it should be able to gather movement!

Multiple threads have tested the cRIO and claim it has more than enough compute power. The standard driver station "periodic" rate is 20ms, which is what we are currently using.
The X,Y movement will use something similar to a mouse. We are using a 3D printed fork assembly to mount two orthogonal un-driven VEX 2.75 omni-wheels with VEX encoders tied to the cRIO FPGA to measure in/s. We are not using encoders on the driven wheels given the amount of slip we expect from a Killough drive.

[gpetilli]

Originally Posted by magnets

That's really neat. I've ever thought of using two different sensors, an angular rate and an absolute rate sensor as two different sources of feedback for a PID loop. Out of curiosity, which compass sensor are you using and have you had interference issues in the past?

We are using a 9DOF IMU called a GY-85 which we got on ebay for $16 including expedited shipping (from Hong Kong so still took a week). It has a 3axis compass, 3axis gyro and 3axis accelerometer all on a single I2C bus which we tied to the DSC. The board is tiny (< 1 sq. inch) but does not have a processor. We read the X,Y magnetometer values and compute atan2 on the cRIO.

We originally mounted it on the main electronics board - which worked fine for debugging I2C and gave accurate compass readings... until we drove the motors. We moved it to about 18" above the motors and that seems to be fine. We have not tested it with other robots on the field yet, but given 18" was enough we are hopeful it will not be an issue.

[brianbond]

Awesome design! Question for ya, have you had any problems with plastic gears?

[yash101]

After comparing the "~37lbs" to other drivetrains, THAT IS VERY LIGHT FOR A SWERVE DRIVETRAIN (I think I needed those caps ). I think that that may be around how heavy the KOP chassey should be! Good work Bryce and Team 2471!

[Tyler2517]

Originally Posted by brianbond

Awesome design! Question for ya, have you had any problems with plastic gears?

If i remember correctly their plastic gears are for the encoders only, they have timing/gate belts for the drive loads.

On a side not the pocketing on then modules for the encoders was an amazing idea. The weight of the swerve is the lightest I have ever seen and will only be getting litter by the time of next season.

[M3rcuriel]

Originally Posted by gpetilli

Yes, FRC1559 is planning this for 2014. We are implementing a fusion sensor of a compass and gyro in a velocity PI loop. The gyro is the P velocity feedback and the compass is the I feedback (conceptually it directly reads the integrated error).

When turning, the current heading is updated to the current compass. When not turning, the PI loop is closed loop to hold the heading (which helps reduce affect of gyro drift).

At initialization, the robot snaps a zero heading. At any time the driver can press a "hat" button to command the heading to be one of the primary orientation (plus maybe feed station). The PI loop will drive the orientation while the driver continues to command XY translations.

We have this working with our asymmetric Killough drive, but only have about 30min of testing under our belt. Focus has moved to a similar fusion PD loop for X and Y with a follower wheel for velocity error P and an accelerometer for the differential error D.

Have you guys found that using this sort of PID loop is more useful than using other sensor integration techniques such as a Kalman filter?