--- In o...@yahoogroups.com, alvin sy wrote:
>
> hi, i want to store the data(latitude and
> longitude) coming from a gps to the OOpic so we can
> compare it to the coordinates that we input while it
> the mobot is moving but i think the oopic is too slow
> even at baud rate 2400 can anyone give suggestions or
> ideas what should we do? thanks
>
> OOpic S board, compiler V6, firmware B2.2+
>

Start by stripping the data: a minute of latitude is 1 nautical mile
(6076.1 feet). It is unlikely your 'bot will traverse a minute of
lat or lon (unless you are VERY far away from the equator).

Convert the fractional minute part of the lat/lon to an integer
(word) and store the values as 2 oWords. Do the same with the
incoming stream. Skip over everything until you get to the
fractional minutes and just convert that for testing.

Look at the $GPGLL sentence here:
http://www.qsl.net/n2ixd/digitraker/visualgps.htm

Your logic should watch the serial stream for $GPGLL, wait for the
following decimal point, convert 4 digits, wait for the following
decimal point, convert 4 digits and you're done. Start waiting for
the next $GPLL, etc

The way to do this is to have your 'bot code in a loop. As you run
through the loop, have a state machine (case statement) that 'knows'
what it is looking for in the next character. The case
statement 'looks' for $ and when it finds one it increments the state
number where is starts looking for G, increments the state and looks
for P and so on. At any point if the proper thing isn't found, it
sets the state back to 1 and looks for another $. 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.

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.

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! 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.

Then, I would get rid of the 2d serial port that talks to the OOPic
and use SPI. That way the OOPic could just clock the most current
data whenever it wanted. Almost any uC will have an SPI gadget and a
UART.

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.

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...

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> --- In o...@yahoogroups.com, alvin sy wrote:
> >
> > hi, i want to store the data(latitude and
> > longitude) coming from a gps to the OOpic so we can
> > compare it to the coordinates that we input while it
> > the mobot is moving but i think the oopic is too slow
> > even at baud rate 2400 can anyone give suggestions or
> > ideas what should we do? thanks
> >
> > OOpic S board, compiler V6, firmware B2.2+
> >
> >
> >
>
> Start by stripping the data: a minute of latitude is 1 nautical
mile
> (6076.1 feet). It is unlikely your 'bot will traverse a minute of
> lat or lon (unless you are VERY far away from the equator).
>
> Convert the fractional minute part of the lat/lon to an integer
> (word) and store the values as 2 oWords. Do the same with the
> incoming stream. Skip over everything until you get to the
> fractional minutes and just convert that for testing.
>
> Look at the $GPGLL sentence here:
> http://www.qsl.net/n2ixd/digitraker/visualgps.htm
>
> Your logic should watch the serial stream for $GPGLL, wait for the
> following decimal point, convert 4 digits, wait for the following
> decimal point, convert 4 digits and you're done. Start waiting for
> the next $GPLL, etc
>
> The way to do this is to have your 'bot code in a loop. As you run
> through the loop, have a state machine (case statement)
that 'knows'
> what it is looking for in the next character. The case
> statement 'looks' for $ and when it finds one it increments the
state
> number where is starts looking for G, increments the state and
looks
> for P and so on. At any point if the proper thing isn't found, it
> sets the state back to 1 and looks for another $. 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.
>
> 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.
>
> 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! 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.
>
> Then, I would get rid of the 2d serial port that talks to the OOPic
> and use SPI. That way the OOPic could just clock the most current
> data whenever it wanted. Almost any uC will have an SPI gadget and
a
> UART.
>
> 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.
>
> 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...
>
> Richard
>

Or, if you don't want a lot of complexity in the co-processor, just
have it pass from the input to output ONLY the sentence you want
($GPGLL ?) and drop all the others. That will take a tremendous load
off the OOPic.

Personally, I would put ALL the complexity in the co-processor to
make the OOPic interface as simple as possible. And it doesn't get
much simpler than SPI. It is really an advantage to have a protocol
where the OOPic is the master.

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

thanks for the suggestions, ill work on to that i have
another question NMEA protocol from GPS is ASCII
right? so do i need to convert it to decimal when
programming my oopic when like when its finding '$' or
the succeeding letters like "GPRMC" or can i just
write it as it is?
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

> for P and so on. At any point if the proper thing isn't found, it
> sets the state back to 1 and looks for another $.

Actually, a '$' always initiates a transition to the beginning-of-a-=20
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'=20=20
to indicate that the sentence is sourced by a GPS. (BTW, some GPS's=20=20
emit $LP if they are emulating a LORAN receiver.) Next comes the three-=20
alpha-character sentence type. The sentence consists of comma-=20
separated fields and always ends with a newline.

By having your state machine always reset on reception of a '<\n>$'=20=20
sequence you can always know where you are.

Richard's suggestion about stripping the most-significant part of the=20=20
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=20=20
on the memory limitations. When writing a parser I would have=20=20
suggested sucking up characters from your serial stream until you see=20=20
a delineator; e.g. $, <\n>, ',', etc.; and then chew on the field.=20=20
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=20=20
object, e.g. oByte, and when do I want to use just a plain variable,=20=20
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=20=20
Parallax Propeller. I am really impressed with the Parallax Propeller=20=20
as a general-purpose microcontroller. I only have two complaints with=20=20
it. One is that I would really like to have integrated A:D and D:A=20=20
hardware so I don't have to do sigma-delta A:D in software. The other=20=20
is that I do not like the spin language nearly as much as I do using=20=20
the Java syntax and the objects in the ooPIC. (Is there a reason why=20=20
most people seem to use the BASIC syntax instead of C/Java on the=20=20
ooPIC?)

The pairing of an ooPIC and a Propeller talking over the I2C bus=20=20
sounds like a marriage made in heaven. The Propeller has enough memory=20=20
and processing power (it has 8 internal independent CPU cores all=20=20
running at 80MHz) to do the kind of processing discussed here.=20=20
Dedicated a core ('cog' in Parallax' parlance) to suck up and process=20=20
the serial stream, leaving shared variables containing your velocity=20=20
vector and position lying around for use by other things. Let it=20=20
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=20=20
am teaching as several of my students (elementary and middle school)=20=20
have opted to acquire MarkIII mini-sumo 'bots powered by ooPICs. We=20=20
have Parallax Boe Bots (Basic Stamp) as our standard learning platform=20=20
and one pair of girls have started from zero designing their own 'bot=20=20
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=20=20
reduce position error. You can low-pass filter your position data to=20=20
reduce noise and improve short-term accuracy. But I am quite intereste=20=20
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
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C

=20

=20


(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

On Feb 17, 2008, at 10:21 AM, alvin sy wrote:

> thanks for the suggestions, ill work on to that i have
> another question NMEA protocol from GPS is ASCII
> right?

If I understand your question correctly, yes it is. You can hook the=20=20
data stream to a display terminal, e.g. a VT100, and what you see on=20=20
the screen will be human-readable. If you want binary values you will=20=20
need to parse the character stream.

> so do i need to convert it to decimal when
> programming my oopic when like when its finding '$' or
> the succeeding letters like "GPRMC" or can i just
> write it as it is?

Again, if I understand your question, you will need to parse the=20=20
stream into something more useful to your program internally.

--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C

=20

=20


(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, alvin sy wrote:
>
> thanks for the suggestions, ill work on to that i have
> another question NMEA protocol from GPS is ASCII
> right? so do i need to convert it to decimal when
> programming my oopic when like when its finding '$' or
> the succeeding letters like "GPRMC" or can i just
> write it as it is?
>
____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>

You grab the char from the oSerialPort into a variable (Byte or oByte)
named, say, ch.

In your case statement in state 1, for example, you do something like
this:

MyState = 1 ' at the top of the code, outside any loop

Do ' the main processing loop

... do whatever

if MySerial.Received then
..ch = MySerial
..Select Case MyState
....Case 1
......if ch = "$" then
........MyState = 2
......end if
....Case 2
......if ch = "G" then
.........MyState = 3
......end if
.. and so on until
....Case
......if ch = '.' then
........value = 0
........MyState =
......end if
....Case
......ch = ch - '0'
......if (ch >= 0) and (ch <= 9) then
........value = 10 * value + ch
......else ' we are out of digits
........MyState =
......end if

from here you look for the next decimal point and do a similar
conversion on a 2d value the then set MyState to 1 - look for the next
message

The whole point of this excercise is to NOT hang waiting on chars.

Richard

....



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

The ooPIC itself can't handle a GPS data rate, at any speed. However,
Micromega has a nifty FPU called the uM-FPU 3.1 that WILL handle it and
do the floating point math you want to do with the strings as well,
check it out here:
http://www.micromegacorp.com/oopic.html

DLC

rtstofer wrote:
> --- In o...@yahoogroups.com, alvin sy wrote:
>
>> hi, i want to store the data(latitude and
>> longitude) coming from a gps to the OOpic so we can
>> compare it to the coordinates that we input while it
>> the mobot is moving but i think the oopic is too slow
>> even at baud rate 2400 can anyone give suggestions or
>> ideas what should we do? thanks
>>
>> OOpic S board, compiler V6, firmware B2.2+
>>
>>
>
> Start by stripping the data: a minute of latitude is 1 nautical mile
> (6076.1 feet). It is unlikely your 'bot will traverse a minute of
> lat or lon (unless you are VERY far away from the equator).
>
> Convert the fractional minute part of the lat/lon to an integer
> (word) and store the values as 2 oWords. Do the same with the
> incoming stream. Skip over everything until you get to the
> fractional minutes and just convert that for testing.
>
> Look at the $GPGLL sentence here:
> http://www.qsl.net/n2ixd/digitraker/visualgps.htm
>
> Your logic should watch the serial stream for $GPGLL, wait for the
> following decimal point, convert 4 digits, wait for the following
> decimal point, convert 4 digits and you're done. Start waiting for
> the next $GPLL, etc
>
> The way to do this is to have your 'bot code in a loop. As you run
> through the loop, have a state machine (case statement) that 'knows'
> what it is looking for in the next character. The case
> statement 'looks' for $ and when it finds one it increments the state
> number where is starts looking for G, increments the state and looks
> for P and so on. At any point if the proper thing isn't found, it
> sets the state back to 1 and looks for another $. 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.
>
> 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.
>
> 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! 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.
>
> Then, I would get rid of the 2d serial port that talks to the OOPic
> and use SPI. That way the OOPic could just clock the most current
> data whenever it wanted. Almost any uC will have an SPI gadget and a
> UART.
>
> 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.
>
> 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...
>
> Richard
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )