![]() |
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
Quote:
|
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
Quote:
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
Quote:
Skids are difficult to predict. |
Re: Tank Steering
Quote:
|
Re: Tank Steering
Quote:
|
Re: Tank Steering
Quote:
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
Quote:
Once StanGPS was released people learned A LOT about how to write a good autonomous. |
Re: Tank Steering
Quote:
and how was the spline calculated? Quote:
Quote:
|
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
Quote:
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 ... ). |
| All times are GMT -5. The time now is 01:56. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi