> sets the state back to 1 and looks for another $.
Actually, a '$' always initiates a transition to the beginning-of-a-
sentence state. No need to "escape".
Here is another description of NMEA sentences your GPS will emit:
http://www.gpsinformation.org/dale/nmea.htm
If you look at an NMEA sentence, it begins with '$' followed by 'GP'
to indicate that the sentence is sourced by a GPS. (BTW, some GPS's
emit $LP if they are emulating a LORAN receiver.) Next comes the three-
alpha-character sentence type. The sentence consists of comma-
separated fields and always ends with a newline.
By having your state machine always reset on reception of a '<\n>$'
sequence you can always know where you are.
Richard's suggestion about stripping the most-significant part of the
data is a good one as it substantially reduces the processing needed.
Caveat: I am very new to the ooPIC. I haven't really gotten a handle
on the memory limitations. When writing a parser I would have
suggested sucking up characters from your serial stream until you see
a delineator; e.g. $, <\n>, ',', etc.; and then chew on the field.
Richard's suggestions may very well be more useful than my comments.
> Obviously, the
> state that skips junk looking for the decimal point needs a way to
> stop looking. Maybe stop when you see a carriage return - something
> to get out of a mangled message and back to state 1.
See my comments above.
> You will need to deal with 'roll-over' if you start at say .9999 and
> travel to .0003 because you only converted the fraction. I haven't
> worked out the details but perhaps oInteger would be better than
> oWord.
And this brings up a question for me: when do I want to use a data
object, e.g. oByte, and when do I want to use just a plain variable,
e.g. Byte? As I said, I'm am a noob and still learning.
> I wouldn't do it this way! The OOPic is a poor choice for serial IO
> and the GPS is 'chatty'. It's talking all the time and just won't
> shut up!
Ah, I was thinking the same thing but wasn't sure.
> I might take a separate uC that had 2 serial ports and use
> one to grab the GPS stream and the other to output the binary
> fractions to the OOPic. In fact, it might be better to not tell the
> OOPic WHERE the 'bot is located but to just tell it how FAR it has
> moved from the start. If you were interested, the co-processor could
> also determine distance in some arbitrary reference and just present
> deltaX and deltaY in units of your choice.
I am going to make a radical suggestion here: pair the ooPIC with a
Parallax Propeller. I am really impressed with the Parallax Propeller
as a general-purpose microcontroller. I only have two complaints with
it. One is that I would really like to have integrated A:D and D:A
hardware so I don't have to do sigma-delta A:D in software. The other
is that I do not like the spin language nearly as much as I do using
the Java syntax and the objects in the ooPIC. (Is there a reason why
most people seem to use the BASIC syntax instead of C/Java on the
ooPIC?)
The pairing of an ooPIC and a Propeller talking over the I2C bus
sounds like a marriage made in heaven. The Propeller has enough memory
and processing power (it has 8 internal independent CPU cores all
running at 80MHz) to do the kind of processing discussed here.
Dedicated a core ('cog' in Parallax' parlance) to suck up and process
the serial stream, leaving shared variables containing your velocity
vector and position lying around for use by other things. Let it
crunch your numbers for you.
> Regardless of the baud rate, you really don't want to use the OOPic
> for serial IO. It can be made to work well if the sender will handle
> flow control but the GPS probably won't. In any event, make sure you
> are using oSerialPort (the hardware UART) because it has a 4 byte
> buffer.
I have so much to learn. I am using the ooPIC in the robotics class I
am teaching as several of my students (elementary and middle school)
have opted to acquire MarkIII mini-sumo 'bots powered by ooPICs. We
have Parallax Boe Bots (Basic Stamp) as our standard learning platform
and one pair of girls have started from zero designing their own 'bot
using the Propeller chip. (Not bad for 6th graders.)
>
>
> Given the 1-5 meter positioning accuracy of differentially corrected
> GPS, I have never been convinced that GPS odometry is practical.
> Maybe one day I'll give it a try...
I have been wondering that too. OTOH, most GPS engines now use WAAS to
reduce position error. You can low-pass filter your position data to
reduce noise and improve short-term accuracy. But I am quite intereste
in people's experiences here.
--
Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
I fly because it releases my mind from the tyranny of petty things . . .
— Antoine de Saint-Exupéry
PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/oopic/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/oopic/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:oopic-digest@yahoogroups.com
mailto:oopic-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
oopic-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
No comments:
Post a Comment