GPS

[chuckmerja]

I’m an “old” (slow learner) mentor of team 1696 in Montana. We have just finished our FIRST regional competition for the 2008 season, and didn’t make it to Atlanta. We have a lot of open space here in Montana and I am a farmer who uses GPS in my farming operations. We have been working on making one of our old FIRST robots an outdoor machine, and I’d really like to try to incorporate some sort of gps steering onto this device as a way to keep kids interested in technology in the “off season”.

So what I’m looking for is a – pardon my lack of good jargon use – library that contains a serial (maybe Mr Kevin Watson serial stuff would work??) NMEA string parser, and maybe pull in some math libraries we’d need.

The way GPS is used in agriculture is for guidance and input for assisted steering. There are many patterns available, but the main two I use is a straight “AB” line and a straight “A+” line. The AB line is developed by physically driving the unit to the first place (point A) and storing that location, then driving to a second place (point B) and storing that location. We then have an electronic line. We have already dialed in a “Width” of our implement (distance between parallel lines) and thus we create a whole series of parallel lines that either we can follow OR cooler yet, that the machine can follow using assisted steering. I’d like to have our robot do this parallel swathing. (Humans have to turn the unit around at the ends of swaths and get it close to the next parallel line for the guidance to work on big machines, so that could be necessary here too).

The straight “A+” is done by setting the first point (A) and a heading, thus drawing a straight line from which parallels are drawn.

The reason I opened with “old” and slow learner is because I am learning EasyC with the kids, and I think we could implement a GPS guidance system if we could find some kind, smart person to put together a library for us, but I just don’t think we have the ability to get that library pulled together.

Might someone be willing to help put a GPS library together???

I’ve seen a few posts on Chief Delphi about gps, most asking for help. I think that once a serial com, parser and maybe a couple simple functions like drive to an input point or drive to point A, click button X, drive to point B, click button X, then create parallel lines happened, the community would be off and running.

BTW – the accuracies would mostly be a function of the GPS unit used. There are many GPS units out there that put out NMEA 0183 strings, and some of them are pretty accurate – by using WAAS, some other satellite/base correction like OmniStar, or even RTK. The point is that they all use NMEA 0183, so the accuracy of our AB lines would just be a function of the GPS.

Maybe this is already done, and just needs to be dragged into EasyC so we can use it. If so, pls point me, THANKS

[Dr.Bot]

You should research a project called robo-magellan. This is a contest where
robots use GPS to locat an orange trraffic cone based on GPS co-ordinates.

Most GPS hand held units come with a serial or USB port now a days. Might be hard to interface with an IFF controller, but possiible even with a VEX.

[OScubed]

You should research a project called robo-magellan. This is a contest where
robots use GPS to locat an orange trraffic cone based on GPS co-ordinates.

Most GPS hand held units come with a serial or USB port now a days. Might be hard to interface with an IFF controller, but possiible even with a VEX.

I have not done this however, my smartphone (and most Windows Mobile OS hand held devices with either USB or Bluetooth) can interface with something like the PHAROS GPS, and you can read the NMEA streams as COM devices. MS has GPS built into the latest version of Windows Mobile. Since we're not limited to the hardware that FIRST uses for this particular challenge you could potentially use a handheld device (probably be able to get one cheap on EBay) as a smart controller.

Microsoft has a free version of it's software for developing for Windows Mobile (Visual Studio 2008 lite) and I believe they may even have libraries for creating apps that at least interface with COM ports, if not also with the GPS itself. Then the only challenge would be outputting something that the VEX or other IFF controller can read for signalling.

[OScubed]

Here's a whole passel of threads on using Windows Mobile with GPS:

http://search.msdn.microsoft.com/Default.aspx?query=windows+mobile+gps&brand=msdn&locale=en-us&refinement=00&lang=en-us

[Qbranch]

Why do you need windows? An 8-bit (such as the 18F8722 found in the FRC controller) device is completely capable of handling a GPS device (most have baud rates around 2400 to 9600), multiple supplementary sensors for between-gps-sample navigation (GPS usually updates at or around ~1Hz) and some pretty fancy navigation stuff no problem.

No bluetooth or USB required. The USB pharos module listed in a previous post is, at it's heart, an RS-232 device. There's just an adapter on it's output. If I remember right, pharos GPS devices are 2400 8-N-1 as are many other GPS devices.

It also seems Spark Fun has a new GPS reciever that's pretty gosh darn cool... it claims a 5Hz update, the fastest I've ever seen. (link to page (http://www.sparkfun.com/commerce/product_info.php?products_id=8266))

As far as the serial data goes, using Kevin's serial driver would work fine, but it wouldn't be too difficult to write your own either. You'd have to write the actual parser yourself, but NMEA isn't that confusing to look at and doesn't take long to figure out. It has no checksum (if I remember right) so there isn't a whole lot of logic needed to securely recieve data from the sensor.

This sounds like a GREAT project... I wish I could help! :(

By the way... if you don't mind my asking... what does this thing look like? Big knobby tires? What kind of implement are you going to use? If you had a big fenced in area (for safety) it would be fun to take a 12v weed wacker and mount it on your machine so it could cut grass.

Awesome! Good luck!

-q

EDIT/ps: As one of your supplementary sensors, I suggest using a really good gyro. The analog devices ones are really good, but can drift with temperature and off-planar rotation (such as if your machine was on a banked hill tilling earth or something). You might consider using a Gyration 5 DOF motion sensing part (http://www.gyration.com/tt_MotionSensing.aspx).

[chuckmerja]

Well - Re uses -
1 - We use airplanes and terrestrial scanning units. I'd like to mount the terrestrial units on this bot for late season scanning (NDVI) relates to yield and protein of my wheat.
2 - The weed whacker has occurred to us for weeds that have grown above crop.
3 - Also a wick-wiper for same use.
4 - Gopher (Richardson ground squirrel) control - ??
5 - Large lawn/yard mowing - maybe a fundraiser for our team. Roomba with a lawn mower and an E STOP!! :o))
6 - Skateboard park fun.
7 - Outside hill climb fun.
8 - Your suggestions...

So those are the thoughts.

I already have about a dozen GPS units from 1 hz handheld units to 5 and maybe this spring, 50 hz units. All have serial out, and I deal with that all the time with CE units as well as Windoze based laptops.

Maybe I'm missing something, but, I am not seeing how a CE machine might interface with the IFI controller to do the controlling I need.

What I need and want is the bridge from this GPS technology to the IFI controllers that the kids are familiar with. I just don't have the capability, and now the time (inversely proportional to capability) to dig deep enough to make this done. I'm sure that there are libraries out there, I just need some help finding them and identifying that they are what I'm looking for. As an example, might this be a parser I could get shoved into EASY C?? -

http://www.dmh2000.com/nmea/nmeap.shtml

and TUT for above - http://www.dmh2000.com/nmea/tutorial.html

If you are interested in the devices that I use on my big tractors and sprayers etc - check out the EZSteer - I have a couple of them, plus Trimble AG 132, Garmin ?16? and more -

http://www.agleader.com/products.php?Product=guidance

Thanks, C

[lynca]

So what I’m looking for is a – pardon my lack of good jargon use – library that contains a serial (maybe Mr Kevin Watson serial stuff would work??) NMEA string parser, and maybe pull in some math libraries we’d need.

Might someone be willing to help put a GPS library together???

Maybe this is already done, and just needs to be dragged into EasyC so we can use it. If so, pls point me, THANKS

I've ported the basics of AVRlib to an ARM and a freescale microcontroller. It should be fairly straightforward to get the PIC working as well. This process will take time but once you understand how serial buffers work in the PIC it should be no problem.
nmea.c (http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/docs/html/nmea_8h-source.html)

gps.c (http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/docs/html/gps_8h-source.html)

[tseres]

might i suggest a Garmin handheld reciever? i've been looking into GPS with a PIC, and my Garmin Rino 120 has NMEA output, but even easier, it has a text output that gives the UTC time, coordinates, elevaton, change in elevation, and East-West and North-South velocities. much easier than NMEA protocol, IMHO.

[Qbranch]

might i suggest a Garmin handheld reciever? i've been looking into GPS with a PIC, and my Garmin Rino 120 has NMEA output, but even easier, it has a text output that gives the UTC time, coordinates, elevaton, change in elevation, and East-West and North-South velocities. much easier than NMEA protocol, IMHO.

NMEA is a text (ascii) language. If you're just trying to get positions, many GPS's stream sentences by default that include coordinate information or by selecting this mode of operation from a menu (example: Magellan Meridian/Meridian Color).

Even if you do start going interactive with your reciever, it isn't as bad as it might look. In the end, its just like learning dos, only the commands and responses are a little more cryptic.

I'm sure you can do it. ;)

-q

[tseres]

sorry for the misunderstanding....

yes, my garmin can output NMEA, but theres also a Garmin text out protocol that is much easier to extract data from than the NMEA where you actually have to choose the stream to decipher.

[chuckmerja]

I've ported the basics of AVRlib to an ARM and a freescale microcontroller. It should be fairly straightforward to get the PIC working as well. This process will take time but once you understand how serial buffers work in the PIC it should be no problem.
nmea.c (http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/docs/html/nmea_8h-source.html)

gps.c (http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/docs/html/gps_8h-source.html)

So it looks to me at first blush that the nmea and gps.hs might even be the same for PIC as AVR, but there will be differences in global, AVRlib and AVRtype. Does that sound close? I was hoping to get my feet wet, but looks like Im in over my head pretty fast:)

[chuckmerja]

sorry for the misunderstanding....

yes, my garmin can output NMEA, but theres also a Garmin text out protocol that is much easier to extract data from than the NMEA where you actually have to choose the stream to decipher.

Which PIC are you intending? We are hoping to use one of our IFI controllers from 2005 -8. I think they have something like a PIC 18f877 or ??

I appreciate your intent for simple, however, NMEA0183 is a widely followed standard, and eventually I want to get there, since Garmin, Trimble, Sparkfun etc put out those strings. I do see where Kevin Watson has played with the binary output of the SiRF based chips, but I don't have one of those, and I do have literally a dozen NMEA0183 units - some with very good accuraccy.

Am I missing something with not trying to track down the SiRF binary output??

[lynca]

So it looks to me at first blush that the nmea and gps.hs might even be the same for PIC as AVR, but there will be differences in global, AVRlib and AVRtype. Does that sound close? I was hoping to get my feet wet, but looks like Im in over my head pretty fast:)

You are correct, the main differences between the AVR and PIC will be the global definitions of the serial ports. The data types could also be different depending on what complier errors you get. Most of the code is basically just copying and pasting into your PIC project. Let me know if you have anymore questions.