Dear friends, I would like to introduce you the RTKite GNSS RTK L1+L2 module receiver.
http://northsurveying.com/index.php/instruments/gnss-rtk-receiver
Designed specifically for Pro and Semi-pro UAV, Robotics and Industrial applications, it connects directly to the Pixhawk and other autopilots and is specific for millimetric Photogrammetry, LIDAR Scans, Themography, etc.
The RTKite is a full Receiver (not a basic GNSS board) with an internal OS that can connect directly to standard CORS stations with its embedded GSM/GPRS cellular modem, can be configured and operated by Bluetooth, COM or TTL communications and can be set with our freeware for Android, Windows PC or WindCE or Linux, or even with text string commands.
It also can receive and transmit RTCM or CRM correction signals by UHF radio or our unique AutoCaster system that allows direct link connection by the integrated mobile modem with an stable transmission range of 75Km on Fixed position.
In is in fact a miniaturization of our professional surveying RTK receiver SmaRTK, (first generation released on 2012), and is compatible with our unique AutoCaster system for direct Base to Rover cellular data link.
Below, an Autocaster test on a modified DJI drone with Pixhawk and the RTKite GNSS with the lightweight helical antenna.
Comments
@Anton, from the paper, as you can see, at 100Km, the position is already on the GIS range.
@ Darius
The Hexa characters are some noise from decompression somewhere on my data backup, not part of the dataset, please disregard that string. We ussually don't sample that kind of data so I don't have more around. Normally is binary Raw (For RINEX).
The 150Hz trigger geotagging is already implemented on the RTKite.
@David
Let me to finish the MWC and I'll send you interesting stuff, however on the other side of the Comm board we have the Cell modem, processor, Bluetooth and power line, plus the GNSS receiver in standard RTK shape.
@Anton
1083Km Baseline!!?? Are you considering RMS Error? Have you double checked with Known points on the ground?
Please allow me to be skeptical at this point but I have my share of GNSS surveying on my back and to get something usable on Static postprocessing with either L1 or L1+L2 it would require to record at least 1 hour and with a fair 50% chance of failure at a maximum 200km baseline.
Here is a paper about that: http://www.fig.net/resources/proceedings/fig_proceedings/fig2014/pa...
Good day all
As a matter of interest here is some data doing observations using a long base line 1083 km.
Startup to gps fix in 2.4 seconds and gps fix to RTK fix in 47.1 seconds I will create a separate blog for the L1 gps units after my meeting on Thursday when we will determine production etc.
processing cycle (ms) : 10
positioning mode : kinematic
frequencies : L1
accumulated time to run : 00:00:02.4
cpu time for a cycle (ms) : 1
missing obs data count : 0
bytes in input buffer : 0,0
# of input data rover : obs(13),nav(0),gnav(0),ion(0),sbs(0),pos(0),dgps(0),err(0)
# of input data base : obs(2),nav(0),gnav(0),ion(0),sbs(0),pos(2),dgps(0),err(0)
# of rtcm messages rover :
# of rtcm messages base : 1004(2),1007(1),1033(1)
solution status : single
time of receiver clock rover: 2015/11/03 07:45:36.499607960
time sys offset (glo-gps)(s): 0.000000000
solution interval (s) : 0.200
age of differential (s) : 1.500
ratio for ar validation : 0.000
# of satellites rover : 10
# of satellites base : 9
# of valid satellites : 7
# of real estimated states : 3
# of all estimated states : 112
pos xyz single (m) rover : 5053331.786,2704243.213,-2792763.961
pos llh single (deg,m) rover: -26.13055336,28.15304582,1610.299
vel enu (m/s) rover : 0.433,0.027,0.320
pos xyz float (m) rover : 0.000,0.000,0.000
pos xyz float std (m) rover : 0.000,0.000,0.000
pos xyz fixed (m) rover : 0.000,0.000,0.000
pos xyz fixed std (m) rover : 0.000,0.000,0.000
pos xyz (m) base : 0.000,0.000,0.000
pos llh (deg,m) base : 0.00000000,0.00000000,0.000
vel enu (m/s) base : 0.000,0.000,0.000
baseline length float (m) : 0.000
baseline length fixed (m) : 0.000
monitor port : 0
processing cycle (ms) : 10
positioning mode : kinematic
frequencies : L1
accumulated time to run : 00:00:47.1
cpu time for a cycle (ms) : 1
missing obs data count : 0
bytes in input buffer : 0,0
# of input data rover : obs(246),nav(9),gnav(0),ion(0),sbs(0),pos(0),dgps(0),err(0)
# of input data base : obs(47),nav(0),gnav(0),ion(0),sbs(0),pos(29),dgps(0),err(0)
# of rtcm messages rover :
# of rtcm messages base : 1004(47),1005(9),1007(10),1033(10),other3(9)
solution status : - fix
time of receiver clock rover: 2015/11/03 07:46:20.999583536
time sys offset (glo-gps)(s): 0.000000000
solution interval (s) : 0.200
age of differential (s) : 0.000
ratio for ar validation : 0.000
# of satellites rover : 10
# of satellites base : 9
# of valid satellites : 8
# of real estimated states : 3
# of all estimated states : 112
pos xyz single (m) rover : 5053359.684,2704261.595,-2792775.634
pos llh single (deg,m) rover: -26.13051570,28.15307624,1645.310
vel enu (m/s) rover : 0.000,0.000,0.000
pos xyz float (m) rover : 5053347.070,2704253.242,-2792766.823
pos xyz float std (m) rover : 0.108,0.083,0.058
pos xyz fixed (m) rover : 5053346.955,2704253.067,-2792766.716
pos xyz fixed std (m) rover : 0.021,0.014,0.010
pos xyz (m) base : 5279492.052,1703114.402,-3139092.893
pos llh (deg,m) base : -29.66932387,17.87921216,1043.089
vel enu (m/s) base : 0.000,0.000,0.000
baseline length float (m) : 1083218.481
baseline length fixed (m) : 1083218.377
monitor port : 0
processing cycle (ms) : 10
positioning mode : kinematic
frequencies : L1
accumulated time to run : 00:01:19.4
cpu time for a cycle (ms) : 1
missing obs data count : 0
bytes in input buffer : 0,0
# of input data rover : obs(409),nav(9),gnav(0),ion(0),sbs(0),pos(0),dgps(0),err(0)
# of input data base : obs(79),nav(0),gnav(0),ion(0),sbs(0),pos(48),dgps(0),err(0)
# of rtcm messages rover :
# of rtcm messages base : 1004(79),1005(16),1007(16),1033(16),other3(16)
solution status : fix
time of receiver clock rover: 2015/11/03 07:46:53.399565830
time sys offset (glo-gps)(s): 0.000000000
solution interval (s) : 0.200
age of differential (s) : 1.400
ratio for ar validation : 999.900
# of satellites rover : 9
# of satellites base : 9
# of valid satellites : 6
# of real estimated states : 3
# of all estimated states : 112
pos xyz single (m) rover : 5053344.356,2704254.176,-2792767.540
pos llh single (deg,m) rover: -26.13051775,28.15308315,1626.470
vel enu (m/s) rover : -0.040,0.024,-0.310
pos xyz float (m) rover : 5053344.359,2704254.177,-2792767.541
pos xyz float std (m) rover : 0.017,0.013,0.010
pos xyz fixed (m) rover : 5053344.356,2704254.176,-2792767.540
pos xyz fixed std (m) rover : 0.017,0.013,0.010
pos xyz (m) base : 5279492.052,1703114.402,-3139092.893
pos llh (deg,m) base : -29.66932387,17.87921216,1043.089
vel enu (m/s) base : 0.000,0.000,0.000
baseline length float (m) : 1083219.681
baseline length fixed (m) : 1083219.681
@Bernardo,
I get extended ASCII set characters
$GPGGA,190827.70,4122.6723462,N,00208.8389077,E,4,07,2.0,32.0143,M,49.441,M,01,0339*68
$GPRMC,190827.70,A,4122.6723462,N,00208.8389077,E,000.020,052.5,210915,-0.0,W,D*06
u�v���
��1��1�.� nt#d o�zΈ�օ@@ u�6� T @t, �Y)� y� � �q o*'�=hN�@5�� ��� �?B6�� ��h� Y$GPGGA,190827.80,4122.6723466,N,00208.8389079,E,4,07,2.0,32.0180,M,49.441,M,01,0339*62
$GPRMC,190827.80,A,4122.6723466,N,00208.8389079,E,000.013,069.1,210915,-0.0,W,D*0F
Lines 55 and 56
unzipped file RTK Dynamic at 10Hz.txt
BTW
I really love Barcelona
@John,
competition is high on GNSS market, more than 1000 GPS sale offers from Alibaba, Aliexpress.
GPS alone, L1, L1/L2 , L1/L2/L5 RTK or not RTK, DGPS
make no money since what matters is high precision GPS integration.
Interest is in 1m accuracy all-in-one RTK GPS at $100
There is no such market solution offered yet since GPS has slow clock (1Hz - 10 Hz)
not fir for drone high-speeding or high-speed orthophotogrametry, surveying, fotogrammetry.
GPS is SLOW by default to offer any accuracy below 1m on drones.
IMU integrated GPS navigation is highly complicated, algorithms offered for personal (drone) use are not reliable.
Bernardo is exactly right, GPS should be clocked 150Hz to work for mini drones and to provide geolocation accuracy when speeding.
Since GPS can offer 10Hz or 15Hz max, support should come from inertial IMU navigation.
Inertial navigation technology is 60 years ago but is not offered for personal drones.
Drone's controller features generally slow processor to supporrt inertial navigation fully.
So Anton is right about his L1 GPS, since it doesn't matter if you buy L1 GPS, L1/L2 GPS, get RTK corrections.
Your GPS is still very slow, clock at 1Hz, 3Hz, 5Hz or 10Hz max.
To slow to support fast flying personal drones in mission mode.
@Bernardo,
Your product is very interesting and it appears that you have put a lot of hard work into developing it. Would you mind posting a picture of the back side of the system so we can get a better idea of the size?
@Darius
Double checked the files, all seems OK. My bad I'm a Windows guy.
Below some samples, of course this is not a normal log as we do not record every position but instead just the camera triggers, but it helps to show the 10Hz behaviour from using 1Hz common correction.
Regarding shutter, we fit it as per our user needs, we've seen any kind of cameras out there. We sample as soon as the signal is sent, so the best is that the camera has a fixed exposition.
Sample from the static (non moving) RTK:
$GPGGA,191239.70,4122.6672439,N,00208.8439116,E,4,07,2.0,31.8150,M,49.440,M,01,0339*65
$GPRMC,191239.70,A,4122.6672439,N,00208.8439116,E,000.009,131.4,210915,-0.0,W,D*0D
$GPGGA,191239.80,4122.6672441,N,00208.8439126,E,4,07,2.0,31.8097,M,49.440,M,01,0339*6C
$GPRMC,191239.80,A,4122.6672441,N,00208.8439126,E,000.020,070.7,210915,-0.0,W,D*02
$GPGGA,191239.90,4122.6672439,N,00208.8439119,E,4,07,2.0,31.8102,M,49.440,M,01,0339*63
$GPRMC,191239.90,A,4122.6672439,N,00208.8439119,E,000.003,082.1,210915,-0.0,W,D*0A
$GPGGA,191240.00,4122.6672443,N,00208.8439116,E,4,07,2.0,31.8091,M,49.440,M,02,0339*6E
Sample from the Dynamic:
$GPGGA,190825.10,4122.6723659,N,00208.8389196,E,4,07,2.0,32.0102,M,49.441,M,02,0339*6E
$GPRMC,190825.10,A,4122.6723659,N,00208.8389196,E,000.031,139.3,210915,-0.0,W,D*0C
$GPGGA,190825.20,4122.6723638,N,00208.8389202,E,4,07,2.0,32.0128,M,49.441,M,01,0339*6F
$GPRMC,190825.20,A,4122.6723638,N,00208.8389202,E,000.053,161.5,210915,-0.0,W,D*09
$GPGGA,190825.30,4122.6723639,N,00208.8389198,E,4,07,2.0,32.0131,M,49.441,M,01,0339*67
$GPRMC,190825.30,A,4122.6723639,N,00208.8389198,E,000.004,146.2,210915,-0.0,W,D*09
$GPGGA,190825.40,4122.6723651,N,00208.8389188,E,4,07,2.0,32.0094,M,49.441,M,01,0339*61
$GPRMC,190825.40,A,4122.6723651,N,00208.8389188,E,000.035,332.3,210915,-0.0,W,D*03
$GPGGA,190825.50,4122.6723646,N,00208.8389193,E,4,07,2.0,32.0118,M,49.441,M,01,0339*69
$GPRMC,190825.50,A,4122.6723646,N,00208.8389193,E,000.015,164.1,210915,-0.0,W,D*0F
$GPGGA,190825.60,4122.6723660,N,00208.8389194,E,4,07,2.0,32.0107,M,49.441,M,01,0339*67
$GPRMC,190825.60,A,4122.6723660,N,00208.8389194,E,000.038,015.4,210915,-0.0,W,D*02
$GPGGA,190825.70,4122.6723657,N,00208.8389201,E,4,07,2.0,32.0096,M,49.441,M,01,0339*64
$GPRMC,190825.70,A,4122.6723657,N,00208.8389201,E,000.016,080.5,210915,-0.0,W,D*09
$GPGGA,190825.80,4122.6723661,N,00208.8389191,E,4,07,2.0,32.0066,M,49.441,M,01,0339*6B
@Anton Strydom
Please do create a new blog post concerning your L1-only system. It will be helpful for so many of the people who are new to high accuracy GPS. There is a lot of misinformation out there.
Of course the potential accuracy of L1-only vs L1/L2 is essentially the same - within limits. I've been pushing the limits of L1-only systems for more than a quarter century now and am quite familiar with what can be done. That said though, I basically agree with Bernado Espinosa. Time is money. Most users of GNSS equipment aren't experts in GNSS. They just want something that works and for that a multiple frequency GNSS will always be more robust.
If you have a single frequency system that compares to a multiple frequency one in robustness and speed to a fixed integer solution - even if just over relatively short baselines - you will be in business.
@Bernardo,
Drone operator "Fly slowly"
One of NMEA.txt files opens with binaries
Google Earth for Android can't open your KMZ/ kml track, no track icons visible.
Have to set up Windows machine.
I am developing an algorithm to calculate geotagging offset if your mission is not a straight line track.
What is your shutter clock ?
To overlay images made in 2-row mission, geotagging offset for one row must be added and substracted in case of images shot in another row to get correctly matched geotagged imaginery.
Fly slowly, be aware of geotagging offset.
Darius, indeed as you comment, even 10Hz is slow for geotag,
Geotag is actually done at 150Hz.
However extra care should be take in order to consider the delay from the photo order to the actual shooting. That is why we recomment to read from the camera flash socket and have an stable aperture/light setting, so to be able to exactly log the moment the picture is taken according to the geotag.
And thank you for the wishes!
-
3
-
4
-
5
-
6
-
7
of 8 Next