Dual GPS output format for AOG

GPS / RTK / GNSS
1

I am using a dual ardusimple gps plus a radio on a purpose build small rover. I use a third gps for the base. This set up provides a rtk position and heading. The heading is not affected by metal or magnetic objects like most magnetometers are.

The dual gps heading device is working well and I want to try it on the AOG code.
our system outputs a GGA message for position and a POLYA message for the heading.

To be compatible with AOG what format is required?

I may also use a Tinkerforge Brick v2 via USB to see the difference in the heading estimates.

On an unlelated question the AOG code does not control the tractor velocity. I assume that is controlled by the guy in the cab.
On one of your videos you were controlling the agribot by team viewer. Did you also control the velocity remotely and what was the cable hanging out of the cab. Was that a safety or communications connection.

regards
Max

2

Looks interesting! Could you provide more details how done?

Whatā€™s POLYA?

You could use standard nmea from Trimble- hdt.

3

If you use a base station and in addition have 2 GPS separated by 1 m on your rover. Then set up one rover as MOVING BASE and the other as a normal receiver. The normal will accepts the heading info from the moving base. You can get a heading in the message (POLYA) and normal rtk fix from a GGA message.
Ardusimple I think sell an add on board to do this as well. They could explain the details. If you want to contact my friend that made my system let me know.
Max

4

Good morning, it sounds good.
Iā€˜m very interested.
How can I have more information how it is done.

5

I am a Spezialist in this and Dual Heading.

What I need is the syntax of this messageā€¦

1 Like
6

Hi
the output from our dual antenna rtk system is as follows
the $GPGGA is a normal NMEA message that contains the usual lat long (in DD.MM.SS format)
the $POLYA message contains Time, N,E,D, separation, heading,Checksum
the $GPGGX message is a hybrid message that contains both lat long (DD.MM) and heading info
as we use the tiny gps library that likes lat and long in DD.MM.SS we extract the data from the GGA and POLYA data streams

can you implement this rtk position and heading in AOG as it would help reduce the reliance on the magnetometer heading. The dual gps uses 2 arduisimple boards and outputs the data streams at 10hz.
We have not detected a delay so far and the results seem good

Output
$GPGGA,160941.500,5230.134999,N,00254.557163,W,1,12,1.04,200.017,M,49.096,M,7B
$GPGGX,160941.500,52.502249986,-2.909286050,1,12,1.04,200.017,M,49.096,M,1.063,278.16,0,060
$POLYA,160941.500,0.151,-1.050,-0.060,1.062,278.16,A20
$GPGGA,160941.600,5230.134998,N,00254.557163,W,1,12,1.04,200.019,M,49.096,M,77
$GPGGX,160941.600,52.502249962,-2.909286058,1,12,1.04,200.019,M,49.096,M,1.062,278.16,0,06E
$POLYA,160941.600,0.151,-1.050,-0.060,1.062,278.16,A23
$GPGGA,160941.700,5230.134998,N,00254.557165,W,1,12,1.04,200.023,M,49.096,M,79
$GPGGX,160941.700,52.502249967,-2.909286080,1,12,1.04,200.023,M,49.096,M,1.062,278.16,0,066
$POLYA,160941.700,0.151,-1.050,-0.060,1.062,278.16,A22
$POLYA,160941.800,0.151,-1.050,-0.060,1.062,278.16,A2D
$GPGGA,160941.800,5230.134994,N,00254.557163,W,1,12,1.04,200.028,M,49.096,M,77
$GPGGX,160941.800,52.502249897,-2.909286043,1,12,1.04,200.028,M,49.096,M,1.062,278.16,0,063
$GPGGA,160941.900,5230.134994,N,00254.557164,W,1,12,1.04,200.033,M,49.096,M,7B
$GPGGX,160941.900,52.502249903,-2.909286069,1,12,1.04,200.033,M,49.096,M,1.062,278.16,0,06C
$POLYA,160941.900,0.141,-1.050,-0.060,1.061,277.63,A*23

7

Can you or anyone comment on the format needed for dual gps operations when the gps outputs position and heading information

8

https://www.trimble.com/OEM_ReceiverHelp/V4.44/en/NMEA-0183messages_HDT.html

https://www.trimble.com/OEM_ReceiverHelp/V4.44/en/NMEA-0183messages_PTNL_AVR.html

9

Many thanksā€¦very useful

So I need to output from the Arduino Nano 3 messages
GGA for position and the 2 you just sent
HDT for heading and PTNL_AVR for IMU data

Do you know if there is any Arduino Nano code available to manage the output of these 3 messages.

For the IMU I will use a TinkerForge Brick V2

10

And vtg for speed.

My code for megaā€¦

11

Thank you very much for allowing my to review the code. It is late now so I will look at this tomorrow. I guess the mega collects all the messages and then send the whole message to AOC.
The whole message now being
GGA
HDT
PTNL_AVR
VTG
Can these be sent in any order ?

regards
Max

1 Like
12

Itā€™s ok!

13

I looked at the AOG code and it wants the messages in the following manor

GGA- General message
VTG- Track made good and speed over ground
RMC Position, velocity, and time
HDT Heading from True North
POAGI (parsed OGI) GGA, RMC or VTG data from the IMU
PTNL (parsed AVR) Time, yaw, tilt, range for moving baseline RTK

first not sure what OGI is.

Also I understand the parsing but do not understand the PTNL (parsedAVR) and the Parsed OGI

I understand all the other messges.

There seems to be a lot of duplication of information between the various messages. I suppose that the duplicated variables are just discarded in the parsing

I will have to make this complex message on the nano before sending it to the AOG

I will look in your code tomorrow to see if I can determine this

Regards

Max

NMEA Messages parsed by code

Pasted Graphic.png

NMEA-0183 message: GGA

Related Topics

Time, position, and fix related data

An example of the GBS message string is:

$GPGGA,172814.0,3723.46587704,N,12202.26957864,W,

2,6,1.2,18.893,M,-25.669,M,2.0,0031*4F

Note ā€“ The data string exceeds the NMEA standard length.

GGA message fields

Field Meaning
0 Message ID $GPGGA
1 UTC of position fix
2 Latitude
3 Direction of latitude:

N: North

S: South|
|4|Longitude|
|5|Direction of longitude:

E: East

W: West|
|6|GPS Quality indicator:

0: Fix not valid

1: GPS fix

2: Differential GPS fix, OmniSTAR VBS

4: Real-Time Kinematic, fixed integers

5: Real-Time Kinematic, float integers, OmniSTAR XP/HP or Location RTK|
|7|Number of SVs in use, range from 00 through to 24+|
|8|HDOP|
|9|Orthometric height (MSL reference)|
|10|M: unit of measure for orthometric height is meters|
|11|Geoid separation|
|12|M: geoid separation measured in meters|
|13|Age of differential GPS data record, Type 1 or Type 9. Null field when DGPS is not used.|
|14|Reference station ID, range 0000-4095. A null field when any reference station ID is selected and no corrections are received1.|
|15|The checksum data, always begins with *|

Note ā€“ If a user-defined geoid model, or an inclined plane is loaded into the receiver, then the height output in the NMEA GGA string is always the orthometric height (height above a geoid). The orthometric height is output even if no user-defined geoid is loaded (there is a simplified default geoid in the receiver), or if a user-defined geoid is loaded, or if an inclined plane is used.

NMEA-0183 message: VTG

Related Topics

Track made good and speed over ground

An example of the VTG message string is:

$GPVTG,T,M,0.00,N,0.00,K*4E

VTG message fields

Field Meaning
0 Message ID $GPVTG
1 Track made good (degrees true)
2 T: track made good is relative to true north
3 Track made good (degrees magnetic)
4 M: track made good is relative to magnetic north
5 Speed, in knots
6 N: speed is measured in knots
7 Speed over ground in kilometers/hour (kph)
8 K: speed over ground is measured in kph
9 The checksum data, always begins with *

NMEA-0183 message: RMC

Related Topics

Position, velocity, and time

The RMC string is:

$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A

GPRMC message fields

Field Meaning
0 Message ID $GPRMC
1 UTC of position fix
2 Status A=active or V=void
3 Latitude
4 Longitude
5 Speed over the ground in knots
6 Track angle in degrees (True)
7 Date
8 Magnetic variation in degrees
9 The checksum data, always begins with *

NMEA-0183 message: HDT

Related Topics

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 *

$PAOGI

From GGA:

  • (1 , 2) 123519.00 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
  • (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

NMEA-0183 message: PTNL,AVR

Related Topics

Time, yaw, tilt, range for moving baseline RTK

An example of the PTNL,AVR message string is:

$PTNL,AVR,181059.6,+149.4688,Yaw,+0.0134,Tilt,60.191,3,2.5,6*00

AVR message fields

Field Meaning
0 Message ID $PTNL,AVR
1 UTC of vector fix
2 Yaw angle in degrees
3 Yaw
4 Tilt angle in degrees
5 Tilt
6 Reserved
7 Reserved
8 Range in meters
9 GPS quality indicator:

0: Fix not available or invalid

1: Autonomous GPS fix

2: Differential carrier phase solution RTK (Float)

3: Differential carrier phase solution RTK (Fix)

4: Differential code-based solution, DGPS|
|10|PDOP|
|11|Number of satellites used in solution|
|12|The checksum data, always begins with *|

14

In general there are only two messages need for Agopengps.

Gga or rmc (what message itā€™s send is Receiver specific) which contains position and some satellite information.
VTG which contains speed

Paogi is the idea of a user which is running with emlid reach . He uses the imu and combined gga,vtg, heading and roll and speed in one messageā€¦

Avr comes from a Trimble system. You can use the information for roll.

15

Iā€™m wondering if we should think about the UBX protocol that u-Blox uses (Page 37). With dual antenna setups it seems like the weā€™re ā€œdumbing downā€ the information by putting everything in NMEA 0183 messages. Might be worth considering AgOpenGPS accepting the UBX protocol as a GPS input.

6 Likes
16

I use the dual receiver gps to avoid problems with magnetic headings. So I do not want other heading estimates to be the primary heading

So how many headings can AOG use?

I want to also use the brick as I guess it is used to fuse to the gap heading estimate to up its frequency

Does that mean all other heading estimates in the various messages are ignored

17

Dual receiver should eliminate the need for a magnetometer. I believe at this point AOG can only use two headings: one from your GPS receiver and one from an IMU. The PAOGI is just as Andreas described earlier.

Brian did a great video explaining how GPS/IMU fusion works and you can find that here.

Hope that helps

18

Why not use the dual antenna for both heading and roll and use them directly? Eliminate the MMA and brick completely. The best thing would be to emulate with the arduino the sentence that Ardusimple will be making for dual antenna. Yet to be finalized though.

3 Likes
19

Here are a couple of pictures of the Dual Antenna device made by Clive Turvey.
It has 2 Ardusimple boards and a Lora radio. Base picture not included. That is one Ardusimple board
As mentioned before it can output various messaged at 10Hz. the heading seems to be solid. The current messages are GGA and POLYA. The Polya message gives the heading.
The reason to keep the Brick is the antenna in our setup will be place longitudinally along the tractor and no good for roll (could be used for pitch.
Also if the Brick updates faster than 10hz so it could be fused in the AOG to provide a faster update rate for the 10hz gps.
From all this the MMA can probably be eliminated.

I need to confirm from Clive is the difference between the POLYA message that we use and the VTG or RMC that you use so we can add the dual gps to our desktop system

Questionā€¦does all this sound reasonableā€¦Is the Brick used in the heading fusion of the gps heading ?
Max

IMG_3048 IMG_3047

20

if you have a dual system with heading .- the brick does not need to useā€¦