Can DriveWorks use generic serial I/F GPS with NMEA protocol?

I tried to use sample/sensors/gps/sample_gps_logger for reading NMEA out from GPS through USB serial.

However sample program showed the message like below and stopped;

./sample_gps_logger  --driver=gps.uart --params=device=/dev/ttyUSB0
[19-11-2019 20:45:40] Platform: Detected Generic x86 Platform
[19-11-2019 20:45:40] Initialize DriveWorks SDK v2.0.2081
[19-11-2019 20:45:40] Release build with GNU 4.9.4 from heads/buildbrain-branch-0-g36b127f
[19-11-2019 20:45:40] TimeSource: monotonic epoch time offset is 1574150330453817
[19-11-2019 20:45:41] Platform: number of GPU devices detected 1
[19-11-2019 20:45:41] Platform: currently selected GPU device discrete ID 0
[19-11-2019 20:45:41] SDK: Resources mounted from /usr/local/driveworks-2.0/data/
[19-11-2019 20:45:41] SensorFactory::createSensor() -> gps.uart, device=/dev/ttyUSB0
[19-11-2019 20:45:41] SensorFactory::createSensor() -> gps.uart, device=/dev/ttyUSB0
[19-11-2019 20:45:41] EndpointTTY: started on /dev/ttyUSB0

I checked the status of dwSensorGPS_readFrame() and found that it always returned DW_TIME_OUT.

The GPS module sent the NMEA sentences like below (I used cu command directly);

$GPGSA,A,3,31,26,21,27,29,,,,,,,,2.76,1.61,2.24*08
$GPGSV,2,1,07,09,10,319,21,14,19,183,,21,34,094,31,26,65,012,35*73
$GPGSV,2,2,07,27,42,217,23,29,13,040,30,31,54,123,31*47
$GPGLL,xxxx.55212,N,xxxxx.90875,E,132844.00,A,A*64
$GPRMC,132845.00,A,xxxx.55212,N,xxxxx.90879,E,0.578,,091119,,,A*7B
$GPVTG,,T,,M,0.578,N,1.071,K,A*2E
$GPGGA,132845.00,xxxx.55212,N,xxxxx.90879,E,1,05,1.61,35.6,M,39.2,M,,*67
$GPGSA,A,3,31,26,21,27,29,,,,,,,,2.76,1.61,2.24*08
$GPGSV,2,1,07,09,10,319,21,14,19,183,,21,34,094,31,26,65,012,35*73
$GPGSV,2,2,07,27,42,217,23,29,13,040,31,31,54,123,31*46
$GPGLL,xxxx.55212,N,xxxxx.90879,E,132845.00,A,A*69
$GPRMC,132846.00,A,xxxx.55210,N,xxxxx.90873,E,0.547,,091119,,,A*7C
$GPVTG,,T,,M,0.547,N,1.013,K,A*26
$GPGGA,132846.00,xxxx.55210,N,xxxxx.90873,E,1,05,1.61,35.6,M,39.2,M,,*6C
$GPGSA,A,3,31,26,21,27,29,,,,,,,,2.76,1.61,2.24*08
$GPGSV,2,1,08,09,10,319,21,14,19,183,,21,34,094,31,23,28,296,*78
$GPGSV,2,2,08,26,65,012,35,27,42,217,23,29,13,040,31,31,54,123,30*7A
$GPGLL,xxxx.55210,N,xxxxx.90873,E,132846.00,A,A*62

How can I use this GPS module for DriveWorks?
Or DriveWorks can work with the GPS/IMUs in the supported device list only?

Environment : Ubuntu 16.04
Drive OS API 5.1.0.2
DriveWorks SDK version : 2.0.2085 Release

Hi Hirofumi.Tamori,

Did you run the sample on host computer? Why is “Platform: Detected Generic x86 Platform” message in your log?

Please try on Drive system with “/dev/ttyACM0”. You can take a look at “GPS Location Logger Sample” section of DriveWorks SDK Reference in DRIVE Software 9.0 Documentation for details.

Drive Software 10.0 release will be announced soon but you can already install it via SDK Managera. So maybe you can also have a try on this.

Thanks, VickNV.

Why is “Platform: Detected Generic x86 Platform” message in your log?

Because my AGX is now at the place apart. I’m preparing GPS logger before AGX comes here.

You said that “/dev/ttyACM0” device works; it means DriveWorks requires not only a simple UART but V.250 command set of modem like ATA, ATDT,…, is it correct?

Drive Software 10.0 release will be announced soon but you can already install it via SDK Managera. So maybe you can also have a try on this.

Is any improvement around gps and uart part in 10.0? As 10.0 requires ubuntu upgrading to 18.04, I’d like to know the upgrade cost benefit balance.

But it looks you can get NMEA sentences from ttyUSB0 device with cu command, right?

At least, I saw some changes in NMEA decoding code. Not for the specific issue, but in the long term, I would still encourage users always move to the latest release.

But it looks you can get NMEA sentences from ttyUSB0 device with cu command, right?

Yes, it’s right. I checked GPS module by cu command (or screen command) thru ttyUSB0.

My question is whether the driver gps.uart sends AT command to GPS module for some purpose i.e. checking the existence of the module by its reply.

If the driver doesn’t use AT command and only reads NMEA strings from GPS, I think there is no difference between ttyUSB0 and ttyACM0. And the cause why the sample logger always returns DW_TIMEOUT should be another story.

At least, I saw some changes in NMEA decoding code. Not for the specific issue, but in the long term, I would still encourage users always move to the latest release.

Yes, I agree. And I (slightly) suspect that the driver gps.uart check the some specific NMEA sentences for data validation.

By the way, if I decide, can I write the dedicated GPS driver by myself?
For that purpose, I could find only the webiner which tells simply how to write custom drivers. Are there any documents about driver programming?

DW does not send commands to the GPS module / check for existence by a reply.

We have tried your nmea snippet (after modifying the XXXX value and checksum) with the sample on virtual device. It’s working. So probably it’s something to do with reading out data from the tty device.

Could you help check if baud rate setting is the problem? Per default, if no baud parameter has been provided, the gps.uart driver assumes a baudrate of 9600.

DW expects at least the GGA message to be present. If this message is missing, the sample will not print any data. This isn’t the case here (as you can see in his NMEA logs).

Yes, that should be possible. We have a new feature in Driveworks called Comprehensive Sensor Plugin Framework. Once you download Drive Software 10.0 via SDK Manager, You can check the release notes (located at ~/Downloads/nvidia/sdkm_downloads/NVIDIA_DRIVE_Software_Release_Notes_10.0.pdf). Also DriveWorks SDK reference has sections about it. You can take a look once available at https://developer.nvidia.com/drive/documentation.

Thank you VickNV for checking my NMEA snippet even with recovering xxxx and checksum!
So, the NMEA sentences of my GPS module is correct and should be omitted from the cause of timeout.

Of course I set and checked the baudrate when I browsed NMEA sentences by cu/screen. I use it with default baudrate 9600.

DW expects at least the GGA message to be present. If this message is missing, the sample will not print any data. This isn’t the case here (as you can see in his NMEA logs).

OK, it make sense of the check condition for NMEA by the driver. Then I must inspect the lower layer of driver (w/o source).

Once you download Drive Software 10.0 via SDK Manager, You can check the release notes (located at ~/Downloads/nvidia/sdkm_downloads/NVIDIA_DRIVE_Software_Release_Notes_10.0.pdf

For the backup plan, I’ll start to read that document.

Please replace /usr/local/driveworks/lib/libdriveworks.so.2.0.xxxx with the attached one and then run the sample with it to check the error from dwSensorGPS_readFrame(). We would like to see if we can further narrow down the issue. Thanks!
libdriveworks.so.2.0.2088.zip (8.42 MB)

The messages after I replaced the library are;

[22-11-2019 10:30:15] Platform: Detected Generic x86 Platform
[22-11-2019 10:30:15] Initialize DriveWorks SDK v2.0.2088
[22-11-2019 10:30:15] Release build with GNU 4.9.4 from heads/release-2.0-0-g7d740dd
[22-11-2019 10:30:15] TimeSource: monotonic epoch time offset is 1574315206384180
[22-11-2019 10:30:15] Platform: number of GPU devices detected 1
[22-11-2019 10:30:15] Platform: currently selected GPU device discrete ID 0
[22-11-2019 10:30:15] SDK: Resources mounted from /usr/local/driveworks-2.0/data/
[22-11-2019 10:30:15] SensorFactory::createSensor() -> gps.uart, device=/dev/ttyUSB0
[22-11-2019 10:30:15] SensorFactory::createSensor() -> gps.uart, device=/dev/ttyUSB0
GPS[0] - 173671696 ERROR DW_NOT_READY
[22-11-2019 10:30:15] EndpointTTY: started on /dev/ttyUSB0
GPS[1] - 173671696 ERROR DW_NOT_READY
GPS[0] - 173671696 ERROR DW_NOT_READY
GPS[1] - 173671696 ERROR DW_NOT_READY
GPS[0] - 173671696 ERROR DW_NOT_READY
GPS[1] - 173671696 ERROR DW_NOT_READY
GPS[0] - 173671696 ERROR DW_NOT_READY
GPS[1] - 173671696 ERROR DW_NOT_READY
GPS[0] - 173671696 ERROR DW_NOT_READY
GPS[1] - 173671696 ERROR DW_NOT_READY
GPS[0] - 173671696 ERROR DW_NOT_READY
GPS[1] - 173671696 ERROR DW_NOT_READY

When does the driver shows this error message?
There are no difference between the cases GPS caught valid satellites or not.

It looks not able to get GPGGA message. Did you try outdoors to make sure it can receive a signal from the actual GPS?

I built another library returning DW_DNN_INVALID_TYPE error for no GPGGA message.
Please try with it to double confirm my presumption.
libdriveworks.so.2.0.2088.zip (8.6 MB)

Unfortunately the result was same as the previous(Hmm, it seems that you might attached the same version as the previous one…).

BTW, I tried to compare the other device.

I captured the NMEA sentences through /dev/ttyUSB0 by cat /dev/ttyUSB0 > gps.txt.

And replayed that text on raspberry pi bu cat gps.txt > /dev/ttyAMA0 → Rpi’s TX/RX → USB serial → sample_gps_logger.

Then it almost works. When the baudrate is 9600, sample_gps_logger shows the location data but still shows ERROR DW_NOT_READY. When the baudrate is 115200, no ERROR messages are shown after the NMEA data sent.

So the cause of the malfunction may be around the USB serial communication layer, I think.
I suspect sample_gps_logger or the PC where sample_gps_logger runs adopts H/W flow control by RTS/CTS.

As Rpi USB serial thru TX/RX apparently has no H/W flow control by default(of course there is a bit annoying way to adopt RTS/CTS), sample_gps_logger can read the NMEA data and display the parse results.

It’s a rough guess but the range for checking is narrowed down.

Have you also tried 115200 baudrate with the GPS through USB serial?

Could you also share the sensor type you are using?

Yes, I tried GPS through USB Serial in 115200 and got the same result(ERROR DW_NOT_READY).

The USB module is GM8013T, very cheap one. I’m using it just for testing because it surely works as a GPS with NMEA format.

So other expensive GPS modules shall work if I try them and there is also a possibility to fail. This is why I concerned with the cause of this phenomenon.

We suspect there are some problems in decoding NMEA sentences.
In our decoder, it looks for newline, carriage return or null as sentence end.
Maybe it’s because the parser cannot get any of them.

Could you run the command to check if any difference between using Rpi and the module (success vs failure)?

stty -F /dev/ttyXYZ

With a known compatible device, we see

tty -F /dev/ttyACM0
speed 57600 baud; line = 0;
eof = ^A; min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-icanon -echo -echoe

Moreover, I made another debugging library. If it’s due to failure in parsing the end of sentence, you will see DW_DNN_INVALID_TYPE returned. Please have it a try.
libdriveworks.so.2.0.2088.zip (27.1 MB)