In 2009, we created a field-centric turret system that let the gunner push the joystick in the direction he wanted the turret to face, no matter what direction the robot was pointing in. The only issue we had with the system was a hard impact would knock the gyro angle off.
In the off season, we’ve planning on developing a swerve drive, and I’d like to set the controls up the same way. As a result, I already know one of my primary controls problems is going to be how to keep that gyro from jumping out of alignment.
Now, I’m a mechanical guy pressed into work as a controls guy, so I haven’t dealt with much of the high level control stuff. I’m sure other teams have dealt with this same issue, but I’ll start by breaking it down into possible solutions:
First, you could try to use some other system to double check and remove the error. Wheel angle / distance encoders doing dead reckoning would be my first thought, but because the absolute angle of the wheels to the field would be dependent on the gyro they would quickly build up error and not a be a good source of correlation.
You could try to sense out-of-bounds conditions and simply ignore them. You could remove changes that exceed the spin-rate of the gyro, or any other odd fluctuations by putting a series of case-statement checks inline that create a correction factor.
You could continue to try to improve the gyro itself. I see that sparkfun now sells 1500 degree/second gyros. While I haven’t dug into their specs to check if their resolution and drift is still suitable, it seems like you’ll reach a point where you simply don’t have the issue anymore.
A hyrbid of 1: completely remove the gyro from the robot and do angle dead-reckoning using only the absolute wheel angle encoders and transmission encoders.
My team built a robot that did something similar to what yours did. However, ours was effective because no matter how many times we bumped into walls, in a two minute time frame our gyro was off at most 5 degrees.
This year we decided to buy a kind of gyro that gives gyros a bad name. Its horribleness could not be put into words.
If you, like we, think that the gyro was programmed and wired correctly, maybe you should try a completely different gyro just to see how that works.
My solution is to train drivers to drive robot-centric.
There are plenty of very good character-centric video games out there, most notably the GBA versions of the Tony Hawk series, that make training for this sort of thing possible.
Not what you’re looking for I bet, but the one year I had an omnidirectional robot to drive (in Vex), it got me up to speed fast enough.
Team 20 did a field-centric swerve drive this year. We used 10 turn pots to sense wheel angle (to allow multiple rotations and remember the position between matches) and the kit gyro. I believe it had about 2 degrees of error at the end of a match. Our driver was great at dealing with error though. He could keep going through 10 minutes plus during practice.
I’ve been promised that the guys who work on the FPGA will fix it for 2011, so that I can get I2C communication with it working - the compass does clock skewing and the current cRIO implementation doesn’t like that. With this sensor, and some well-placed encoders on the drivetrain, I should be able to drive any type of robot anywhere on the field during autonomous AND make the robot do whatever I want during the game (including field-oriented driving). With its integrated 3D accelerometers and the tilt-compensated heading, what more can you ask?
Keep us posted, I was planning on playing with a cheaper one this summer myself. I think the one I have interfaces over SPI but we were planning on making it and several other sensors run on a coprocessor anyway.
Sure, I was thinking of putting it into a white-paper or something if everything works out - including wiring schematics and a parts list. I personally like this rather integrated solution, everything runs off the I2C port on the digital sidecar so I don’t even have to document any “custom circuits.” I also don’t have to write any custom PIC code or anything like that, which makes documentation and replication of my sensor module much easier.
That’s a pretty awesome unit, but I noticed that it uses 3 mems accelerometers as well. They don’t list the maximum DPS of those - but won’t they have the same issues we already have with Gyros in collisions?
I see two relatively simple things that might be done, that are sort of device-agnostic. Rather than focusing on eliminating gyro error, perhaps you could instead make it easier to tolerate.
The first solution (the higher-tech route) would be to use the accelerometers in conjunction with the gyro. Since the majority of the gyro error is accumulated during gross impacts (as opposed to “normal” robot vibration), preserve the “good” value of the gyro until each impact is over. Then, compensate for the FPGA-produced value via addition or subtraction. A more sophisticated version of this approach might calculate the impact vector, and adjust the heading output based on the gyro’s directional impact sensitivity (which I suspect you’d have to measure yourself). Dunno, never tried that before; probably not worth the effort frankly.
The second (lower tech) solution is to give your turret operator the ability to re-zero the heading when necessary. For example, whenever the turret passes through an “observed” orientation (0 deg, 90 deg, etc.), give them a button to press which forces the gyro-based heading value to “agree” to that orientation. The upside is that this is easy to program, the downside is that it takes a little more work for the turret operator; ideally it would still result in an easy-to-operate system. We did something functionally equivalent on our Breakaway bot, wherein if things got hinky for the driver he could look at the indicated heading on the dashboard (to verify that it had indeed drifted) and manually re-zero the gyro heading by momentarily reorienting the robot and hitting a “re-zero” button. It sounds a lot more complicated than it was. In the end our competition driver decided that he preferred to operate things robo-centric rather than field-centric but at least he had the option available. Other drivers preferred the field-centric approach.
I’m sure there are other, probably even better ways to do this. I don’t think there’s a “perfect” gyro out there that will eliminate the problem - best to find a way to work around it instead.
If the field is flat, I say do away with the gyro and put two encoders on follower wheels. Using this method we get better than one-tenth of a degree of accuracy over many minutes of driving. If the field isn’t level (like this year), this becomes a little trickier from a mechanical standpoint of keeping the encoder wheels in contact with the floor.
What we did this year is incorporate a gyro with our encoders. While we were using the encoders for heading calculation (the normal mode of operation), we constantly updated a gyro correction term that forced the gyro heading to be equal to the encoder heading. This corrects for any gyro drift during the time when the encoders are being used to calculate the heading.
When the robot’s calculated X coordinate was within an area that we knew an encoder could leave the ground, we switched to the gyro-calculated heading. While using the gyro calculated heading, the encoders were correlated with the gyro to determine if an encoder lost contact with the floor. If so, we calculated an encoder correction term to force the encoder data to agree with the gyro. Once the X coordinate left the trouble area of the field, the robot would switch back to using encoder based headings (using the corrections from the gyro).
Like the previous poster said, you can also include a “Heading Sync” button or a heading trim pot. Those work pretty well when needed.
We used a vector-based system for our drivetrain this year. We used an X and Y gyro to calculate our first vector, and joystick data to calculate the second. By using wheel encoders rather than the joystick data, theoretically you should get a vector that would be more useful in getting absolute position. (We were only compensating for drifts in the joystick and the tenancy of the wheels to drift.)
Of course, redundancy is good. finding the average value of these, we were recording a 1.8% Margin of Error throughout the CT regional and a 2.1% in Atlanta. While not perfect, it’s certainly better than we expected, as we know that our gyros had a 1% drift on the X axis and an 8% drift on the Y. (Found by graphing signal over 100 reads on a stable surface.)
You lost me there; did you mean X and Y accelerometers? If you really did mean gyro (meaning yaw rate gyro), what axes did X and Y correspond with? Z seems to be the only one of interest…
Three unpowered omniwheels in a “kiwi” configuration (as the sides of an equilateral triangle, e.g. at 120 degree angles to each other).
An encoder on each wheel.
The entire assembly on a suspension to ensure that it never leaves the ground (assuming a flat-ish field).
Such an arrangement would theoretically give you drift-free position and velocity in R2, and would be robust to collision (as long as the wheels don’t leave the ground).
My team used the kit gyro this year for field-centric control along with 6" mecanum wheels.
We foresaw the issue of the gyro drifting too far that the robot would become difficult to control, so we instructed the driver that if that’s the case, to square the robot up against a field element and reset the gyro using a button on the controller.
I don’t think we ever got to the point where the driver needed to reset. I know when we tested in a classroom (and were hammering the robot to the point where one of the AM mecanum wheels broke), the gyro didn’t drift any noticeable amount (we ran it for about 20 minutes before having to replace the battery, thus resetting the system).
By the way, 2-5 degrees of drift is very hard to notice. Unless you were trying to score a ball from the far zone this year, you’ll never need to be that precise.
Worth noting (to anybody that may have missed it) is that the mid-season LabVIEW update included a new WPILIB version of the HolonomicDrive.VI which featured a gyro input to allow for easy field-centric driving. To make it robot centric, the input could be left unwired or forced to “0”. Not directly applicable to swerve control, but conceptually relevant nonetheless.
If your problem is due to gyro saturation caused by bumps then you might
consider another hybrid solution with coarse and fine scaled gyros. Coarse is a high-max-rate-low-resolution gyro and the fine is a low-max-rate-high resolution gyro. Simply switch the heading integrator input from the fine gryo to the coarse when saturation is detected on the fine gyro. This is added complexity, but gives you the best of both worlds of precision and dynamic range.
I would use the encoder heading over this if they are on the robot…if not , this might prove cost effective.
One was mounted as documented on the X axis, while the other was oriented 90 degrees to the X, on the Y axis (we used that to do an inverse-pendulum system, so we could balance and travel across the bump)
What about using a compass. Wouldn’t this give absolute position, without the need for gyros? Sure, they’re a little more expensive, but their accuracy would be much more than that of a gyroscope.
Others have reported (and it makes a lot of sense) that the compass modules they’ve used are very sensitive to the “natural” EMI environment around the permanent magnet motors in our bots. My own limited experience with such modules outside of a FRC environment matches their observations, so I don’t have a high degree of confidence in that approach.
What if you created a “calibrate” mode, where the driver can push a button to recalibrate a gyro to what the compass sensor is outputting when they think there is a significant amount of drift. That way you don’t have the interference but you still have the consistency.
