I have a Pixhawk system with all the standard 3DR peripherals (telemetry radio, GPS). I need to replace the 3DR GPS with another GPS unit so that I can conduct some tests with higher accuracy. I have a Trimble RTK unit and others at work that I want to try. I have no problem setting these up for the desired output so that is not a concern. I really just need to understand the Pixhawk/APM:Rover side better.
I've tried to find information about the configuration of the GPS port, but it is very sparse. Everything seems to try to push the 3DR modules (which I already have so I'm not cutting into their profits). The most information I have found has been on the Pixhawk webpage (https://pixhawk.org/modules/pixhawk) which let me know that the port is 3.3 V. But, there is no other information. I know it is possible to use other GPS systems. I can see discussion on the developer board about support for NMEA strings and custom RTK GPS modules.
Specifically, I'd like to know:
1. What protocol is used for the GPS TX/RX lines?
2. If it is UART, what baud rate is expected? If baud is configurable, where is it configured?
3. Do I need to change an APM:Rover parameter? I have found GPStype in the list, but NMEA is the only one I readily know how to setup. Are the others special for certain parts or are any generic protocols that I just didn't recognize?
4. What NMEA strings can it interpret and how fast can it handle them?
Thanks for any help anyone can provide.
Replies
GGA was good enough for me.
I'm not sure on why you don't see the data.
We moved away from the Polulo broad as we built a datalogging board to constantly record the GPS coordinates. This board does the level shifting and passes the shifted signal to the Pixhawk.
It sounds like it works with a UNO so your shifting appears to work.
Is there any chance that all the grounds (GPS, level shifter, and Pixhawk) are not connected? Floating grounds often cause the communication problems you are describing. When using the UNO, it might be that everything is grounded through something like the USB cable you are using to connect it, but the Pixhawk might have isolated power. Make sure you are using the ground connection on the Pixhawk serial port and connecting that to the ground on the level shifter and to the ground on the RS-232 port on the GPS.
So I had some trouble with my pololu board today. When I first hooked it up everything worked but I didn't have the right cables so I made a very makeshift connection between two female DB9 ends. (One on the pololu and one on the cable coming from my gps). So I purchased a male male cable thinking it would just plug in and work but no. I tried switching the rx tx lines coming from pixhawk and nothing. It only worked after I redid the male end of the DB9 cable coming from my gps. You need to change pins 2 and 3. so from the DB9 cable coming from your gps pin 2 needs to go to pin 3 of pololu and pin 3 from gps needs to go to pin 2 on pololu. I don't exactly know why you cant just switch the rx and tx lines on the other side but it doesn't work that way. You have to switch the lines on the gps side of the pololu board.
Have you tried other Baudrates?
Did you ever get your connection to work? mine works I hooked it up as follows VCC to VCC GND to GND TX_fromPixhawk(greenwire) to RX_convertor RX_fromPixhawk(bluewire) to TX_convertor I used baud rate of 57600 some of the baud rate options on my gps didn't work. I output all 3 sentences at 5hz
With the pololu board, i never see nothing.
So, i take another MAX3232 based board, very cheap, but it's working very nice and i can see all sentences on the arduino UNO, but when connected to pixhawk on gps port or serial 4, with the good baud rate and configuration, nothing appear...
Hi Joe,
Thanks for the reply.
Ill take a look at the 2301a as it seems like a good choice.
Out of interest exactly which Trimble GPS were you using?
In some of my initial testing I have been struggling with getting the Trimble GPS (MS990) to output the NMEA GPRMC Sentence Type as it doesn't show as a supported sentence type in the Configuration software I am using (Configuration Toolbox).
Note, the other 2 sentence types were selectable.
Cheers and Many Thanks
Kia
P.S.
I have attached a photo of how my project is progressing. Shouldn't be too long until I can start with the electronics installation. Just waiting on batteries to arrive so I can finish the fabrication process.
IMG_0536.JPG
Hi Joe,
We support a fairly wide range of GPS types. The code doesn't assume it comes from 3DR.
The GPS_TYPE parameter controls what type of GPS is connected. The default is 1, which means to auto-detect. It then tries all types of supported GPS protocols at several different baudrates (4800, 9600, 38400, 57600 and 115200). Signaling is 3.3V, with a 5V supply on the same port.
For the trimble it should detect as a NMEA GPS. For a NMEA GPS it uses 3 sentence types, GPRMC, GPGGA and GPVTG.
One issue you may find for high accuracy GPS is that the uploading/downloading of mission items happens as 32 bit floats in degrees. That gives a precision of about 1m, which is not great. We are working on fixing that, but for now it is the best you can do for a mission.Cheers, Tridge
@Andrew_Tridgell,
do you if can it be gotten the $GPGSV, from the GPS that the Solo 3DR comes with??? I am interested in obtaining the SNR, PNR but I struggled doing it?
Thanks. I believe that answers all my questions about the connection. It sounds like you have made it almost plug-n-play. I guess I should have just tried plugging it in after level shifting the signals. I'm so used to these communication protocols being very picky and any deviation potentially causing hardware damage!
Is the accuracy issue only in the uploading/downloading? Do learned waypoints have the same issue? I remember seeing an announcement several months ago about APM:Rover being capable of cm-level navigation so I'm guessing the control code is at least precise enough. I once ran into the same issue in a MATLAB script I was working on so I understand the challenge. Fixing some code to enable higher precision might be something I could help with in a few weeks, but I'm guessing that it is likely a variable definition and computation change that affects a lot of code. In that case, is it something that only long-term developers would be able to successfully complete without introducing other bugs since a new person would not know where different assumptions have been made?
Thanks!
Joe
Internally it is all cm-level. It is just the mission upload/download protocol that is 1m level. We're working on a fix for that.
If you want to start trying to improve the code I'd highly recommend you learn to use SITL (see dev.ardupilot.com under simulation). Using SITL allows you to try things out much more easily.
Cheers, Tridge
-
1
-
2
-
3
-
4
of 4 Next