I’ve been trying to set up reach and pixhwak (v1) receiving RTK corrections for that smooth RTL I’ve seen on youtube. However, It’s not working. So I wonder what am I possibly doing wrong and what should I do in order to make it work. There are two questions in this post, the second being the ultimate one.
Below I’ll attach the detailed description
both modules have the latest stable build - 2.2.5
both modules have ground plane, but rover uses seemingly bad one, I’d replace it soon (~8 green satellite bars on Base VS only 4 - on Rover)
Both times reach was tested in conditions with no buildings obstructing the view (30 degrees), the first time the test was taken in the fields
And it’s basically not working!
There are no grey corrections bars in Rover’s status - al it gives is just single mode.
So, I really want to know what am I doing wrong.
VERY IMPORTANT SECOND QUESTION:
a week ago at the other location I did manage to get corrections sent and displayed. The rover was indicating “Fix status” in ReachView However, Misson Planner was showing only RTK FLOAT and the drone basically WAS NOT using reach corrections - I strongly beleive that it was relying on my ordinary M8n GPS module (regular GPS Fix with 0.6 accuracy displayed in mission planner), as it failed to make any precise landing - and in pixhawk logs I found that the drone had ordinary GPS accuracy (btw, no signs of secondary reach GPS at all!)
So, what I want to know from you is:
What are correct settings for BASE/ROVER in case of Pixhawk
Can I configure GPS at 5Ghz update rate? or it’s not recommended?
Do I need to turn on Glonass AR?
What else is needed to get RTK FIX status in Mission Planner - and, as a result 5)What should I do to make pixhawk start using RTK GPS as a source for GPS data (cause right now it obviously isn’t using reach GPS even when it provides corrections.
Your help would be greatly appreciated!
Below you will find logs from my first attempt (float/fix issue) logs.zip (2.8 MB)
It’s exactly the same, only I use 38400 bauds as written in reach docs. I’d change that.
Also, during the first attempt I un-ticked the inject message type - however, the problem described was still there.
Anyway, I’ll test it on new settings and let you know
I’ve changed reach settings according to those provided in the other thread - but still no luck.
It seems that ROVER module is simply not processing corrections
So as you can see the base provides corrections which are processed by mission planner…and then they somehow don’t reach emlid reach
No grey bars in Reachview, no RTK status in Mission planer
did you set the correct parameters in missionplanner to use reach as a second gps? eg serial 4 as the 2nd gps and also the same baudrate as reach’s correction input baudrate?
also use the same baudrate for erb protocol output on reach;
Again no luck with reach. I’ve updated it to the latest stable version 2.2.7, rechecked all the parameters according to the link Igor provided…
I even flashed the latest apm.copter beta (3.5 - rc-3)!
Also, I checked custom 6-wire cable I got with reach. It is made parallel (1-1, 2-2…6-6)
and still, reach simply isn’t working.
Now, I’m pretty sure everything goes fine at least until Mission Planner - it does receive corrections from base, I see fluctuations in the sattelite level. But pixhawk doesn’t seem to recognize reach - I constantly have gpsstatus2 at 0. Maybe this is the root of the problem?
Obviously, I have all those MP parameters edited, with secondary GPS enabled, SERIAL4 protocol as GPS, correction sent to secondary GPS and baudrate as 57600
Here is my pixhawk parameters file RTK_setup_not_working.zip (4.0 KB)
What on Earth might be wrong? I need suggestions badly, as this is starting to freak me out.
P.S. Also, how can I check reach image version?
P.P.S I also tried to to enable secondary corrections feed to the rover in my local WiFi. I had no luck with that either…but look at IP for rover in reachview
The latest copter code uses a virtual 3rd GPS that blends inputs from both GPS units in a dual setup. I have not used it yet. Might be some new parameters that need to be changed.
From release notes.
Improved dual GPS support including blending (set GPS_TYPE2=1, GPS_AUTO_SWITCH=2)
I just tested yesterday with latest Reach 2.2.7 and ArduCopter 3.4.6 and it works fine. Although I must be behind on my Mission Planner updates as I do not show the signal strength bars in the RTK Inject screen. Anyway, I typically see the standard GPS go to Status=4 with about 18 sats and HDOP of around .6, and in really bad conditions I get Reach Rover to fluctuate between Status 4 and 5; each time it would hold 5 long enough the HUD would report GPS: RTK Float as expected. Ground tests only. Flight tests on Tuesday if all goes well.
I would recommend you revert to 3.4.6 stable unless you are keen on testing the new GPS code. At least revert back long enough to make sure RTK inject is working as expected.
Wow, glad to hear it works for someone !
Would you be so kind to tell me the version of Mission planner you are using? Also, could you please share the coper parameters file u’r using?
As for the Reach module: prior to getting RTK fix - which Status do you get for secondary GPS? I mean just after the powerup. Cause I have Status=3 and 17 sattelites with .7 hdop …but Status=0 for my secondary reach. Althogh I can see perfectly well in reachview that it sees some sats
Yup, I’ve checked that, Funny thing is, those new parameters are yet undocumented in param list - there are no expalations for these new numbers.
In fact, I’ve switched to beta only cause I was desperate to try something to make it work…failed there…I’d revert back to stable just as you suggested
Sorry for bothering you, but I’m so glad there is someone for whom it’s working
Wow, glad to hear it works for someone !
Would you be so kind to tell me the version of Mission planner you are using? Also, could you please share the coper parameters file u’r using?
As for the Reach module: prior to getting RTK fix - which Status do you get for secondary GPS in Mission Planner? I mean just after the powerup. Cause I have Status=3 and 17 sattelites with .7 hdop …but Status=0 for my secondary reach. Althogh I can see perfectly well in reachview that it sees some sats
Yup, I’ve checked that, Funny thing is, those new parameters are yet undocumented in param list - there are no expalations for these new numbers.
In fact, I’ve switched to beta only cause I was desperate to try something to make it work…failed there…I’d revert back to stable just as you suggested
Sorry for bothering you, but I’m so glad there is someone for whom it’s working
This is the primary issue that is likely causing the others that you observe. Even without corrections GPS status should not be 0. 0 means that Pixhawk does not detect any GPS data. Check your wiring and that position output on rover Reach is ERB.
I’m in the field right now. Well, I’ve managed to make reach connect - it does report status different from zero.
However, it still doesnt work! Despite having Fix solution in emlid reach - Reach reports rtk float status and HDOP of 0,91-0,81 in Mission planner, which is WAY worse than ,my m8n (0,6). What is more, when there is rtk float in reachview…I see only 3D DGPS and GPS2 status at 0 in MP (which means copter is using only primary GPS.
Now, by any means 0,8 HDOP is not RTK accuracy -it’s more of LEA 6H I had
I’m in a bare field with reach on for more then an hour, there is nothing around me, I have a fresh metal plate both for base and rover (16x16 cm), I’ve tried it on fresh tallysman antennae
And it still doesn’t work no matter which baudrate (38400 or 57600 as in telemetry), Glonass AR (off\on), sattelite constellation (+/- SBAS), refresh rate (1Ghz or 5 Ghz) I select.
And yeah, I have GPS_INJECT_TO set at 1
It’s really driving me crazy
Please, @igor.vereninov and other reach creators, tell me how to make your product work as advertised!
And I do envy you, @coby, for having it work)
HDOP is not a measure of accuracy, it simply shows how well are sats distributed over the sky. Reach will discard sats below 15deg elevation as they are useless for precise positioning, m8n does not mask sats by default and that is why you are seeing a lower hdop. This does not mean that Reach accuracy is lower. Your status is showing RTK FIX which means that accuracy is centimeter-level.
According to what you have posted everything works except that you see Float in MP when Reach shows Fix. And in this situation you should trust what Reach is showing, there might have been some status mismatch introduced with certain MP version. @coby could you confirm that this is an issue?
Sorry for repeating myself, but I would like to make it clear for everyone who reads this topic.
The effect of geometry of the satellites on position error is called geometric dilution of precision and it is roughly interpreted as ratio of position error to the range error. Imagine that a square pyramid is formed by lines joining four satellites with the receiver at the tip of the pyramid. The larger the volume of the pyramid, the better (lower) the value of GDOP; the smaller its volume, the worse (higher) the value of GDOP will be. Similarly, the greater the number of satellites, the better the value of GDOP.
I forgot to mention one thing: when I launched the drone and tried RTL it missed around ~80 cm from the lauch point. I repeated that aound 8 times, arming and disarming it after each try (this way homepoint was reset). And each time the drone was missing the spot by around 80cm (in different directions).As I guess it means that despite reach reported FIX … pixhawk had only good old 3D fix from m8n. Or it was relying on m8n, idk. Funnily, in reachview - Rover did have very small position fluctuatuin within RTK accuracy
So, as of now, I do think there is a problem somewhere between Rover correction output and pixhawk processing it. And I want to know how to overcome this problem
Actually, can anyone confirm working centimeter accuracy on Pixhawk with copter firmware?
And if there is - please, tell the version of MP/ firmware/ reachview
@igor.vereninov can you yourself confirm working conjuction of reach (2.2.+) and any stable copter firmware?
In this case I’d just repeat your setup
@igor.vereninov we have Saturday set aside for full day of testing. Will watch this closely and report back.
So far I have witnessed status go from 5 to 6 which is float to fix. But it would not hold fix. Really bad location so I was surprised to even get float after about ten minutes. Copter was sitting on ground.
I am wondering if this is related to the delay parameter for auto switch between gps1 and gps2. Might not be holding fix long enough for system to switch.
@ohiskyy if you search your full parameter list in mission planner for “gps” there is a parameter to force which gps is primary and you can turn the auto switch off. Sorry, on my tablet so don’t have the parameters names handy. So you could force the reach to be primary and turn auto switch off so it stays with the reach for gps. I do not do this because I am never certain about RTK performance when moving between different flying areas. If you are comfortable with performance of the Reach you can make it primary and only gps via parameters. But be ready to switch to stabilize if things get crazy.
All that being said 80cm is better accuracy than .6 HDOP which equates to about 1.2 meters with an M8N. Your logs should tell you what gps was in use.
Anyway, I’ll have a bunch more data after this weekend.
We are having very good flights with the default settings, but also note that on the latest Mission planner and running the latest Arducopter versions, we get a float message on the HUD instead of fix. However, I have seen it before change to fix. So Im not sure. Its a bit of a pain because we like to switch off the wifi on the Reach prior to takeoff, thus we cant see the actual status.
Don’t have any Reach logs handy. Just ArduCopter. Watched GPS status for an entire day of flights and RTK Float was reported a bunch. Don’t see a Fix at all. Based on what is reported here not sure if it’s an issue with churn in the ArduCopter code, Mission Planner code, or just poor GNSS performance.
