ArduPilot does all that automatically for you. What exactly do you want to change?
1 Like
Not only that, but NMEA doesnât carry enough info to create RTCM3.
1 Like
Hi @Yuri_Rage and @amilcarlucas Thanks for your responses.
Yeah! currently I am using the RTK GPS system and it is working great. I just want to see the possibility of making this configuration work with non-RTK GPS, this is just for my understanding and learning.
I just want to take the raw data from the non-rtk gps and process it in my system/computer and send the generated RTCM3 data (after processing the raw data) to pixhawk as a correction for the other gps.
it seems like the .ubx format is the raw data format from the GPS. If I can get this kind of output format from the GPS, is it possible to make it work?
Could you please explain a bit more about what I might be missing here? I understand it might be a bit challenging, and not worth as the existing RTK GPS setup works well, but Iâm curious and want to give it a try.
I apologize for bothering you with this again and again. Thanks!
If youâre using a non-RTK capable GPS, itâs unreasonable to expect that it will have the data required in its output stream be able to craft RTCM3 corrections. I assume this is all to try and save a buck, but the new dual antenna system from CUAV is so affordable that itâs hard to justify a kludge like you suggest, even if it were possible.
1 Like
It is simply not possible. The atmospheric corrections required for RTK operation are only available on RTK GNSS receivers.
It does not matter how much ammount of processing you do on .ubx raw data from a non-RTK receiver. You will never be able to create a proper RTCM datastrem to feed into a RTK receiver. And feeding it to a non-RTK receiver will not improve it in any way.
1 Like
I totally understand it, working on to find the data required to generate the RTCM3.
Actually, it is not like that. There are two reason for that, First is; for my understanding and learning and second is; to change the shape and size of this configuration. Nothing much.
I will give it a try and see if it works, do you know any library or software which can generate the RTCM3 data from the raw data? Thanks!
Totally agree, thatâs my concern. That might impact big on the performance.
Yeah! you are right, I have to find a way to correct the other gps data based on the first gps RTCM data and then feed it to the pixhawk. In this case, there is a chance to make it work. Thanks!
I fear youâre wasting your time. GNSS hardware is a multi-billion dollar global industry. Donât you think if it were possible to get cm level precision by processing data from a cheap receiver that someone would already be mass producing such a thing?
3 Likes
Hey @Yuri_Rage, You make a good point, and I want to clarify that I donât need super-precise measurements down to the centimeter. If this setup can give me slightly better results than a regular GPS, thatâs perfectly fine. My main focus is on improving how it calculates the Yaw direction, even though I understand it wonât be super precise in that regard. Iâm comfortable with that limitation; I just want to test how well it can estimate Yaw.
Thank you for your input, and please donât think Iâm arguing with you (I canât even think of that, you are like a teacher for me). Our back-and-forth discussion is incredibly helpful to me. I appreciate your advice, and I genuinely want to know your thoughts on using this setup for primarily Yaw estimation (just as a backup in areas with a lot of compass interference). Thanks 
You can not do GPS for yaw without RTK. Period.
You can also not improve non-RTK-GPS position with RTCM.
1 Like
I donât perceive an argument, but rather naive enthusiasm. You say you donât want cm level precision, but thatâs exactly what you need if you aim to arrive at a yaw solution derived from antenna position.
ArduPilot can already achieve an imprecise yaw solution by calculating it from GPS course and filling in the gaps with gyro data. It works ok but tends to get a little funky during sharp or pivoted turns. Read up on GSF.
1 Like
Hey @Yuri_Rage, Totally understood. I guess now I donât have anything to say and you are totally right, it will not work. I have tried to process the NMEA data and it showed errors (missing data) so dropping this plan.
Thank you so much for all the explanation and making me understand how it works.
Btw, I found something else to work on, I want to use optical flow sensor for flying in Non-GPS regions. I know there are few options available but range of detection is less and people are suggesting to use external ultrasonic or lidar sensor for height estimation.
So I am thinking to make my own custom optical flow using pi camera and Maxbotic sensor.
I know this is not related to this topic, will create a new thread just thought to ask you first here. Thanks!
Hey @Yuri_Rage, I hope you are doing good. After so long, I continued my work (have been busy in my academic work).
I am using the GPS for Yaw configuration and I noticed that the compass error shoots up as I make the yaw movement. I know GPS for YAW will not give results as precise as a compass can do. But I want to know, is it okay to turn off the compass and fly completely in GPS for Yaw configuration? (My compass is experiencing a lot of interference).
and one more think, what graph plot I should look at to see how good the GPS for YAW is working? here is log for your reference: 2024-01-21 11-39-45.bin - Google Drive
Looking forward to hearing back from you. Thanks!
I donât see an issue with disabling the compass at all, so long as youâve experienced good GPS performance to date. Thatâs how I run most of my Rovers, and GSF fallback takes care of any gaps in data. There should be no appreciable difference in Copter. The issue isnât precision so much as update frequency, but, again, I donât see an issue.
To analyze performance, look at EKF innovations in the log.
Graph XKF3[0].IYAW using Mission Planner like this:
Here you can see that the mean innovation for this brief but representative section of your log is 11.2 degrees, which is actually pretty high, and quite probably skewed by the compass interference that you mention. By comparison, my very noisy mower that uses only GPS yaw sees a max innovation less than that, with the average being 1-2 degrees.
1 Like
Thank you so much @Yuri_Rage for your quick response. I have disabled the compass, as per now I have set the EK3_SRC1_YAW=3 (GPS with Compass Fall Back).
You are right, it works really nice. The yaw degree innovation in hover flight is almost zero. I have flown some small mission and I noticed the error grows during the yaw turns but the EKF innovation is still under 0.5 (but yaw innovation went up to 7 degree).
What is the source of XKF3[1].IYAW? is it based on the compass data? If No then what is the plot for heading error of compass data? the XKF3[0] and XKF3[1] for yaw are almost same.
It estimates the heading by comparing GPS outputs to the IMU movements so if there is a lag in GPS then it calculates only based on IMU movement?
and can you please help me in one more thing? I am using mauch 100A sensor with Pixhawk 6C. I have put the voltage divider and Amp per volt values as per mauch instruction, it shows the correct voltage but the âprearm: battery is unhealthy errorâ is keep on coming no matter what BATT_CUR_PIN and BATT_VOLT_PIN I am using, so currently I have disabled the batt_monitor to fly but it is not safe.
Always looking forward to hearing back from you. Thanks!
If you have the compass disabled, then set EK3_SRC1_YAW=2.
The different log indices are for each EKF instance (one per IMU). They should be similar in value.
Look through all of the battery parameters and make sure they are set appropriately. You may have a failsafe parameter mismatched with the size battery youâre using.
1 Like
Thanks again @Yuri_Rage
No! I have not disabled the compass, I have set it as a fallback for EKF.
Yes! thanks, Number of EKF is always based on the IMU, as I have set the EKF source for heading to GPS so it is fusing each IMU with the GPS and plotting two graphs.
As I have not disabled the compass, can I still check the heading error by compass data? I just want to compare with the GPS heading error.
I have set the battery parameters correctly and cross-checked again now, I guess there is a problem in setting the BATT_CUR_PIN and BATT_VOLT_PIN, what values should I set for the Pixhawk 6C?
Thanks again for clearing my doubts.
Hi @Yuri_Rage I hope you are doing good.
In my last flight I faced a GPS glitch Issue which resulted in crash. This is the first time I am facing such kind of issue. I have read the wiki page about the GPS glitch error. I really donât know how come it happen? I was flying in a clear sky and in open farm, hard to believe that there could be a GPS glitch in such environment.
My GPS is UM982 based (Dual antenna), do you know what could be the best way to set it up? I did not set the GNSS_MODE to 2 constellations, I will set it properly. Apart from that is there anything else I should do to make sure that this GPS glitch issue will never happen again in future? I have mounted the GNSS receiver board on top of the Pixhawk & surrounded by the wires (but Antennaâs are away and properly installed), Can GNSS receiver also have the interference issue?
Just for the info, I have tried to check the logs but it is showing that FMT message is missing.
You can check the logs and other detailed info in this post: Gyro & Accel Error in Flight
Really looking forward to your insightful response. Thank you so much!
@scientist_bala , I am no expert so I only can give some brainstorming like ideas.
You first noticed Gyro & Accel errors followed by a Failsafe RTL. Additional you noticed a low power message. Now you noticed GPS glitch, was this the same flight as before or a following flight. Did you find out the reason for the low power message? Is it possible that you have ageneral power problem by some bad connections etc. ?
1 Like