I have noticed that most of the robots here use a skid steering drive.
How do most teams decide which values to use in the autonomous mode for getting to a location on the field?
we have switches on the robot to flip to indicate what positition it is at. our programers found it easier to do that
so, then its just experimented values?
yes and no, we had a lot of encoders on our robot so we knew exactly how far it went, but the turning we did was experimental. (we had a crab drive)
here’s a pic: http://www.teamdriven.us/media_page/media_images/newpictures/shipday/images/102_2390.jpg
oh, crab has several advantages over tank for navigation.
I wish that kinematically modeling a skidsteer was easier for navigation.
If my team would use crab, I would already have made a navigation model, and have a route planning algorithm.
Navigation with skid steer is harder, and it seems no teams have done much with it
almost requires some type of position/orientation feedback, eh?
Skids are difficult to predict.
A combination Gyro, encoder, + inertial mesurements?
Pretty solid results have been achieved with just encoders and a gyro. I think the entire 08 season was a testament to this.
so just a simple formula like
X pos = X0 + (((Left encoder + Right encoder)* wheel radius) /2 ) * cos(Gyro Theta)
Y pos = Y0 + (((Left encoder + Right encoder)* wheel radius) /2 ) * sin(Gyro Theta)
This year, 971 integrated the ground speed sensors to get our position. We couldn’t measure sideways sliding, though one more sensor and vex omni wheel would have dealt with that. Our programmer then wrote a PD loop to get the robot to follow a spline.
One of the most important lessons he learned during this process is that it helps a lot to have plots on your computer showing what you wanted, and what the bot did. He used the dashboard port, a piece of ruby code, and Gnuplot to get the data back and display it.
An easy way to go to a position on the field is to write a PD loop that controls the steering to get the angle right, and apply forwards power to get to the point. If you care if you stop there, you’ll then need some sort of control for the throttle as well. A simple way to follow a path is to string these points together and move on to the next one when you get close to the first one. This all assumes you have encoders and/or gyros to measure where you are.
Our best results have been from gyros, ecoders, PD loops and PID.
Once StanGPS was released people learned A LOT about how to write a good autonomous.
Could an accelerometer account for the deflection?
and how was the spline calculated?
One of the most important lessons he learned during this process is that it helps a lot to have plots on your computer showing what you wanted, and what the bot did. He used the dashboard port, a piece of ruby code, and Gnuplot to get the data back and display it.
That sounds like an application for a touchscreen dashboard 
An easy way to go to a position on the field is to write a PD loop that controls the steering to get the angle right, and apply forwards power to get to the point. If you care if you stop there, you’ll then need some sort of control for the throttle as well. A simple way to follow a path is to string these points together and move on to the next one when you get close to the first one. This all assumes you have encoders and/or gyros to measure where you are.
The steering seems to me the hardest part. What variables did the PD loop control ?
Crab steering should be no harder than any other steering and perhaps more easy. You need to know how far the wheels have driven (preferably more than one to increase accuracy), which direction the steering is turned and where you want the robot to be at various intervals. The big variables occur when you run into objects on the field like goals and other robots. With other steering methods you have to compensate for turning radius when moving in other than a straight line.
As far as travel, we have used wheel encoders, either scratch built optical or off the shelf rotational encoders. The data is then used in calculating the distance traveled by incorporating wheel circumference and rotations. Steering is a simple pot but you should have used that already for feedback control with manual steering. A gyro will help you to maintain preset way points and can help in collision correction. We used one to great effect during 2003 when climbing the ramp in auto.
That’s a pretty bold claim, as well has a VERY inaccurate one. A lot of teams have been doing skid steer navigation since autonomous began in 2003.
Here’s the best advice I can give you: do NOT put your encoders on your drive wheels - put them on non-driven “dummy” wheels that do nothing but measure distance. By using non-driven wheels, all of the skidding and associated wheel slippage do not influence the measured distance.
I’m pretty sure '08 bots who could run around the field multiple times used more than just gyros and encoders (…like human IR control…).
That said, in the quadrotor world there’s only 1 way to go: Butterworth-filtered accelerometers and redundant gyros that failover. The filters help to reduce noise at the circuit level. The gyros are on a reset circuit that resets their power every N seconds to reduce slop (and there’s another issue…can’t remember the name…where over time their readings become more offset). While one is resetting, the other has valid data. I’m not the circuit genius behind this … I’m the one who integrated the architecture together to make everything work together as 1 system
In the FRC world, we’ve used encoders and gyros with success (2007) and failure (2008). Encoders give a # of ticks per rotation, and that can translate into inches per tick. If you poll the gyro every N milliseconds, you can use some trig (using lookup tables on those systems) to calculate your position with pretty good accuracy. Accelerometers have generally been too noisy to be accurate for planar field positioning in our experience. This year we will probably use filters with them for angular arm positioning (shh, don’t tell my team that … ).
This is a very interesting idea, but does it really work? I always thought that the gyros (at least the ones we use) had to have a quiet “settling” period during initialization, otherwise their readings would be bogus. What am I missing?
P.S. - I’m also impressed at the amount of truly useful information that has appeared in this thread in just a couple of hours, as compared to some of the other ones that go on for days and weeks, and provide nothing of value (<cough> game hints </cough>) 
You need a quiet settling period during gyro calibration, but if you already know the calibration data they can be power cycled pretty quickly.
How would turning off a gyro ever help, though? Integrated angular position from a gyro drifts over time, and power cycling will reset this drift, but then the gyro is “starting” at an unknown orientation.
(Example) GyroA power resets. It’s drift is reset to zero, yet all the while during GyroA’s reset, GyroB provides (supposedly) accurate data. Software keeps track of which gyro is active and what the overall relative heading is since system start, and it also keeps track of failover status (e.g. if it’s unable to read from the second gyro it doesn’t reset the first…). For autonomous hovering purposes, resetting the gyros is necessary so that the quadrotor stays in the air autonomously for long periods of time, yet all they control for hovering’s purpose is yaw rate. We think of yaw rate as a local discreet-time issue rather than something to track from system startup. So tracking heading for that purpose adds unnecessary overhead to the hovering routines.
We will only need to keep track of true heading if we take it another step further and do autonomous travel. But there are many hurdles to get over first, like not crashing when tilting forward to go in a straight line …:ahh:. We’ll probably put a compass on board at some point too, but as a 3rd heading sensor.
I also wanted to note that it doesn’t really make sense to power cycle gyros in FRC unless your robot is trying to spin in place for several rotations and stop at an exact angle. The quadrotor only does it because with environmental effects (e.g. turbulence) on such a lightweight system, the thing winds up spinning 720 degrees over a 10 minute period sometimes.
What?
In 2007, we were one of the most consistent teams in the country scoring the tubes on the rack-n-roll rack. We were consistent to about 1/4 inch true position through the use of a gyro, two encoders, and knowing the center of turning of the robot. We were skid steer.
In 2008, we consistently did 4 lines unless we were blocked by another bot, and we knew exactly where the robot was going to turn and end up. Using skid steer, a gyro, and two encoders.
In 2009, we had the robot set up to accept an angle and a distance from two dials on the board so we could put it anywhere we needed it (barring collisions of course). We didn’t account for side skid just for simplicity’s sake. We used a gyro and two encoders.
Skid steer is extremely easy to navigate with by doing constant angle / distance calulcations at a decent rate and averaging them between the sides. In fact, functionally, the math is no different that the trig you do with the swerve.
On what do you base the idea that not many people with skids have done much with navigation?
All I’m going to say on the 6WD skid navigation is:
1024’s 2008 automode.
(I can also name several other teams, including my own, but choose not to.)