GPS with VEX

[whytheheckme]

So.... what are the odds of IFI issuing some kind of field positioning system (weather its a beacon in the center of the field, or some kind of magic sensors under the carpet) and the devices to use in our bots?

I think that while the lights are a challenge, they simply aren't accurate enough. Imagine how much more complicated the game could be if you could reliably know where your robot is at all times.

Jacob

[AdamHeard]

Originally Posted by whytheheckme

So.... what are the odds of IFI issuing some kind of field positioning system (weather its a beacon in the center of the field, or some kind of magic sensors under the carpet) and the devices to use in our bots?

I think that while the lights are a challenge, they simply aren't accurate enough. Imagine how much more complicated the game could be if you could reliably know where your robot is at all times.

Jacob

In 2004 there were two infrared beacons that could be used.... From what I remember, most teams didn't because dead reckoning, line following & gyro and/or encoders all worked better. Anyone with more experience care to clarify?

How is the light not accurate enough though? Between this year and last year we had distance down to less than a foot of accuracy, and the angle wasn't too bad either (I don't remember exactly). I can't imagine any field based navigation being any more accurate.
EDIT: didn't realize you were talking about the entire field, not just an object...... In that case, I can't think of any current system that is realistic for FIRST that will work here....

[whytheheckme]

I was thinking about a radio transmission system that works like a local GPS, where something above the field is transmitting a signal, and devices on the robots can use the exact timing of that signal to determine exactly where it is (think thats how GPS works, but i could be completely wrong.) Something radio, wireless, free of looking for visual things (or infrared, basically free of line of sight stuff.) More of an actual location instead of an estimated calculated location. Think of the possibilities for a game and the autonomy of a game if you had this data reliably!

(I just realized that I'm talking about FRC here, and the thread is titled VEX. Sorry for the confusion.)

Jacob

[dtengineering]

Here's a couple ideas to kick around... rather than using a radio signal, why not an ultrasonic signal? Since sound travels more slowly, it is a bit easier to measure the timing differences accurately. If there were four transmitters (one in each corner of the field) and each fired a slightly different length of noise at a pre-defined interval, it may be possible for the robot to determine its position with a fair bit of precision... barring reflections and other nastiness.

Or take a couple of CMUcams (or perhaps something with a bit higher resolution) and point them up at the ceiling... use some of the fixed field lighting as "stars" for an "astonomical" positioning system. It would require a fair bit of effort to deal with blinking and moving lights and such, let alone lens flares and other real-world weirdness, but in the happy, happy world of pure theory... it might work.

But anyways, that is off the point of the thread... my Garmin Etrex Legend has an RS-232 port and should be able to "talk" to a VEX. Although I've only used it for downloading track logs and uploading maps, I believe it IS capable of doing a real-time GPS location feed. The downside is that it has an older chipset... I've found the new SirfStar III devices to have much faster acquisition times and better reception. Some of them even work indoors.

There are also neat tricks for improving GPS accuracy. One of the less expen sive ones... although not a particularly useful one for real-time robotics applications... is to leave your GPS sitting in one place for an hour or so and record all the positional readings (they will fluctuate a bit). Then you compare them to the readings of a nearby receiver at a known location. Since some of the errors in your signal are caused by random atmospheric fluctuations, and since a nearby receiver will have similar fluctuations, then the errors between the two sets of readings should be similar. Since the reference receiver is at a known location, it will be possible to determine a known error, and modify the results for the mobile GPS unit. I suppose this technique could be modified to offer real-time benefits, but I don't know if I'd want to do that on a VEX platform.

Jason

[Gdeaver]

There are six fixed position 900 mhz transmitters at the operator stations. There are ways to resolve your position from these sources, however it is not easy. In the past our team has used parts of the field as way points. This proved very easy to do in stack attack and raising the bar. First put lines on the field. They where easy to detect with the Banner sensors. We drove toward the line using dead reconing, stopped when the line was detected, timed turn and go on. It was good enough to nock the ball off in raising the bar. We now have a large inventory of available senors. Each year evaluate the field for waypoints objects.

[Alan Anderson]

Originally Posted by dtengineering

Or take a couple of CMUcams (or perhaps something with a bit higher resolution) and point them up at the ceiling... use some of the fixed field lighting as "stars" for an "astonomical" positioning system. It would require a fair bit of effort to deal with blinking and moving lights and such, let alone lens flares and other real-world weirdness, but in the happy, happy world of pure theory... it might work.

http://www.evolution.com/products/northstar/works.masn

http://www.memagazine.org/backissues.../measurng.html

Originally Posted by Gdeaver

There are six fixed position 900 mhz transmitters at the operator stations...

For the past couple of years, the transmitters are actually all on a common "tower" at one side of the field.

[basicxman]

Originally Posted by Kingofl337

Unfortunately IFI didn't bring out I2C in the VEX controller other then it is used by the two PICs
to communicate with each other.

doesnt matter, you can use standard I/O pins and make subroutines for i2c, look at this topic in the VexForum (www.vexforum.com), i've already posted how, after FIRST i'll even make the subroutines

[tseres]

Originally Posted by dtengineering

There are also neat tricks for improving GPS accuracy. One of the less expen sive ones... although not a particularly useful one for real-time robotics applications... is to leave your GPS sitting in one place for an hour or so and record all the positional readings (they will fluctuate a bit). Then you compare them to the readings of a nearby receiver at a known location. Since some of the errors in your signal are caused by random atmospheric fluctuations, and since a nearby receiver will have similar fluctuations, then the errors between the two sets of readings should be similar. Since the reference receiver is at a known location, it will be possible to determine a known error, and modify the results for the mobile GPS unit. I suppose this technique could be modified to offer real-time benefits, but I don't know if I'd want to do that on a VEX platform.

Jason

WAAS (wide area augmentation system) does this for you on relatively new GPS receivers. it takes what the satellites are giving and compares it to a known location (WAAS station)

[dasmoenator]

Thanks for the great info guys. I'll definitely be looking into WPILib. From what I hear its what I need. My project is more of an outdoors thing so I'm not too worried about GPS signal having problems with walls. I'm still somewhat torn between the parallax GPS and the eTrex. I'll probably end up with the parallax as it was mainly made for this purpose and the fact that I will be able to integrate it into my bot quicker and easier is a major plus. I'll post back with some results after I try it all out.

[tseres]

ya, the parallax is cool, but i'd personally go with the etrex. i have a Garmin RINO and although it's a different model, Garmin GPS's will output the same signal. the pinout guide in in the gps manual. it outputs he same as the others. also, if you ever wanted to, you could temporarily take the gps off and do something like geocaching....

[Peter Randall]

We are trying to add a Parallax GPS to a standard FRC controller using Easy C. We can see that we have established a fix via the idiot light on the GPS, but we are having trouble writing and reading the TTL serial port. Can anyone provide words of wisdom on how to write text strings to the serial port e.g "!GPS05" and how to read the serial response.

Thanks

[ay2b]

Originally Posted by Peter Randall

We are trying to add a Parallax GPS to a standard FRC controller using Easy C. We can see that we have established a fix via the idiot light on the GPS, but we are having trouble writing and reading the TTL serial port. Can anyone provide words of wisdom on how to write text strings to the serial port e.g "!GPS05" and how to read the serial response.

There are several different serial port libraries out there, so look through the documentation/header files for the one you are using. Generally you can write to the TTL serial port using printf or fprintf. Some libraries present the 2nd port as "stderr". Others will have a global variable you change to set which port the stdout (i.e. normal printf) goes to.

Is the TTL serial port enabled? The header file for your serial library might have some #define statement you'll need to change.

What baud rate are you using? Again, hopefully you can set this via a #define in the header file. What baud rate does your GPS expect?

If you're up for it, you might try connecting your TTL serial port on the controller to the serial port on your computer, so you can more easily see whether or not anything is being sent out. In order to do this, however, you will need a "ttl converter chip" (I don't think that's quite the right name for it, but I'm drawing a blank on the proper name). You could potentially use the one provided for use with the CMUCam. This will require a little extra wiring on your part to make it work, but it could be done.

I know these answers are vague, but hopefully they help a little. Keep us all up to date on your progress.

[Peter Randall]

We are using Easy C which uses the WPI library. Since it can run the CMU camera on the TTL serial port, it clearly has the functions we require, unfortunately, I can't figure from the WPI documentation what the syntax should be for reading and writing to the serial port. The Parallax runs at 4800 baud, which we set (I think) via a command in our Init function
The issue is that the Prallax need us to send it a command string "!GPS0x05" and then read the reply which is the latitude in decimal format. I am trying to read it into a Long variable, but when I print the value, all I get is -1. We can see from the GPS that it has acquired a fix. I am befuddled

PGR

[Kingofl337]

E-mail Brad Miller he can help you out. YGPM

[dasmoenator]

Originally Posted by Peter Randall

We are using Easy C which uses the WPI library. Since it can run the CMU camera on the TTL serial port, it clearly has the functions we require, unfortunately, I can't figure from the WPI documentation what the syntax should be for reading and writing to the serial port. The Parallax runs at 4800 baud, which we set (I think) via a command in our Init function
The issue is that the Prallax need us to send it a command string "!GPS0x05" and then read the reply which is the latitude in decimal format. I am trying to read it into a Long variable, but when I print the value, all I get is -1. We can see from the GPS that it has acquired a fix. I am befuddled

PGR

Please post back or let me know if you find a way to get it to work. I'm very interested in getting something like this off the ground and working.