dGPS Problem in NXT-G 2.0

LEGO Mindstorms Navigation Sensors for LEGO
1

I have a new dGPS sensor that I’m using with the NXT-G 2.0 Education version. Generally it works well, but I’m having a problem. My project is to drive a small autonomous boat around the waters here in Bahrain (yes, in the Middle East). Besides the dGPS, I have a Mindsensors AGC accel/gyro/compass on another sensor port, and a Mindsensors relay driver on a motor port. The setup has the Mindstorms brick atop the boat in a small waterproof case (see attached photo) with a battery and motors below the case.

The program uses the dGPS navigation block to determine desired heading to a waypoint and the boat navigates there. What I’ve found is that after a few minutes (10+) the reported GPS coordinates become erroneous. They start to “walk off” in a direction different from where the boat really is located. I know this from the log file and from the reported heading that’s clearly in error. I’ve only been able to confirm this behavior on the boat after several minutes of operation,. I haven’t had the time to try to reproduce it (e.g. in my car). I’ve reflashed the NXT brick and there’s no memory space issue even with the log file being written.

Any ideas? Could it be a bad dGPS unit? I purchased it via Amazon two months ago.

2

wjpavalko, can’t thinkg of anything. Is the dGPS seeing enough horizon? Are the original coordinates accurate?

3

It’s on the water, so horizon is not an issue. Yes, the original coordinates are correct, but something happens after the Brick/GPS/Program has been running for a while. I’ve attached a plot showing the erroneous points. It’s not completely corrupted data, but clearly off from where the boat really was, which caused navigation to go haywire. I’ve yet to try with EV3, but I’d really like to get this to work with NXT.

4

Any more thoughts on this problem? Is there any way this is NOT a sensor issue? Could the NXT Brick be causing this? Could there be interference with the boat hardware?

On a related topic, is there a Navigation block for the dGPS in EV3 or just a Read block? I don’t see a Navigation block like I do in NXT-G. Do I need to use the I2C block?

5

Hey,

This could be a software issue with NXT-G. Are those’Bad’ points happening, time-wise, after the “good” points? I

We trust the NXT more than the EV3. I would stick with that. You might also be better off using RobotC or NXC, which we get super-reliable data from.

Is there any way you can run this with RobotC or NXC?

6

Yes, the bad points happen after about 10 minutes of operation. Weird to get realistic, but wrong GPS locations. I can imagine completely corrupted data if NXT-G was the problem, but the data is just shifted from the real points.

RobotC may be an option, but I have a relay driver for the prop that doesn’t work with RobotC. I’m looking at other options for the motor controller, so I will switch to RobotC if possible.

7

That is weird. I’m wondering if the last byte is somehow getting shifted or something, which I why I’m asking about the RobotC and NXC option. Bytewise operations are much easier in C than in Labview, which is a pain to work with (which is what NXT-G is based off of).

It sounds like you have a pretty advanced project. Please let us know how the C goes and if we can help with anything there.

8

Turns out I can use RobotC for the motor driver, so I’m trying that.

Q: Can you tell me the correct units for Lat & Lon in the C code? 8 and 9 digit integers? Decimals?

9

Trying RobotC. Do you see any errors in this code? When I run it, destination heading and distance are not correct.

#include “drivers/dexterind-gps.h”

task main () {

long longitude = 0;
long latitude = 0;
long utc = 0;
bool linkstatus = false;
bool destination = false;
int dest_heading = 0;
int dest_distance = 0;
long lat_destination = 26203967;
long lon_destination = 506132460;

nxtDisplayCenteredTextLine(0, “Dexter Ind.”);
nxtDisplayCenteredBigTextLine(1, “GPS”);
nxtDisplayCenteredTextLine(3, “Test 1”);
nxtDisplayCenteredTextLine(5, “Connect sensor”);
nxtDisplayCenteredTextLine(6, “to S1”);
wait1Msec(2000);
eraseDisplay();

DGPSsetDestination(DGPS, lat_destination, lon_destination);

while (true) {

// Read the sensor’s data

utc = DGPSreadUTC(DGPS);
longitude = DGPSreadLongitude(DGPS);
latitude = DGPSreadLatitude(DGPS);
linkstatus = DGPSreadStatus(DGPS);
dest_heading = DGPSreadRelHeading(DGPS);
dest_distance = DGPSreadDistToDestination(DGPS);

nxtDisplayTextLine(2, "UTC: %d", utc);
nxtDisplayTextLine(3, "Lon: %d", longitude);
nxtDisplayTextLine(4, "Lat: %d", latitude);

nxtDisplayTextLine(5, "Head: %3d", dest_heading);
nxtDisplayTextLine(6, "Dist: %6d", dest_distance);

wait1Msec(500);

}
}

10

I’ve tried the above code with 8 digit lat/lons too and I’m getting bogus angle to destination and range to destination. Is there anything obviously wrong in that code? Works fine in NXT-G.

11

Update: The reported distance to destination and heading to destination do not appear to be affected by what I send in via the DGPSsetDestination() function. Even sending (0,0) returns the same DGPSreadRelHeading and DGPSreadDistToDestination values.

Any ideas?

12

Update: I tracked this down to an error I made in polling the dGPS too often. I originally included the dGPS calls in a control loop for the rudder, but that wasn’t necessary. Changing the dGPS calls to 1/2 Hz solved the problem.

13

Excellent. I should have mentioned that but I haven’t worked on the dGPS in a very, very long time. I’m sorry for the additional hassle.

Best practice is to make sure you’re not polling the dGPS more than 1HZ. Since the GPS module isn’t updating any faster, it’s not necessary to do this (and you’re probably not moving faster than 10 meters per second with a LEGO device as well).