Discussions

We are currently working on a DGPS solution for UAVs to improve precision up to centimeter levels. Our architecture is the following, we use two Ublox GPS with raw data activated, one for the base station, the other one for the rover. The rover GPS is connected to the Intel Edison breakout board that also receives the base station GPS signal through a telemetry (for the moment, we are also focusing on a 2G/3G/4G solution that would remove all range problems). Then, the Intel Edison runs the RTKLIB code that outputs a DGPS solution to the DroPix flight controller with Ardupilot 3.2.1 firmware. 

We have been running tests with GPS mounted on cars and dataloggers. The logs were post-processed afterwards with the library in order to obtain DGPS solutions.

Results were quite good in areas with wide sky views, worse in places with a high number of obstacles (trees or houses), where the solution became float or even single and the precision was completely lost. The high precision, when available, can tell exactly on what lane the car is and can even report the movements inside the road.

The static solution has a precision of less than 2 centimeters.

Mounted on a drone, the GPS has no line-of-sight problem and we get the fix solution most of the time.

This process also works in real time (no datalogger/post-processing), except that the flight controller does not get the signal. The Edison outputs NMEA sentences ($GPGSA $GLGSA $GPGSV $GLGSV $GPRMC $GPGGA) that are routed to the FC via serial communication (the TX of the Edison is connected to the RX GPS port of the Dropix, both other cables remain unconnected). We have been trying changing baudrates, frequencies and messages but in no way the FC would get the message. Does someone know how to communicate with the FC without having to convert the NMEA messages into UBlox binary protocol?