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 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!
@RPM,
thank you
100km/h = 100,000 m/ 3,600 s rounded to 28 m/s
if you fly your drone slowly at 10 km/h so 1sec GPS offset calculated is 2.8 m
If your GPS is clocked at 10Hz and no latency is generated by Pixhawk code, motors control loop, don't expect better GPS accuracy than 0.28 m irrespective your GPS is RTK, L1 RTK , L1/L2 RTK
Since GPS can be clocked at 3Hz, 5Hz, we can assume 1m GPS geolocation accuracy error by default.
Drone is fast moving Rover, so geodesy grade GPS accuracy doesn't work for it.
In the worst case, as calculated by RPM, if you fly a drone at 100 km/h and your GPS is clocked at 1Hz and Pixhawk code execution latency is set to 0 miliseconds, you can still expect 28 metres GPS error.
I am not sure if this is one of the main causes of drone fly-aways but should be checked and verified..
@Bernardo,
If I recall correctly, GPS + IMU (innertial navigation) has been already embedded into Pixhawk controller.
Wish you success at Barcelona Mobile Congress.
Darius, here is a sample data set I've found.
The data is logged straight into the RTKite as NMEA and converted to KML.
The test was done at ground level, with the RTKite mounted on a bike, moving fast, on a park surrounded by buildings, and tall trees. Nightime, half overcast.
The log is at 10Hz, and done on strict RTK, without postprocess edition or cleanup, it is raw out of the receiver. The correction source was the freely available CatNet CORS sending GNSS RTCM3 at 1Hz.
One recording is Dynamic and the second recording is static, meaning that the receiver was not moving, but it was recording dynamic RTK at 10Hz. (You will notice a spike at the end of the recording due to the body covering the antenna while stopping the recording)
You can use Goggle street maps to see the surroundings. Urban canyon with high multipath noise.
https://onedrive.live.com/redir?resid=37E7F12A3066E006!8606&authkey=!APw8x_phbmoB6U8&ithint=file%2czip
Looking forward for your comments.
(I think my past comment was lost)
Darius, it seems an interesting test. I will supply you some sample data at 10Hz RTK. (we are in the midst f the Mobile World Congress)
Actually we give 10Hz for fast moving applications on both air and ground, so there's no problem.
Besides that and considering the faster fixed wing drones, and in order to geotag at 150Hz (nearly instantaneous) the internal algorithm uses the XYZ acceleration to readout the precise spatial location when the camera shoots.
@Darius, is that a straight comparison from km/h to m/s? If so, 100km/hr rounds to 28m/s
@Bernardo,
@Anton,
I would like to support your L1 vs. L1/L2 GPS accuracy challenge at my Open FabLab.
What is offered by Bernardo is ground station + rover configuration known from geodesy.
Rover in geodesy is not mobile or is slow moving GPS rover and geolocalization is calculated at fixed point.
The opposite configuration comes with a drone.
Drone is fast moving gps rover.
GPS is clocked 1Hz - 10Hz
drone controller, motor controller are clocked by code loops at known timing.
If your drone flies at 10 km/h forward speed , so about 3 cm/sec
If 100 km/h, so 0.30 m/s
so if GPS clock is slow and controller processor is slow (not real-time)
don't expect better than 1m accuracy since latency counts and calculated fix
is always the previous fix, since drone is moving fast.
Since GPS raw data can be saved to a file and postprocessed,
just record GPS and RTK data files and let us verify claimed accuracy of L1 vs. L1/L2
technologies.
a brief note on L1, L2, L5
http://geoconnect.com.au/gps-signals-l1-l2-l5/
Dear Anton, kindly write to emea@northgps.com to have every detail.
As said, your R+D looks promising. Cheers!
Good day Bernardo
I will forward you all the data I have for your perusal. I am not in R+D phase but am moving to production. The environments I have tested in is in a vehicle driving on the highways at 120 km /hr. Flying a Jabiru 4 seater plane at around 200km /hr and then in mopani veld as well as under tree canopies in the Caprivi strip in Namibia
I am not looking again to start an argument but simply indicating that L1 has been neglected over the years and that you cannot compare results from an autonomous GPS to a GPS capable of dong RTK
For what it is worth we used a Leica 500 and our GPS in the plane with both the antennas inside the plane behind the passenger seat. The performance was identical. I would be interested in getting one or two of your L1/L2 receivers and put them on my GPS to evaluate then against the L1 receiver I am using now
What would the cost of the receiver only be?
Regards
Anton