Read a GPS through a Serial Port

Hi Chief Delphi Community!

For a separate robotics competition (The Sparkfun Autonomous Vehicle Competition, if you were wondering) we are using the FRC control system. For the competition we have to autonomously navigate a course and race other robots around a parking lot, and we aim to do so by using GPS. We have a working GPS chip on an Arduino system that can output to a serial port, and so we would like to use the one on the cRIO to get the data. We have verified the chip can output the correct data using other software, but when we try to read it from the code, we get a bunch of nonsense. The baud rate is correct, so we don’t know why we are getting this data. Any help is appreciated! Thanks!

-Katy

 
package edu.wpi.first.wpilibj.templates;

import edu.wpi.first.wpilibj.IterativeRobot;
import edu.wpi.first.wpilibj.SerialPort;
import edu.wpi.first.wpilibj.visa.VisaException;

public class RobotTemplate extends IterativeRobot {
    
    SerialPort gps;
    
    int dataCount;
        
    public void robotInit() {
        try {
            gps = new SerialPort(9600);
            this.gps.disableTermination();
        }
        catch (Exception e) {
            System.out.println("something went wrong, " + e.getMessage());
        }
    }
    
    public void autonomousInit() {
        dataCount = 0;
        
        try {
            gps.reset();
        } catch (VisaException ex) {}
    }
    
    public void autonomousPeriodic() {
        
        try {
            System.out.println("DC " + dataCount + " " + gps.readString());
        } catch (VisaException ex) {}
        
        dataCount ++; //this is just to make sure our output is updating
    }   
}

Is the console out switch on the cRIO off? Make sure the cRIO isn’t imaged with the serial CAN plugin.

What serial levels does the arduino serial port use? Many microcontrollers use TTL levels, which violate the RS-232 spec. You’d need a level converter like the MAX232 to use it with the cRIO.

If you post the gibberish and an example of what the GPS sends, someone might be to make sense of it.

Yea it’s most likely that you need a logic level converter as stated above, because its working on a arduino which uses TTL.

The console out switch is off. I don’t have the data with me now but the next time we meet I can try posting some output. You’re probably right about the TTL thing, thanks! I will look into that.

BTW, most GPS modules output in serial in NEMA format anyway so using an arduino seems kind of unnecessary.

This bug report suggests that the Serial port in Java is broken:
http://firstforge.wpi.edu/sf/go/artf1596?nav=1&_pagenum=1&returnUrlKey=1369954540550

That was in January. Has there been an update for that?

I know there have definitely been updates since January 20, but I don’t remember seeing anything about Serial Ports. If that’s the case then this may all be a lost cause, even with a converter…

Alternatively you can read the GPS data via the arduino’s serial port, then send that data over I2C to the digital sidecar.

Hmmm… Thanks for the suggestion, we can check that out next time we meet.

If you use I2C to communicate between the cRIO and Arduino, be sure to “setCompabilityMode(true)” on the I2c object otherwise you will probably experience sporatic communication failures. Also, there is a bug in the i2c.java code that treats all sent data bytes (cRIO to Arduino) as signed instead of unsigned (java doesn’t have an unsigned byte), this causes it overwrite some bytes with a 255 (0xFF) when it combines the bytes into 32 bit integers prior to transmitting. This bug has been fixed for the next release of WPILib, but probably still resides in your code. You can fix this yourself if it becomes a problem.

Mike

No problem.

I wrote that bug… and it’s not fixed as far as I know.

Not being able to clear the read buffer makes the serial port quite useless. Any imput data just continues to stack up. So every time you read you get a complete history of the past data.

I tihnk you could recompile the source locally to fix the problem. I didn’t have a lot of data to send, I just used a bunch of relay channels for the signals I needed to send. It would be really nice to have a useable RS232 port though in the future.

Updated serial port files were just attached to the bug report in FIRST Forge.