Go to Post There is nothing that says 'gracious professionalism' like making brunch for your opponents. - Monochron [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 17-01-2006, 21:43
magical hands magical hands is offline
Jigar Patel
AKA: Jigar Patel
FRC #2185 (Etobicoke CI)
Team Role: Mentor
 
Join Date: Dec 2003
Rookie Year: 2004
Location: TORONTO
Posts: 93
magical hands is on a distinguished road
Lightbulb Pin Point Robot's Position (GPS)

I just want to know, how can i create a system where my robot can keep track of its position (x,y) and for e.g. the target it at (3,4) than all i have to say go to (3,4). Is it possible to do something like this with the sensor's available if so can you please give a detailed procedure. Thank You
  #2   Spotlight this post!  
Unread 17-01-2006, 21:47
Jared Russell's Avatar
Jared Russell Jared Russell is offline
Taking a year (mostly) off
FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy)
Team Role: Engineer
 
Join Date: Nov 2002
Rookie Year: 2001
Location: San Francisco, CA
Posts: 3,082
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
Re: Pin Point Robot's Position (GPS)

Yes, it's possible and can be done. Team 341 did it last year.

You can use encoder counts to measure distance travelled, and a gyro reading to determine heading.

Your X/Y positions would be incremented each cycle by distance_travelled_this_cycle * sin(heading) and distance_travelled_this_cycle * cos(heading) (or reverse, depending on how you define X and Y; beware that sin() and cos() don't exist...you have to write them or find someone who did [hint: whitepapers on delphi]).

To go to a position X/Y, simply compare each component with your current position, determine what heading to turn to and how far to drive, and do it.

www.kevin.org/frc has good examples.
  #3   Spotlight this post!  
Unread 17-01-2006, 23:13
magical hands magical hands is offline
Jigar Patel
AKA: Jigar Patel
FRC #2185 (Etobicoke CI)
Team Role: Mentor
 
Join Date: Dec 2003
Rookie Year: 2004
Location: TORONTO
Posts: 93
magical hands is on a distinguished road
Thumbs up Re: Pin Point Robot's Position (GPS)

Anyone has anyother ideas? which they have tried in previous years and worked successfully.
  #4   Spotlight this post!  
Unread 17-01-2006, 23:30
NextPerception NextPerception is offline
Sleep-Deprived
AKA: Matt
FRC #0437 (Richardson Robotics)
Team Role: Mentor
 
Join Date: Sep 2004
Rookie Year: 2005
Location: Richardson, TX
Posts: 69
NextPerception has a spectacular aura aboutNextPerception has a spectacular aura aboutNextPerception has a spectacular aura about
Send a message via AIM to NextPerception
Re: Pin Point Robot's Position (GPS)

has anyone ever used anything that uses 4 or mabye even 6 distance sensors (probably ultrasonic) to find distances from the walls and find position that way?
  #5   Spotlight this post!  
Unread 17-01-2006, 23:35
Donut Donut is offline
The Arizona Mentor
AKA: Andrew
FRC #2662 (RoboKrew)
Team Role: Engineer
 
Join Date: Mar 2005
Rookie Year: 2004
Location: Goodyear, AZ
Posts: 1,313
Donut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond reputeDonut has a reputation beyond repute
Re: Pin Point Robot's Position (GPS)

Similar to the encoder/gyro idea, you could keep track of things using the acceleromotor and a gyro.

Our team has never really gotten things working in the past for positioning. Doesn't help when you spend too much time on the camera the previous year.
  #6   Spotlight this post!  
Unread 17-01-2006, 23:41
Goldeye Goldeye is offline
Registered User
AKA: Josh Hecht
FRC #0694 (Stuypulse)
Team Role: College Student
 
Join Date: Jan 2005
Rookie Year: 2005
Location: New York
Posts: 145
Goldeye has a spectacular aura aboutGoldeye has a spectacular aura aboutGoldeye has a spectacular aura about
Send a message via AIM to Goldeye
Re: Pin Point Robot's Position (GPS)

Quote:
Originally Posted by Abwehr
beware that sin() and cos() don't exist...you have to write them or find someone who did [hint: whitepapers on delphi]).
Actually, they do exist in the mcc18 libraries nowadays. They're not ideal if you're running low on time though.

My confusion is: How do you calculate distance_traveled_this_cycle if the wheels are turning at different rates?
Even worse, how do you do it with center-lowered 6 wheel drive?
__________________
Team 694

2005 Championship - Galileo Semifinalist
2005 New York - Regional Chairmans Award
2005 New York - Semifinalist (Thanks 1257,1340)
  #7   Spotlight this post!  
Unread 17-01-2006, 23:46
Dillon Compton Dillon Compton is offline
Jack-Of-All-Trades
FRC #1391 (Metal Moose)
Team Role: Mentor
 
Join Date: Jan 2005
Rookie Year: 2004
Location: Malvern, PA
Posts: 186
Dillon Compton has much to be proud ofDillon Compton has much to be proud ofDillon Compton has much to be proud ofDillon Compton has much to be proud ofDillon Compton has much to be proud ofDillon Compton has much to be proud ofDillon Compton has much to be proud ofDillon Compton has much to be proud of
Send a message via AIM to Dillon Compton
Re: Pin Point Robot's Position (GPS)

Quote:
Originally Posted by Goldeye
Actually, they do exist in the mcc18 libraries nowadays. They're not ideal if you're running low on time though.

My confusion is: How do you calculate distance_traveled_this_cycle if the wheels are turning at different rates?
Even worse, how do you do it with center-lowered 6 wheel drive?
Could you not simply measure the encoder rates on the lowered center wheels? Since those will always be in contact with the floor, a read off of them should be fairly accurate.


No idea about an answer to the different turning rates...not planning on using a complex positioning system this year.
__________________
www.metalmoose.com
  #8   Spotlight this post!  
Unread 18-01-2006, 00:30
Tom Bottiglieri Tom Bottiglieri is offline
Registered User
FRC #0254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Jan 2004
Rookie Year: 2003
Location: San Francisco, CA
Posts: 3,188
Tom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond reputeTom Bottiglieri has a reputation beyond repute
Re: Pin Point Robot's Position (GPS)

Quote:
Originally Posted by Goldeye

My confusion is: How do you calculate distance_traveled_this_cycle if the wheels are turning at different rates?
Every time the example navigation program loops, it is creating a vector in component form to express the position of the robot in relative to its position the in the previous loop of the program. Therefore, your position on the field at any particular point in time is the summation of all the relative position vectors created up until that particular point in time. Most teams just keep a running total of the X and Y components and throw away the vector data. Keep in mind, it is perfectly possible to keep track of all of those relative position vectors, then create a graph using a parametric equation (with X and Y as parameters of Time) to study later on how the robot moved during the match.

Back to the question at hand... To find the magnitude of distance traveled simply average the left and right side encoder counts. This holds true because this code is really tracking the motion of the center of mass of the robot, not the entire robot. As an example, think of 2 people running side by side, each holding the end of a 10 ft long stick. In the middle of the stick is a big red dot. When the 2 people run at the same speed, the red spot stays directly in between them. When one starts to slow down, the red dot still stay exactly in between the 2 men, but the angle the stick is at has now changed. The red dot signifies the Center of the robot, and how its motion is affected by linear forces on either side of it.

Here is an example of basic position calculator.
Code:
//Using Accelerometer....

//position is the total linear distance moved since start up
velocity += GetAcceleration();
position += velocity;
Code:
//Using Encoders...


//position is the total linear distance moved since start up

position = ( GetLeftEncoderCount() - GetRightEncoderCount() ) / 2 ;
Now throw what your total travelled distance is into this:
Code:
distance=position-distance; //find distance travelled since last loop
heading = GetGyroAngle(); //get instantaneous heading


//accumulate X components of relative position vectors
X_coord += distance * cos(heading); 

//accumulate Y components of relative position vectors
Y_coord += distance * sin(heading);
Just make sure something like that loops very fast. (The IFI default code loop should be fast enough)

So, I've told you how to find where you are. The balls in your court to find where you want to be and how to get there.

Good Luck!

EDIT: If none of this is making sense to you, check this out!

Last edited by Tom Bottiglieri : 18-01-2006 at 00:40.
  #9   Spotlight this post!  
Unread 18-01-2006, 10:11
KenWittlief KenWittlief is offline
.
no team
Team Role: Engineer
 
Join Date: Mar 2003
Location: Rochester, NY
Posts: 4,213
KenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond repute
Re: Pin Point Robot's Position (GPS)

There are many ways to keep track of your position on the field.

The simple way is to measure how fast your robot moves and turns (feet per second and degrees per second for turning) and calculate where your robot is based on where you started, and keeping a running summation of all the commands (pwm outputs) you have sent to your motors, and the amount of time that has passed (SW loops).

This is easy, and its not very accurate (engineering tradeoff). Several teams used this method in the 'stack attack' game to hit the center of the wall as fast as possible in auton mode. In fact, the fastest robots used this method (ie: go forward for 1 second, turn left for 0.5S, go forward for 3 seconds...). If you are trying to hit a wall of boxes 12 feet wide you dont need mm accuracy.

Putting something on one of your wheels that counts revolutions is a more accurate way to measure distance travelled, as long as that wheel stays in contact with the floor and does not spin. Measuring the number of turns of wheels on both sides can be used to measure which way you are pointing.

You could also use the camera sensor to look for the beacon on the field, and use that to triangulate your position, esp if you can see both of them and measure your distance to one or both.

There are magnetic sensors you can get that allow you to measure the direction of the earth magnetic field. You have to place them on your bot where there is no steel or iron nearby, but they work pretty well. then you always know which way your bot is pointing, and these can be accurate to 1°.

accelerometers can be integrated to measure velocity (V=AT), and velocity can be integrated to measure distance (D=VT). This will work no matter what your wheels are doing (slipping, spinning, being pushed backwards), but its more complex and needs to be calibrated to get the best accuracy.

another way to figure out position is to sense the walls and railings and other objects on the playfield. If you keep a running estimate of where you think the robot is, you should know when to expect to run into a field boundary (instead of another robot), and you can use that information to increase the accuracy of your position.

you can get creative with the boundary sensors - simple: use contact switches that close when you bump into something, or more complex, like using an ultrasonic range finder to measure the distance to a boundary, or rotate it like radar to see whats all around your.

My favorite sensor is the yaw rate sensor. Its a solid state device that tells you how fast your robot is turning. This is very usefull for closed-loop steering control (another subject) but you can also integrate the yaw rate to get a compass (heading) reading.

Unfortunately, the best navigation system ever devised, GPS has two problems: 1. the accuracy is excellent for sailing across a lake or ocean, but +/- 2 or 3 feet is not that good for playing this game on the field, and 2. the signals are blocked by the roof of the arena :c(
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Rotary Position Sensors DonRotolo Electrical 10 21-11-2005 15:03
FYI: FIRST Robots at the NYC Hall of Science Rich Wong General Forum 9 11-07-2002 10:52
Game Idea archiver 2000 3 23-06-2002 23:27
My 02c nick reynolds General Forum 16 16-11-2001 19:27


All times are GMT -5. The time now is 01:55.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi