Tank Steering
 

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?

Re: Tank Steering
 

we have switches on the robot to flip to indicate what positition it is at. our programers found it easier to do that

Re: Tank Steering
 

so, then its just experimented values?

Re: Tank Steering
 

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/...s/102_2390.jpg

Re: Tank Steering
 

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

Re: Tank Steering
 

almost requires some type of position/orientation feedback, eh?

Skids are difficult to predict.

Re: Tank Steering
 

A combination Gyro, encoder, + inertial mesurements?

Re: Tank Steering
 

Pretty solid results have been achieved with just encoders and a gyro. I think the entire 08 season was a testament to this.

Re: Tank Steering
 

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)

Re: Tank Steering
 

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.

Re: Tank Steering
 

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.

Re: Tank Steering
 

Could an accelerometer account for the deflection?

and how was the spline calculated?

That sounds like an application for a touchscreen dashboard :)

The steering seems to me the hardest part. What variables did the PD loop control ?

Re: Tank Steering
 

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.

Re: Tank Steering
 

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.

Re: Tank Steering
 

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 ... ).

Re: Tank Steering
 

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>) ;)

Re: Tank Steering
 

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.

Re: Tank Steering
 

(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.

Re: Tank Steering
 

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?

Re: Tank Steering
 

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.)

Re: Tank Steering
 

The teams I'm thinking of with 4+ line autons using encoders and gyros either didn't use the remote, or only used it to change "paths"; the encoders and gyros themselves still had to be accurate.

I stand by my statement, encoders (on drive wheels) and gyro alone are sufficient for accurate navigation even at high speeds.

As Chris said, separate dummy wheels would be superior, but teams did just fine with out them in 08.

Re: Tank Steering
 

We might have been able to use an accelerometer, but we heard enough stories about people trying to use one for traction control and determining that it wasn't working well that we didn't bother to try. It also was at the point of diminishing returns, since the bot didn't skid sideways very much anyways.

I don't recall the equation, but you can spend some time on the wikipedia page or the internet in general and get a parametric equation for the cubic spline.

turn = error * k1 + (error - lasterror) * K2
left = 1.0 + turn
right = 1.0 - turn

Like always, the hard part is tweaking the constants.

Re: Tank Steering
 

So, just correcting the skid value from an absolute sensor (ex Ultrasonic sensor to a known wall) is all that is required to have accurate readings?

Also on carpet, there isnt as much skidding, so it is not as important then?


Ok, then thats not too hard. Yay math!

and your error has what value? current heading - target heading, or something similar?

Re: Tank Steering
 

As with all engineering, you need to figure out how much is good enough, and how to deal with things not being exactly as planned. Say someone gets between the wall and your sensor? Say someone crashes into your side? Do you care? We chose to just use the ground speed encoders and let someone crashing into our side make us loose track of our real position. For the most part, it worked fine, and it's debatable whether having that information when someone did hit us would have allowed us to do much more. Assuming you tried to add in an Ultrasonic sensor, that would only let you narrow down the potential error in one direction. I'd say just integrate the ground speed encoders, or the ones on your drive train, and use that until you have determined that that isn't enough. Detecting position and using it are isolated things that you can improve independently.

If you are trying to point the robot in a direction in order to go in that direction, the error is some measurement that is fairly linear and will be 0 when you are pointed in the correct direction. The heading error was what I used when trying to go to a way point.

Re: Tank Steering
 

Considering that we will probably only have 15 seconds again, encoder errors shouldn't compound too quickly. Only if we go longer then that, a recalibration may be necessary

so you took your spline and split it into discrete points? then calculated the angle to the next point, and arced to the point, or did you turn, then drive straight?

Re: Tank Steering
 

Splitting the spline up into points is one way to do it. Create a list of fairly evenly spaced points, and go to the next point on the list when you get within a certain distance of the last point. I think our programmer wrote some equation that did it without points, but I'm fuzzy on that detail of the code.

You don't have to worry about what it does between the points. Just apply forwards power, and PID your heading. The robot can't make sharp turns easily, so it'll take a bit to make the turn and that will smooth the turn out. You can also just up the number of points. This is the same thing as approximating a circle as a many sided polygon. The more sides, the better the approximation.