Another advantage of GPS simulation: you get to discover horrible glitches in the matrix, such as the inconvenient fact that GPS comes in different dialects, each of which requires different parsing. I found this out when my GPS parser was working with the simulator, but not the real EM406. The problem turned out to be that the simulator outputs GPS time as hhmmss, while the EM406 outputs it as hhmmss.sss (the newer SIRF III chipset has fractional seconds).
How to write a parser that can handle both? The Basic Stamp's powerful SERIN formatting commands came to the rescue. Our entire GPS parser is built right into the SERIN command:
SERIN GPS,Baud,5000,noGPSData,[WAIT("GPGGA,"),DEC TempW, WAIT (","), DEC LatDeg, DEC LatMin, SKIP 3, DEC LonDeg, DEC LonMin, SKIP 12, DEC TempAlt(1)]
The "DEC TempW, WAIT (",")" tells the serial parser to read the first number after GPGGA, then skip till after the next comma. On the old version of NMEA (and the simulator), the comma is the next thing so we're not skipping anything. But on the new EM406, this command will skip the fractional seconds and the comma.
It's worth studying the whole range of SERIN formatting commands. With clever use of skips, waits and variable entries, you can process pretty much anything by turning SERIN into an embedded data parser.
Ohh perfect!! no big deal i'm just trying to help. Actually im not sure of the math you use to navigate. Did you explain before about the Waypoint Math to know the direction and the distance of a waypoint?? Thanks!!!
Of course we do that calculation 60 times a minute, so the error shrinks the closer we get. We'll never be more than a few feet off target. Honestly, I don't think this is a problem.
If you don't correct the lon variation according to the Lat, your navigation system will tell you to head to 37 degrees, to get to your destination. In other words, if you objective is 111 km away you going to finish more than 15 Km away of your the real destination.
If you correct the lon variation according to the lat, your navigation will say, "Please go to: 43 degrees". If your objective is 111 km away, you going to finish just a few meters away of your real destination.
The difference is just 6 degrees, being careless about the GPS error too.
Yes, a word: just 16 bits. If we had long variables (as we do in RobotC on the Mindstorms NXT) this would be a different matter.
We don't adjust the waypoint algorithm for latitude on the assumption that it doesn't matter enough for our purposes. But we'll see if that's the case with more testing.
hahah i was laughing about the time we comment.
Well.. Actually i changed this part in my GPS navigation (talking about the lookup table for the angle and the Arctan). I use a simple equation (rule of three) and multiply everything by 100 to have 1 degree resolution, without using floating points. Atmega 168 do not support floating operations by hardware, all is software emulated, and thats sucks a lot of CPU power. Actually i'll try to do the same with Kalman Filters. XD
Uhh bad news about the the largest variable (is 16bits right?). My point was use only one value to store the latitude or the longitude (32 bits). And the second point is the adjustment made to have a better navigation, because the length of longitude change depending the latitude.
We're constrained by the data structures of Basic Stamp, where the largest variable is a word. ddmm.mmmm is two words, so we input it as two words. Then when we subtract our current position from our waypoint, we're left with m.mmmm, which can be held in one word, which is how it's used for the rest of the code. Is there a better way that I'm missing?
I hadn't seen that tutorial, but as it happens that's quite similar to the method I came up with. But rather than use a lookup table for angle, we use ArcTan (maybe PicBasic doesn't have trig functions?).
Comments
http://jordii07.googlepages.com/Waypoint-Math.pdf
If you don't correct the lon variation according to the Lat, your navigation system will tell you to head to 37 degrees, to get to your destination. In other words, if you objective is 111 km away you going to finish more than 15 Km away of your the real destination.
If you correct the lon variation according to the lat, your navigation will say, "Please go to: 43 degrees". If your objective is 111 km away, you going to finish just a few meters away of your real destination.
The difference is just 6 degrees, being careless about the GPS error too.
One Longitude degree measure 111, when lat is equal to 0 degrees.
Now move on to California,
one longitude degree measure 96.448 km, when lat is equal to 30 degrees (15Km less).
And one Lon degree measure 78.849 km, when lat is equal to 45 degrees (32 Km less).
So here in California we have a difference of >15Kms!!!
So you airplane is going to be 15 km away of your real objective.
http://www.fes.uwaterloo.ca/crs/geog165/gcoords.htm
We don't adjust the waypoint algorithm for latitude on the assumption that it doesn't matter enough for our purposes. But we'll see if that's the case with more testing.
Well.. Actually i changed this part in my GPS navigation (talking about the lookup table for the angle and the Arctan). I use a simple equation (rule of three) and multiply everything by 100 to have 1 degree resolution, without using floating points. Atmega 168 do not support floating operations by hardware, all is software emulated, and thats sucks a lot of CPU power. Actually i'll try to do the same with Kalman Filters. XD
I hadn't seen that tutorial, but as it happens that's quite similar to the method I came up with. But rather than use a lookup table for angle, we use ArcTan (maybe PicBasic doesn't have trig functions?).
Theres a easy way, did you read this good tutorial?:
http://jordii07.googlepages.com/Waypoint-Math.pdf