A base station GPS at a fixed and known location is used in conjunction with the GPS on the rover.
At the risk of over-simplifying, the base station GPS and the rover GPS suffer the same atmospheric distortions, but the exact position of the base station is known. Therefore the error on the base station (due to the atmospheric distortions) is known. Hence this error can be applied to the rover GPS reading, and a very accurate reading obtained.
A far better explanation than this is at RTK Explorer.
|CSG NEO-M8T U-Blox GNSS (GPS)||Raw-mode capable of GNSS, supported by RTKLIB. Two of these will required for DIY RTKLIB / Kinematics.|
|Box||A box for the mast head on the rover.|
|150mm PVC cap||Base of roof-top enclosure for GPS base station antenna.|
|150mm PVC pipe||Sides of roof-top enclosure for GPS base station antenna..|
|150mm PVC threaded Cap||To attach lid of roof-top enclosure for GPS base station antenna..|
|150mm PVC threaded end||To make lid of roof-top enclosure for GPS base station antenna..|
|Raspberry Pis||One for the base station, and one for the rover. These can multitask with other things (security lighting etc).|
Water tight .. within reason. A USB cable goes out the bottom, and through the shed roof. It is protected from the sun by a length of irrigation tube. It's tempting to make the enclosure water-tight / air-tight, but the reality is that even changing air pressure (think hot day, cold night), will eventually result in moisture-ingress. A small hole at the bottom (or even a tiny gap around the antenna cable) will allow it to breathe.
The GNSS (GPS) is placed in an elevated plastic box on a mast made from PVC plumbing pipe and appropriate joiners, using as little metal as possible.
An LSM8DS0 IMU is also mounted in the mast head to distance the magnetometer from the metal of the rover body.
As little metal as possible has been used in the mast head box to avoid magnetic or RF interference. The bolts to hold the GNSS and IMU in place in this design are plastic. The PVC pipe and components use plumbing glue.
The elevated mast is a trade-off: The LidarLiteSweeper should be both as low as possible (to detect low obstacles), but be the highest point of the rover to get a 360° view. The mast will get in the way of the scanning, and will probably require software programming to remove it from view. This will create a blind-spot. If the mast is behind the LidarLiteSweeper, at least the blind spot will be behind the rover and not in front. However it does force a directionality into the rover, which in principle could be orientation-agnostic.
Consider, for instance a rover pushing a reel-mower (one of those old ones which powers the blades from being pushed by the operator). It would run forwards to mow grass, but backwards when moving to position, returning to be recharged etc. Orientation-agnosticism would be important there.
The lid in this image is clear, but after debugging and testing, the lid should be replaced with a opaque one to avoid the greenhouse effect - particularly as the GPS antenna is black.
RTKLIB requires a GNSS ground station receiver, as well as a GNSS on the rover.
It requires a quality GNSS which can receive phase information and transmit raw data.
This project used two "NEO-M8T U-BLOX" from CSG Shop (with built-in antenna). These are not high enough quality for high precision, but they are affordable. See below.
Recommendation: The NEO-M8Ts are only a single frequency (L1). They are not actually up to the task of precision location. They will do reasonably well in most cases (probably well enough for a large mower in a paddock), but not for a small mower with a 20 inch blade, or for controlling a tractor to do precision rows. These task require a higher cost GNSS receiver.
RTKLIB is tricky to get going, and could have a whole web-site itself. Actually it does, and it's still confusing.
Get started by doing thisBuy a suitable GNSS which is supported by RTKLIB.
The light green dots are the readings obtained from walking around the yard carrying the mast (attached to Raspberry Pi and a battery, obviously), superimposed over a map of the house paddock (ignore the solid blue line, it's a route for another experiment).
The GPS did pretty well in this test.
The missing dots on the east side of the garden shed (the eastern black square) are due to the WiFi signal being lost (the shed blocked the WiFi antenna, which is on the top of the homestead) as I walked past - okay for me, but a serious problem for a rover.
There are at least three other short (1s) drop-outs on the south and south-east of the walk. A better WiFi antenna on the rover largely solved this problem, though there are still times when rtklib can't find a solution.
This is a geo-log of the first time the rover followed a pre-programmed route around the house without being rescued along the way.
At the time it was only using GPS (U.S.) satellites not the Glonass (Russian) satellites, so the readings are a bit rough.
The thin blue path is the programmed course (starting at the north, going around the house clockwise), and the thicker light-green path (actually series of dots) is path the rover 'thinks' it took (according to the GPS logs).
The red blob north of the house is the final position of the rover (stopped after completing the course), and the tail at the start of the course is the path the rover took (autonomously) moving to the initial position to start the course.
There are some interesting features here.
1. This is the path the rover thinks it took - not where it actually went. In particular, there are some 'spurs' visible in the path up the western driveway, which did not actually occur in the path it took. The GPS reading jumped to the side, and rover 'corrected'.
2. The rover consistently overshoots when the course has a sharp corner. This is partly the crude path-following program (it doesn't change direction until it reaches the end of a line segment), and also due to the rtklib solution only arriving once per second - and often some time after the actual measurements if the rtkrcv output is to be believed. Hence the rtklib solution data could be up to two seconds out of date. so the rover frequently passes the turning point before it knows to start turning. Clearly the overshoots will be worse for a faster rover.
Here we have been running (stationary rover) for several hours, and almost all solutions are within 8cm. Not bad.
We can pick up the Glonass (Russian) satellites. The NEO-M8T will apparently pick up the Galileo satellites, but needs a newer firmware version and (disappointingly) U-BLOX don't seem keen to make this upgrade available to their user base.
A truckload of software to make this do anything sensible.
With regards navigation in particular, there are multiple inputs coming in from different sources which give clues about location, velocity, orientation and spin. Don't expect consistency between these. Don't even expect consistency between different GNSS streams (eg the velocity/heading is based on Doppler measurements, but the location is computed from timing information. Location may jump around madly even when velocity stays correct). This is a very interesting and challenging problem which might best be classified as 'open ended'.
telnet roverhostname 2833will let the operator see the feed from the RTK system. Good for debugging.
Currently the RTK position quality goes to FLOAT, but hardly ever goes to FIX, however the accuracy still seems to be pretty good - at least good enough for some agricultural purposes, though possibly not good enough for a domestic lawn-mower. 'Agricultural GPS' is normally expected to be around 100mm. A serious domestic mower will need to be better than 30mm to avoid the wife's flower beds.
There are a number of publicly accessible NTRIP casters on the interweb which broadcast base-station data which can be used instead of installing your own base station. With permission of Geoscience Australia, I tried using AUSCORS NTRIP broadcaster and read data from a server around 30km away.
The results, in one word: disappointing, with 2m drift common. The results are so disappointing, I have not even graphed them here [update: I think the problem was a misconfiguration with the Russian satellites, but I have not revisited this]. Maybe there is a source of error here, but overall I suggest using your own base station if you are serious about robot navigation.
None really, except ..
The system goes to FLOAT solution quite quickly, but only seldom goes to FIX. This is not a problem in itself, but others seem to be able to get the system to FIX, and have pretty much stay there. I have not achieved this with these GNSS units. Those who have enjoyed greater success also seem to be blessed with deeper pockets than yours truly - they have purchased more expensive GNSS units.
this will get a good solution for the price, but not get truly high-precision RTK positioning - you simply need more expensive (multi frequency) GNSS receivers to do that.
Also buying the combined NEO-M8T and antenna (ie the M8T is mounted on a PC board which acts as an antenna) seemed like a good idea at the time, but it's kind of inflexible. It would be nice to be able to swap around the antennas to try to find combinations that might work better.