Status Glitches with Pixhawk APM driver

[Jefferson Romney]

I have had a problem this week in my testing of the Piksi driver on Arducopter 3.3 on a pixhawk.

The reported status of the GPS will randomly glitch and Report 1 instead of a 5 causing the Pixhawk to momentarily switch back to the Ublox GPS and therefore twitch or sway depending on the length of the glitch. It lasts anywhere from 0.1 sec to 2 seconds while in level flight with clear skies.

I have my doubts though that the piksi is actually losing it's RTK fix because from my understanding of RTK, which is admittedly very limited so I could be wrong, if it really did completely lose the RTK fix, it would take longer than 0.1 seconds or less to get it back. And even then I think it would go from 1 to 3 to 4 then finally 5. So this jumping from 5 to 1 and back to 5 in a tenth of a second doesn't seem realistic. 

On the other hand, In my sample size of 2, I noticed that it was worse with 2 separate datalinks than when using the inject GPS function of Mission Planner. This causes me to think that it is a datalink problem and that with 2 separate datalinks, they were getting interference where with one the interference was limited. But if this were the whole problem, why does it not switch to float-RTK while it regains fixed-RTK?

Is this a bug in the driver of APM, or is there something happening that I can't see in the logs, or did it really lose the whole fix and get it back in 0.1 sec? 

I could be wrong on this as I am no GPS expert but I am really excited to get this flying stably and this is really my last hurdle.

I have attached some screenshots of my graphs.

LATvsGPS_STATUS:  this is my first flight this morning.  I have scaled the Latitude to fit in the screen, but you can see when the glitches happen, it switches and the Latitude starts to slew toward the reported position of the Ublox then RTK returns and it slews back but the copter has reacted already and is in a different spot. For this flight I used a separate data link for the Piksi's and the Telemetry.

NTUNvsGPS_STATUS:  This is my second flight. I used the inject GPS function in mission planner for the solutions this time and it seems to have helped although there could have been other factors that influenced it. You can see the same thing here though just less frequently.

[Henry Hallam]

Hi Jefferson,

I'm not personally familiar with the APM stuff, but there is at least
one possible explanations for why the Piksi might momentarily drop out
of fixed-mode RTK before quickly regaining it: Communication problems
between base station and rover Piksis. If the rover doesn't see base
station observations for more than 1 second it will stop providing RTK
fixes. But once they resume, if the lock counters haven't changed
(indicating phase lock was maintained on both ends), it can resume RTK
navigation

Whick Piksi firmware version are you using?

Cheers, Henry

> --
> You received this message because you are subscribed to the Google Groups
> "swiftnav-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to swiftnav-discu...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jefferson Romney]

Thanks for the quick reply! That would explain it actually. I didnt know it could regain a fix like that. That also explains the variation between the first and second test because the thing I changed was the communication method between the two Piksis. So sounds like I should just increase the integrity of the data link between the two and that should solve the problem. thanks!

[dzo...@swift-nav.com]

You may be experiencing timeouts in the SBP driver that reads the data on the serial port from piksi due to dropped packets between Piksi and pikshawk. I believe the driver is configured to go to status '1' if it hasn't received a position message in one second. From dataflash log analysis, which logs raw sbp, we see periodic "holes" in the data which don't exist when the data is recorded via other means. It is my hypothesis that the a buffer is being filled up before pikshawk has a chance to read. We are working to reduce any extraneous sbp messages in the integration as to help ensure that no information from piksi is thrown away between reads by ardupilot.

[Jefferson Romney]

That would explain it too. I guess that would mean on the one flight the buffer was filling up faster?  The datalink was likely faster that flight, but I think the connection between the autopilot and the piksi was the same I can look at the logs and find out. Thanks for the info. If this is it i hope we can get it fixed quickly.