gps with propeller - really weird, wrong results

compuwiz

Hi, I'm Matt a sophomore in high school. I am in science research doing a science project on autonomous mobile robot navigation for SAR. I am using the parallax gps. I want it too return decimal degrees so I can compare them to the destination decimal degrees and the gps gives out degrees, minutes, and fractional minutes. I found a program diydrones.com/forum/topics/705844:Topic:20648?page=1 but the math gives me really weird results. I adapted the math from the BS2 example code given in the documentation for the gps www.parallax.com/Portals/0/Downloads/docs/prod/acc/GPSManualV1.1.pdf to do this:
F references the object FloatMath


DecDegrees := F.FMul(F.FAdd(F.FDiv(F.FMul(F.FFloat(mn), 1000), 6), F.FDiv(F.FFLoat(MinFrac), 60) ) , 10000)
'DecimalDegrees equals (minutes * 1000) / 6
if negate
DecDegrees := F.FNeg(DecDegrees)

that didn't work neither did other attempts that I have commented out in GetXitude under GPSSmartMode.spin

Anyone have any idea what I did wrong?

or is their a better object to use because I couldn't find any on the Propeller exchange

p.s. i do have it wired correctly

Post Edited (compuwiz) : 1/31/2009 4:37:56 PM GMT

Leon

Are the original raw data OK?

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

compuwiz

yes, I've returned all the values individually and they have come out right. WHen I use my math I return DecDegrees instead of GetGPSFloat by the way

Beau Schwabe

Monday I will look into this issue. The problem arises in "Smart mode" communications between the Propeller and the GPS module. In "Smart mode", the GPS unit requires that you send it information in order for the GPS to know what to send back to you. The logic HIGH threshold for the GPS unit is 4V. In "RAW mode" however, the GPS simply streams the data as it receives it from the satellites. I think this issue is purely the 3.3V logic HIGH that the Propeller is capable of generating competing against an expected 4V threshold receiving level of the GPS. A simple diode/resistor pull-up is not enough due to a current loop that would be created through the ESD diodes in the Propeller, but a bipolar transistor configured as an emitter follower would probably do the trick once and for all. (See attached image)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

compuwiz

I am using a spin stamp plugged into a Board of Education. I have found that that has changed things before, could it have an effect on this?

compuwiz

also I don't think it is a voltage problem because I get the Degrees, Minutes, and Fractions of a Minute when I get them individually, it's just my math that is messed up

cessnapilot

Try the formula with the float format of the numbers, like

DecDegrees := F.FMul(F.FAdd(F.FDiv(F.FMul(F.FFloat(mn), 1000.0), 6.0), F.FDiv(F.FFLoat(MinFrac), 60.0) ) , 10000.0)

Chuck Rice

I had some problems with the FP Math with my GPS. It turned out to be the precision of the propeller's FP is limited for the calculations required. After much digging, I found the code in the attached works. See the comments in the code. You may be running into the same problems.

compuwiz

thank you very much

cessnapilot

To find even more navigation routines look into the 'GPS
Float' object that was recently put on Obex. I just cite from its header:

' ... The 'GPS_Float' driver object bridges a SPIN program
to the strings and longs provided by the basic
"GPS_Str_NMEA" driver and translates them into descriptive
status strings, long and float values and checks errors
wherever appropriate. This driver contains basic algorithms
for calculations in navigation. By using these procedures
you can make your Propeller/GPS combination to be much more
useful than just a part of·· the onboard entertainment
system of your car, ship or plane. Given two locations,
where one of them can be a measured position and the second
one a destination, the driver calculates the distance and
the initial (actual) bearing for the shortest, so called
Great-Circle route to the second position. Alternatively, it
can calculate the constant bearing and the somewhat longer
distance on that path to reach the same destination. This
second type of navigation, where it is easier to steer due
to the constant bearing, is known as Rhumb-Line navigation.
Great-Circle courses where the bearing of the destination is
changing continuously during travel, are only jokes for a
helmsman, but are quite appropriate for a computerized
autopilot. In Rhumb-line· navigation the driver helps Dead-
Reckoning by calculating the destination from the known
length and course of a leg. The driver contains procedures
to check the proximity of a third location while en-route
from a first to a second point. For Great-Circle routes it
can calculate the Cross-Track distance of a given off-track
location and the Along-Track distance, which is the distance
from the current position to the closest point on the path
to that third location. For Rhumb-Line navigation the driver
calculates Closest Point of Approach (CPA) related
quantities, such as Time for CPA (TCPA) and distance from
object at CPA (DCPA), where the object is given by its
Latitude, Longitude (and by its constant course and speed,
if known) and we are cruising on a measured stable course
with measured constant speed. ...'································································
·······
As for the precision: Navigation calculations on the
spherical or on the ellipsoidal Earth usually involve some
trigonometry whatever kind of arithmetic, integer or float,
you use. Because of the given resolution of the arithmetic
tables in the Prop ROM, I noticed difference between the
results when I used the Floating Point objects and the uM-
FPU Floating Point coprocessor. Typical example is the
transformation between the surface-referenced latitude,
longitude and altitude (geographic) and Earth-Centered,
Earth-Fixed (ECEF) position coordinates. Using the Floating
Point arithmetic objects the results can be imprecise with
several nautical miles in many positions on the Mother
Earth. Using the FPU the precision is usually better than 1
m, wherever you are. In fact, you can hardly reach higher
precision with 32 bit floats. This number format has a
maximum of 7.5 digits of precision. ECEF coordinate values
are some tens of millions of meters. The product of the
precision and the values is about 1 m. This precision is,
however, much better than the position accuracy of a typical
SPS GPS reading. The 'method' of the FPU to obtain that 1 m
precision is simple: SINE and COSINE values all accurate in
at least 7 decimal digits.

If your integer arithmetic uses the ROM tables you probably
have to live with that precision they provide. I can just
hope that some of the integer arithmetic gurus, For Example
(EF), on the forum will provide us with higher precision
arithmetic tables by mastering, not just extolling, the
virtues of integer arithmetic.

compuwiz

I will have to take a closer look at that object it sounds really helpful. My current path planning just has to robot go N or S until the Latitude is the same and then E or W until the longitude is the same. Then if an obstacle is detected it avoids it but this sounds like it can do better. Last night I was able to get the numbers I wanted by using the GetGpsFixedMethod as opposed to the GetGpsFloat method. As to the floating point processor my project is due on thursday but I will definitely order one once fair is over.

Beau Schwabe

compuwiz,

Can you post the schematic that you are using between the Propeller and the GPS unit?
I'm not sure that the 1K resistor between Propeller's P0 and the GPS's SIO will work in "Smart" mode, because the GPS has a voltage threshold of 4V and the Propeller is only capable of providing 3.3V.

"Raw" mode·reception would be just fine with this configuration however.


Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 2/1/2009 3:14:45 PM GMT

compuwiz

I am not using a resistor. Sio to P14, GND to Vss, Vcc to Vdd. /Raw is left unconnected

Beau Schwabe

compuwiz,
·
You need some kind of current limiting resistor between the GPS and the Propeller or you run the risk of damaging your Propeller pin.· Since the GPS operates on a 5V supply, and the Propeller operates on a 3.3V supply, your design should observe proper 3.3V to 5V interfacing techniques.
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

compuwiz

okay