The Combine Forum banner

1 - 20 of 65 Posts

·
Registered
Joined
·
133 Posts
Discussion Starter #1
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.
 

·
Registered
Joined
·
133 Posts
Discussion Starter #2 (Edited)
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 12:35:19 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
 

·
Registered
Joined
·
5,808 Posts
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

 

Attachments

·
Registered
Joined
·
5,808 Posts
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;
            }
 

·
Registered
Joined
·
133 Posts
Discussion Starter #6
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
 

·
Registered
Joined
·
788 Posts
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_ReceiverHelp/V4.44/en/NMEA-0183messages_HDT.html

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

a
 

·
Registered
Joined
·
5,808 Posts
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!
 

·
Registered
Joined
·
5,808 Posts
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.
 

·
Registered
Joined
·
133 Posts
Discussion Starter #10
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!
 

·
Registered
Joined
·
5,808 Posts
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!
OOPS, i called it GAOGI - changed it to PAOGI and put on github Dev.

The roll pitch etc just gets plopped into variables at parsing - but nothing happens with them yet. I could have roll and heading print out tho. Will up it again shortly. That way you can at least see the numbers are getting to AgOpen.
 

·
Registered
Joined
·
5,808 Posts
Removed the comma from the sim sentence generator - i forgot to add the angular velocity term in the sim, hence the extra comma there.

Should be no comma by the *.

I added roll pitch yaw to the screen, at least you can see them in AOG now. I'll have to add all the gui stuff in order to select emlid imu stuff, that a much bigger job. The gui always is a pita.

Upped to git.
 

·
Registered
Joined
·
788 Posts
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.
Good work! Do you share your code?
 

·
Registered
Joined
·
133 Posts
Discussion Starter #14
Yes, I'll share my code, will admit that it's not great code and all of my debugging is via inserting print statements, then commenting them out. So it's not real pretty.
I'm testing with the latest Dev. to make sure everything works and will post it on GitHub later this week.
 

·
Registered
Joined
·
133 Posts
Discussion Starter #15
Update 2 for the night, was able to successfully get PAOGI sentence in. Roll, Pitch and Yaw are reading out correctly.
 

·
Registered
Joined
·
788 Posts
So a few things according to my new dual antenna system:

question 1)

With my vector antenna i have 2 possibility to output true heading:

A) all heading outputs
b) or only to the NMEA HDT (so i think i will have a track (vtg) and a heading output)

Because of your post i know that you calculate heading yourself in ag with last collected points. So if i output heading to all heading outputs you don´t get the real heading from receiver.
So there a 2 different ways to use real heading.
a) use hdt
b) make a checkbox (again :) ) to say nmea input = real heading

question 2)

a) i can mount my first antenna on steering axe and vector antenna on roof of my tractor - because of long baseline i would get a very very accurate heading information

b) i can mount my 2 antennas on the roof of the tractor side by side (left and right) like at kylers tractor.

Please correct me if i wrong, but with correct heading i can use var b) very well for getting and calculating the position of front axis for autosteer.

that would bring the advantage not so much cable across the tractor to lay. I could also fix the 2 antennas on a pole on the roof. so it looks beautiful and professional.
furthermore i can use the 2 antenna for the calculation of roll. (I have to test this)

but I would need a offset setting of the antenna to the side
 

·
Registered
Joined
·
5,808 Posts
If the heading was coming from a dual antenna, then would be a lot less calcs for AgOpenGPS to do. And the heading would be very accurate. No heading correction required and no slow speed compensation at all. Most of what AgOpenGPS does can be removed.

I think figure out what the best configuration is on your end, identify what is being sent, then add that to AgOpen. Probably easiest is to send HTG and position.

Would you like to program it?
 
1 - 20 of 65 Posts
Top