AgOpenGPS Input Data Sources - The Combine Forum
 19Likes
Reply
 
LinkBack Thread Tools
post #1 of 65 (permalink) Old 01-28-2018, 04:54 PM Thread Starter
Senior Member
 
Join Date: Jan 2017
Location: NorthEast Ohio
Posts: 133
Mentioned: 0 Post(s)
Quoted: 62 Post(s)
AgOpenGPS Input Data Sources

Moving to a new thread to not clog up the main AgOpenGPS thread any further.

I'm starting this thread to as a spot to talk about the input data sources. There are many different ways to get the data and I see this as a quick moving field in trying to find sensors that are rugged and accurate enough for the Ag applications without breaking the bank.

The first area I'm investigating is using the Emlid Reach GPS for both GPS datastreams and the IMU data (roll, pitch and heading). Roll and (eventually) pitch are used to correct the GPS position. Heading is used to supplement to GPs heading calculation for turns where heading can be changing pretty fast.

JB_1 is offline  
Sponsored Links
Advertisement
 
post #2 of 65 (permalink) Old 01-28-2018, 05:03 PM Thread Starter
Senior Member
 
Join Date: Jan 2017
Location: NorthEast Ohio
Posts: 133
Mentioned: 0 Post(s)
Quoted: 62 Post(s)
Here'e the first bit of output using the reach.

The general approach is:
1) GPS sentences are sent directly from the reach to itself on 127.0.0.1
2) fused and filtered IMU data is added to the GPS data
..........the IMU is using the onboard MPU9250 + RTIMULib for applying calibrations and filtering to cleaning up the IMU Roll, Pitch, Heading and Yaw Rate
3) A reconstructed NMEA sentence, $PAOGI -- for Proprietary, AgOpenGps, Imu is then built and sent.

Here's a sample of the PAOGI sentence and the GGA, RMC data that was used to construct the GPS portion.

Sent Message:
$PAOGI,214818.80,4106.8273759,N,08142.2834086,W,4, 09,1.0,364.153,M,0.8,0.0,333.43,319.39,-0.46,-1.94,0.0,T*5D

..GPS components...
$GPGGA,214818.80,4106.8273759,N,08142.2834086,W,4, 09,1.0,364.153,M,-34.312,M,0.8,*7D
$GPRMC,214818.80,A,4106.8273759,N,08142.2834086,W, 0.00,333.43,280118,0.0,E,D*20

...imu readings...
319.39 - True heading (degrees)
-0.46 - Roll (degrees)
-1.94 - Pitch (degrees)
0.0 - yaw rate (degrees / second)

*5D - * + Cksum

Proposed format of PAOGI is: () is field number, each separated by commas

From GGA:
(1 , 2) 123519 Fix taken at 1219 UTC
(3 , 4) 4807.038,N Latitude 48 deg 07.038' N
(5, 6) 01131.000,E Longitude 11 deg 31.000' E
(7) 1 Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode
(8) 08 Number of satellites being tracked
(9) 0.9 Horizontal dilution of position
(10, 11) 545.4,M Altitude, Meters, above mean sea level
(12) 1.2 time in seconds since last DGPS update

From RMC or VTG:
(13) 022.4 Speed over the ground in knots (Or would you prefer KPH)
(14) 084.4 Track angle in degrees True

FROM IMU:
(15) XXX.xx IMU Heading in degrees True
(16) XXX.xx Roll angle in degrees (What is a positive roll, left leaning - left down, right up?)
(17) XXX.xx Pitch angle in degrees (Positive pitch = nose up)
(18) XXX.xx Yaw Rate in Degrees / second
(19) T/F IMU status - Valid IMU Fusion

*CHKSUM


Last edited by JB_1; 01-28-2018 at 05:05 PM.
JB_1 is offline  
post #3 of 65 (permalink) Old 01-28-2018, 05:59 PM
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,681
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
It reminds me of Pogey, i know, not helpful

I'll change RMC to OGI as per specs.
BrianTee is online now  
Sponsored Links
Advertisement
 
post #4 of 65 (permalink) Old 01-28-2018, 07:27 PM
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,681
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
Ok the internal sim is sending OGI and AgOpen is receiving. It is decoding all the navigation.

Knots is good, that makes it consistent.

Also, Roll Pitch Yaw is kind of the standard way to describe AHRS navigation, would you be willing to make that change?

Roll to left is positive right now. But i think it should be the other way around.

Time only takes up 1 position so 2 starts off with latitude. Hope this is ok....

(1) 123519 Fix taken at 1219 UTC

(2, 3) 4807.038,N Latitude 48 deg 07.038' N
(4, 5) 01131.000,E Longitude 11 deg 31.000' E

(6) Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode

(7) 08 Number of satellites being tracked
(8) 0.9 Horizontal dilution of position

(9, 10) 545.4,M Altitude, Meters, above mean sea level
(11) 1.2 time in seconds since last DGPS update

From RMC or VTG:
(12) 022.4 Speed over the ground in knots
(13) 084.4 Track angle in degrees True

FROM IMU:
(14) XXX.xx Roll angle in degrees (Roll to left is positive)
(15) XXX.xx Pitch angle in degrees (Positive pitch = nose up)
(16) XXX.xx Yaw Heading in degrees True
(17) XXX.xx Yaw Rate in Degrees / second
(18) T/F IMU status - Valid IMU Fusion

*CHKSUM

Attached Images
File Type: png 2018-01-28 (4).png (20.2 KB, 25 views)
JB_1 likes this.

Last edited by BrianTee; 01-28-2018 at 07:40 PM.
BrianTee is online now  
post #5 of 65 (permalink) Old 01-28-2018, 09:40 PM
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,681
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
The nmea parsing code

Code:
            if (!String.IsNullOrEmpty(words[2]) & !String.IsNullOrEmpty(words[3])
                & !String.IsNullOrEmpty(words[4]) & !String.IsNullOrEmpty(words[5]))
            {
                double temp;
                //get latitude and convert to decimal degrees
                double.TryParse(words[2].Substring(0, 2), NumberStyles.Float, CultureInfo.InvariantCulture, out latitude);
                double.TryParse(words[2].Substring(2), NumberStyles.Float, CultureInfo.InvariantCulture, out temp);
                temp *= 0.01666666666666666666666666666667;
                latitude += temp;
                if (words[3] == "S")
                {
                    latitude *= -1;
                    hemisphere = 'S';
                }
                else { hemisphere = 'N'; }

                //get longitude and convert to decimal degrees
                double.TryParse(words[4].Substring(0, 3), NumberStyles.Float, CultureInfo.InvariantCulture, out longitude);
                double.TryParse(words[4].Substring(3), NumberStyles.Float, CultureInfo.InvariantCulture, out temp);
                longitude += temp * 0.01666666666666666666666666666667;

                { if (words[5] == "W") longitude *= -1; }

                //calculate zone and UTM coords
                DecDeg2UTM();

                //fixQuality
                int.TryParse(words[6], NumberStyles.Float, CultureInfo.InvariantCulture, out fixQuality);

                //satellites tracked
                int.TryParse(words[7], NumberStyles.Float, CultureInfo.InvariantCulture, out satellitesTracked);

                //hdop
                double.TryParse(words[8], NumberStyles.Float, CultureInfo.InvariantCulture, out hdop);

                //altitude
                double.TryParse(words[9], NumberStyles.Float, CultureInfo.InvariantCulture, out altitude);

                //age of differential
                double.TryParse(words[11], NumberStyles.Float, CultureInfo.InvariantCulture, out ageDiff);

                //kph for speed - knots read
                double.TryParse(words[12], NumberStyles.Float, CultureInfo.InvariantCulture, out speed);
                speed = Math.Round(speed * 1.852, 1);

                //True heading
                double.TryParse(words[13], NumberStyles.Float, CultureInfo.InvariantCulture, out headingTrue);

                //roll
                double.TryParse(words[14], NumberStyles.Float, CultureInfo.InvariantCulture, out nRoll);

                //pitch
                double.TryParse(words[15], NumberStyles.Float, CultureInfo.InvariantCulture, out nPitch);

                //yaw
                double.TryParse(words[16], NumberStyles.Float, CultureInfo.InvariantCulture, out nYaw);

                //Angular velocity
                double.TryParse(words[17], NumberStyles.Float, CultureInfo.InvariantCulture, out nAngularVelocity);

                //is imu valid fusion
                if (words[18] == "T") isValidIMU = true;
                else isValidIMU = false;

                //update the watchdog
                mf.recvCounter = 0;
                updatedOGI = true;

                //average the speed
                mf.avgSpeed[mf.ringCounter] = speed;
                if (mf.ringCounter++ > 8) mf.ringCounter = 0;
            }
BrianTee is online now  
post #6 of 65 (permalink) Old 01-28-2018, 10:17 PM Thread Starter
Senior Member
 
Join Date: Jan 2017
Location: NorthEast Ohio
Posts: 133
Mentioned: 0 Post(s)
Quoted: 62 Post(s)
Smile

Like!

time was a typo on my part, agreed 1 position for time.

I'm good with AHRS standards...that's how I'm receiving the data from the IMU currently.
To clarify, for yaw, are you expecting -180 to 0 to 180 (looks like that's the standard for yaw).
Here's how I was converting yaw to heading
Code:
if(yaw < 0):
       heading = yaw+360
if (yaw >= 0):
        heading = yaw
I assume you're using the change in value and not the absolute number anyway.

I used the same roll picture...is the drone like plane flying toward you or away from you?

ps..I learned a new Canadian word today with Pogey

bench testing of pogey sentence:
$PAOGI,031555.20,4106.8271458,N,08142.2835704,W,5, 10,1.0,363.688,M,1.2,0.26,299.60,-10.58,0.05,-1.81,0.02,T*66
BrianTee likes this.
JB_1 is offline  
post #7 of 65 (permalink) Old 01-29-2018, 02:51 AM
Senior Member
 
Join Date: Nov 2016
Location: Austria
Posts: 782
Mentioned: 3 Post(s)
Quoted: 318 Post(s)
Quote:
Originally Posted by BrianTee View Post
Ok the internal sim is sending OGI and AgOpen is receiving. It is decoding all the navigation.

Knots is good, that makes it consistent.

Also, Roll Pitch Yaw is kind of the standard way to describe AHRS navigation, would you be willing to make that change?

Roll to left is positive right now. But i think it should be the other way around.

Time only takes up 1 position so 2 starts off with latitude. Hope this is ok....

(1) 123519 Fix taken at 1219 UTC

(2, 3) 4807.038,N Latitude 48 deg 07.038' N
(4, 5) 01131.000,E Longitude 11 deg 31.000' E

(6) Fix quality: 0 = invalid
1 = GPS fix (SPS)
2 = DGPS fix
3 = PPS fix
4 = Real Time Kinematic
5 = Float RTK
6 = estimated (dead reckoning) (2.3 feature)
7 = Manual input mode
8 = Simulation mode

(7) 08 Number of satellites being tracked
(8) 0.9 Horizontal dilution of position

(9, 10) 545.4,M Altitude, Meters, above mean sea level
(11) 1.2 time in seconds since last DGPS update

From RMC or VTG:
(12) 022.4 Speed over the ground in knots
(13) 084.4 Track angle in degrees True

FROM IMU:
(14) XXX.xx Roll angle in degrees (Roll to left is positive)
(15) XXX.xx Pitch angle in degrees (Positive pitch = nose up)
(16) XXX.xx Yaw Heading in degrees True
(17) XXX.xx Yaw Rate in Degrees / second
(18) T/F IMU status - Valid IMU Fusion

*CHKSUM

Could you also parse for me:

NMEA-0183 message: HDT
Related Topics
NMEA-0183 messages: Overview
Heading from True North
An example of the HDT string is:

$GPHDT,123.456,T*00

Heading from true north message fields
Field Meaning
0 Message ID $GPHDT
1 Heading in degrees
2 T: Indicates heading relative to True North
3 The checksum data, always begins with *

like also here:

https://www.trimble.com/OEM_Receiver...sages_HDT.html

It is the true heading coming from the 2 vector antenna of many gps receivers.

a
Andreas Ortner is offline  
post #8 of 65 (permalink) Old 01-29-2018, 11:36 AM
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,681
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
Quote:
Originally Posted by JB_1 View Post
Like!

time was a typo on my part, agreed 1 position for time.

I'm good with AHRS standards...that's how I'm receiving the data from the IMU currently.
To clarify, for yaw, are you expecting -180 to 0 to 180 (looks like that's the standard for yaw).
Here's how I was converting yaw to heading
Code:
if(yaw < 0):
       heading = yaw+360
if (yaw >= 0):
        heading = yaw
I assume you're using the change in value and not the absolute number anyway.

I used the same roll picture...is the drone like plane flying toward you or away from you?

ps..I learned a new Canadian word today with Pogey

bench testing of pogey sentence:
$PAOGI,031555.20,4106.8271458,N,08142.2835704,W,5, 10,1.0,363.688,M,1.2,0.26,299.60,-10.58,0.05,-1.81,0.02,T*66
Just send 0 to 360. A lot of imu's send that times 16 to send as an integer, but its just as easy to send as a float.

i have no idea which way its flying lol. But sitting in the seat, clockwise or lean to the right probably best to be positive. I will change everything on this end to reflect that.

I am at the FarmTech conference for the next few days so development will not be happening on my end for a few days. I will get the latest AOG up on Github so you can send it a pogey and make sure all is well.

I'll be checking here of course and can help with the usual bugs that creep up. We are getting there!
BrianTee is online now  
post #9 of 65 (permalink) Old 01-29-2018, 12:16 PM
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,681
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
The pogey version is on git.

Also the sim spits out paogi too.

Roll left is still positive. That will be a big job to change so later this week.
JB_1 likes this.
BrianTee is online now  
post #10 of 65 (permalink) Old 01-29-2018, 09:59 PM Thread Starter
Senior Member
 
Join Date: Jan 2017
Location: NorthEast Ohio
Posts: 133
Mentioned: 0 Post(s)
Quoted: 62 Post(s)
Quote:
Originally Posted by BrianTee View Post
The pogey version is on git.

Also the sim spits out paogi too.

Roll left is still positive. That will be a big job to change so later this week.
I was able to successfully have AgOpen recognize the $GAOGI sentence tonight. (after adding a \r\n the end end of the sentence!)
Lat, Lon and Altitude work.
It doesn't seem to be doing anything with roll angle currently (or do I need to have the antenna moving as I was bench testing?)
Also, is a comma needed after the IMUStatus (T/F) and before the *Cksum. I see the sim sends "...T,*CSUM"

A few comment and suggestions:
The MPU9250 + RTIMULib2 does use rolling to the right / clockwise as positive, seems like this is the standard. For now, I put a *-1 in before sending to AgOpen to flip it.

Small item, but I suggest using $PAOGI vs $GAOGI since it seem the industry standard for NMEA is to us $P to denote a proprietary sentence.

from the NMEA 0183 standard:
Proprietary Sentences. The standard allows individual manufacturers to define proprietary sentence
formats. These sentences start with "$P", then a 3 letter manufacturer ID, followed by whatever data the
manufacturer wishes, following the general format of the standard sentences. Some proprietary
sentences, mainly from Garmin, Inc., are listed in chapter 6.


Enjoy the conference. Would be really interested to hear you talk. I'm hope there are recordings available afterward!

JB_1 is offline  
Sponsored Links
Advertisement
 
Reply

Quick Reply
Message:
Options

Register Now



In order to be able to post messages on the The Combine Forum forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.

User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.

Password:


Confirm Password:
Email Address
Please enter a valid email address for yourself.

Email Address:
OR

Log-in










Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page



Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

 
For the best viewing experience please update your browser to Google Chrome