I have noticed that the Reach’s altitude can take a few minutes to settle to within half a meter of accuracy compared to the base station altitude while both on the ground. Also, I had an incident where I walked towards the copter flying at 3 m and the Reach altitude dropped 10 m, which caused the copter to climb 10m to compensate. (My GCS updated the waypoint’s altitude to compensate for the lower predicted altitude to hit the target altitude of 3 m.) It appears that 1 satellite dropped out of the solution. Went from 9 to 8 right before the drop in altitude.
It looks like it was slowly recovering, but I landed the copter to reset the GPS. What factors would help speed up the altitude prediction of the Reach and prevent rapid jumps like I saw in flight? Should I use continuous mode or fix and hold mode? It looks like it might help for USA locations to only use GPS satellites rather than both GPS and GLONASS satellites, have others found that true?
BTW, I am also using 10x10 cm copper ground planes for the base and rover.
(I have RTCM3 and ublox logs, but not Rinex. I’m having mixed results with the converter.)
I didn’t save the Rinex files only correction*.RTCM3, raw*.UBX and solution*.ERB on the base and rover. Can you work with those? I tried using rtkconv, but it didn’t want to generate the rinex files.
My initial impression from a systems standpoint is that I would expect the main problem to be interference from something associated with changes in prop motor speed. Your data shows interference to barometric altimeter and GPS when there are rapid changes to motor speed.
Make sure there are no common ground returns from motor and sensor circuits including GPS.
Basic systems designs include shielding of all transient producing circuits and leads. Sensor circuits are always best powered by separate power leads and grounds.
I have no idea what your actual wiring looks like, but I would look there first. I would not be inclined to suspect software first.
Second, it appears that the GPS response time is slower than the barometric sensor response time. I’m not sure what parameters adjust the Kinematic response, but this would most likely be different for each device.
I’ve processed your logs and could say that it’s hard to find glitch, because there’s no base pair for raw_201612142223 rover file.
Here’s what I can see at around 3:00 PM CST.
Also you use only GPS satellites, try to turn on GLONASS next time.
And I’ll be really thankful if you’ll send set of rover & base logs for one time in the future
Thanks! I’ll delete all my logs next time before I start. How did you convert to the Rinex format? If I could get timestamps out of the files, I could better correlate with what I saw in the Arducopter log posted above as well. The Arducopter log has GPS time, but I’m not sure what it date/time its referenced to. (midnight of January 5th 1980?)
I turned off GLONASS since it appeared that I was getting better solutions with just GPS based on casual observations.Will more satellites make it more robust or add more variability - how does more satellites impact the time to solution?
You should use RTKCONV from this post to convert raw logs to RINEX.
Try to do it with RTKPOST. You could find it in the same post.[quote=“rrr6399, post:11, topic:4608”]
how does more satellites impact the time to solution?
[/quote]
In some cases it could help to lower time (ex. small amount of GPS satellites), but it has more effect on robustness.
I figured out how to convert the GPS2.GMS time from the ardupilot log into UTC. Looks like its GMS is seconds of the current GPS week. The glitch occurred at GMS=334865 for the week of 12/14/2016, which ends up being: 21:01:05 UTC.
(Used this handy converter: GPS Time Calculator )
HI,
I’m curious about whether you found a solution for this problem. Hopefully, you have as I’ve seen later postings by you.
I just felt I should point out confirmation that motor transients can cause problems. See RTKExplorer blog on “RTKLIB on a drone with U-blox M8T receivers” posted a day or two ago. There is also a description for testing the drone tethered to earth.
Although you may have found a different cause in your case, I felt I should pass these results on to the Emlid Forum.
Turning high current devices ON and Off generate tremendous rf transients compared to weak GPS signals. The first step in eliminating this problem is to move antennas or receivers as there is no weight penalty. If that fails, try shielding cables, etc. Slight weight penalty. Be careful not to shield Reach module WIFI antenna. Finally, placing a small capacitor plus resister at motor control lines can help. The capacitor should end up being rather small, so ,fortunately there should not be be too much of a weight penalty. Too large will create excess motor current with risk of overheating motor drive components.
Search internet for “motor transient suppression”.
I thank you for this post as it is a good example to illustrate what the Emlid group has said many times. Thank you for the opportunity to illustrate this often overlooked system design problem.
