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.