Your log shows only a few minutes of waiting with high HDOP and a large disparity in satellite count between GPS1 and GPS2. GPS2 never gets an RTK fix, probably because things are performing sub-optimally overall, so it will not provide a yaw solution.
First, ensure that both antennas are mounted up and away from any other physical components that could cause interference or obstruction.
Next, try just giving it some more time to acquire and settle down. Wait 15 minutes, minimum, without moving the Copter. Make sure you have a very clear view of the sky with no obstructions. You may not have to wait so long on subsequent boot cycles, but wait longer than 3-4 minutes, for sure, especially with brand new GPS modules.
If that doesn’t work, perhaps reduce the number of GNSS constellations in use. Set the GPS_GNSS_MODE and GPS_GNSS_MODE2 bitmasks to only use GPS and one other constellation such as Galileo or Beidou. See if there’s a combination that improves the HDOP and fix quality for you.
Thank you so much Yuri for the detailed explanation. Yes! in this log, HDOP is high but I have tried few more times and waited for around 20-30 minutes and noticed the significantly reduce in HDOP (around 0.5) but still same issue.
Currently, I am not using RTK. I have read on the wiki that this configuration also supports without RTK. Do I have to change some parameter for that?
Actually, I am using 2 Ublox GPS from different companies (one from Foxeer and other BN880). Will that cause a problem? I know both might have different baud rate and frequency update rate and few other things but I can change to the same baud and update rate in the parameters and I have tried that but still it did not work.
What are the parameters I should change so that I can make both the GPS almost similar to make it work for yaw configuration? Is there any way?
Looking forward for your further response and help. Thanks again!
Moving baseline is an RTK setup by its very nature. You do not need external corrections, but GPS1 must be able to provide RTCM3 to GPS2 for the system to work. It is self-contained. In other words, the modules must be RTK-capable, even if you aren’t sending RTCM3 corrections from an external fixed base station.
Exactly what modules are you using? The disparity in satellite count is certainly explained by the differing models, and it’s entirely possible you’re using modules that won’t support the feature set you desire.
There are no magic parameters to set. What you’ve done so far looks reasonable.
Thanks again for the quick reply Yuri.
Actually, I am not using any RTK capable module, I am using the quite cheap Ublox GPS modules, both does not support RTK. All RTK capable modules are costly.
And I still don’t understand the need of RTK capable GNSS for this configuration.
“GPS Yaw estimation relies on the detection of signal delays from each satellite as they reach two separated antennas. The GPS system may consist of dual or a single module, but two antennas are required in each case”
The above information, I copied from the wiki and it makes totally sense. Can you please elaborate a bit the need of RTK enabled GPS for this? Sorry for the trouble, I know I might be asking the simple question.
Looking forward to your response and thanks a lot for helping me out.
Moving baseline literally means there’s a correction source onboard such that the second antenna can be precisely located relative to the first. Once the relative position is locked down, a heading (yaw) can be derived by measuring the angular difference between the two antennas and a reference frame (earth frame).
Just because external RTCM3 corrections are not required to determine this relative positioning, it does not mean that the system need not be RTK capable.
Thanks for the explanation @Yuri_Rage, I really appreciate your support and help.
Absolutely correct. It make totally sense. Correct me if I am wrong, in RTK the moving base would be connected to ground base to get the RTCM correction data and send the same data to the rover GNSS for correction (this communication happens through pixhawk).
When there is no RTK then what is the communication happen between rover and moving base GNSS?
What do you mean by relative position locked down? I have already updated the position of the both GNSS receiver, isn’t it how they calculate the relative position to each other?
Sorry for the trouble but I still don’t understand it. Thanks! would be waiting for your response. I tried to find it on my own but could not able to find the reason.
MOVING BASELINE (it’s in the name): the base module is on the vehicle, which provides corrections to the rover module, also on the vehicle. The rover module’s position is always precise, RELATIVE to the base module. As such, the heading from the base module to the rover module will change precisely enough to be captured as a heading reference for the vehicle as it moves.
There is NO REQUIREMENT for a fixed base station.
If you want to improve absolute position accuracy, a fixed base station can be used to correct the moving base’s position as well. This is common practice with ArduPilot, but it is not strictly required just to get a GPS-based heading solution.
Thanks @Yuri_Rage
Now understood, The moving base has to provide corrections to the rover module to make this work. So I need both RTK enabled GNSS to make it work.
I wonder how accurate the corrections would be from the base (as it is moving) and what would be these corrections about? As rover and base both mounted on the same platform.
I feel like that in this scenario the non RTK GNSS would also work, I understand they will not be as accurate as the RTK enabled one but there would be some slight chance to make them work. What do you say? I know I might be totally wrong but I just want to ask and clear my doubts. Again thank you so much for your responses.
It absolutely cannot work without RTK-capable GPS modules and such operation is definitely not supported by ArduPilot.
The corrections from the moving base are VERY precise and again only correct the position of the rover module relative to it. They are derived using satellite signal analysis to address precise timing such that any module receiving the correction data will be able to correct its position RELATIVE to the base.
Hey @Yuri_Rage
Now I totally understand it. Thanks for all the detailed explanation, I really appreciate it.
I am planning to buy 2 ublox ZED F9P_01B, I have found the wiki page which says it can be used for “GPS for Yaw Configuration”
The Zed-F9P is an excellent choice. Recommend you purchase ready-made modules such as those from ArduSimple, SparkFun, Holybro, or CUAV. If you just purchase the Zed-F9P surface mount device, you may find it challenging to create a fully functional breakout board for it.
Minor correction - the new offering from CUAV can do moving baseline without EXTERNAL corrections (without a fixed base), just like all other configurations for ArduPilot. The advantage is that both the moving base and rover are contained in one dual antenna module.
I hope you are doing good. I have tested the RTK enabled GPS and it is working like magic. It is really interesting.
I want to know something and learn about the working. If I take/fetch the 2 GPS data into the system and correct the GPS2 data based on the GPS1 (I don’t know how to do it but will definitely try to find a way) and then feed it to Pixhawk. Will it work this way?
I just want to give it a try but need to know your opinion on this. Looking forward to hearing back from you.
I apologize for any confusion, but I wanted to discuss something I’m not entirely clear on.
In order to make this configuration work, GPS2 needs to send RTCM data to GPS1. From my google search, RTCM data seems to contain correction data, including atmospheric, phase, and satellite position corrections, among others. This data is typically generated by processing raw data.
If my understanding is correct, could we process the raw data (NMEA) from GPS2 within our system (using some software) to generate RTCM data? This way, we could apply corrections to the data from GPS1. Is this a feasible approach? I’d appreciate your insights on this matter.
Thanks!