Should I expect a crash at some point?

Nervously I took the Spy 750 Y6 up for the first time in over 3 weeks (had a warm spell of 25F today).

In stab it flies great, then switching to poshold it seemed fine, but did the twitchy thing again for a few seconds here and there, then seemed to smooth out (subjective). I brought it down and hovered nearby where it stayed rock steady for a minute or so and landed.

So, what does it mean when INAVerr goes to 255 and stays there? From what I understand it is the FC not receiving data from the GPS properly. Apparently this copter has done it from day one since transplanting the PIxhawk and running on AC3.2 and 3.2.1, with the 3DR GPS and the current CSGShop Neo-M8N. These errors did not exist on the Y6B with 3.1.5 and the 3DR GPS.

Any help is appreciated.

Views: 2525

Reply to This

Replies to This Discussion

So that means there's 3 of us then! Guess I'm in good company... :-|

I've been browsing around in the code and -where I certainly do not understand every line- I got the impression that the error-count increases when no update from the GPS is seen where it's expected. 

Looking at the GPS updates, I can indeed see cases where there are gaps in the GPS timestamp. E.g. in the first picture you can see it skips stamps 602217200, 602219200 and 602220200. In the second picture you can see that this is around the same time where the INAVErr starts climbing from 0 to 39 (last column).

My question would now be to find out whether a message @ 602217200 from the GPS was completely missing (i.e. the GPS module is at fault or misconfigured) or whether it was missed/miss-interpreted (i.e. the ArduCopter SW is at fault). Not sure how to monitor all messages send from the GPS to the Pixhawk though?

Or there could be a HW issue similar between the 3 if us but that seems unlikely...

Here's the raw data in Excel for INVerr

I'm puzzled because the flight ended at 49xxxx and I don't recall leaving the power on after landing.

Here is the data as seen in MP. It's missing the time values, but I wanted to get this posted while I remember.......going to try another quick flight before it gets dark.

Very gppd!

I just check for M8N firmware update.  There is none yet available.

Do you know of a way to set Arducopter to interface the GPS at a higher baud rate?

How about update rate?

I just checked for GPS parameters.  There is a GPS_type1 and 2.  Apparently you can have 2 GPS's.  That might be interesting.  My type is set to 1 : auto.  Type 2 is Ublox.

I wonder what would happen if you set type to ublox.

The first graph above should read "GPS"

I flew for ~6 minutes. The logging was changed to 'Almost All'.

I also changed the ins_mpu6k_filter from 0 (default) to 20.  Default I believe is 42hz. I don't have issues with vibration, but have read that 20 can smooth out issues with "twitching" and such. It did seem to fly very well, but that's neither here no there for this topic.

I digress.

No logging was performed before arming. INAVerr was 255 straight across.

The GPS values, which I assume (nobody has said, just guessing) is the raw data used to capture the INAVerr. I'm not getting why in this case under PM it shows 255 throughout the flight, yet under GPS it varies. Having not studied the code to find how INAVerr is calculated, I'm probably totally off base.  I don't care to learn the code, it reminds me of work too much :) (is there a detailed summary of how to analyze logs?)  I just wanna fly and have confidence it will come back and in one piece.

The raw data from 'GPS'. So what do these data represent?

Nsat and Hdop

Vibration:

And the kmz. No gaps? Huh?

RE: Hans

I see what you're mean. It should be updating at 200ms (5hz) but is skipping a beat. All I want to  know is if the value of 255 (however that is derived) can cause the copter to malfunction. And if it can, why. That's it in a nutshell. What does the value of 255 represent?

According to the following reference, Pixhawk recognizes the Neo-M8N and automatically sets the parameters. All the user needs to is reset the GPS to default first using U-Center.

   http://www.rcgroups.com/forums/showthread.php?t=2353323

NOTE: When connected to either APM 2.xx or Pixhawk, the firmware recognizes the ublox GPS
and sends instruction to set the baudrate to 38,400, rate to 5Hz, turn off NMEA protocol, turn on UBX protocol, as well as other settings suited for use with APM and Pixhawk meaning that the "Default parameters" are irrelevant
as they are overridden by the APM or Pixhawk firmware.

I am getting this same error...I discovered this issue on the thread which discusses that the CSGM8N causes PM issues....and Randy Confirmed that this INAVerr could be a real issue....I have the Rctimer M8N as my primary while the CSGshop M8N as my secondary ..both of them show the same error even after exchanging both of them...any idea if his may cause a fly away or a crash ??

 

Looking at my KMZ file there are big gaps in between subsequent GPS updates ....I just went ahead and gathered the guts to fly an auto mission today and it went fine ...no issues but I get an intermittent bad GPS health message as well as the GPS glitch tune...I am attaching the KMZ file for anyone to have a look ...also my PM message has the APM speed error which shows almost 500 Slow loop lines...I am running a hexa-copter APM 3.2.1 latest stable release

 

Attachments:

AKcopter,

   If you post your log, I'd like to run it through Excel.

My log is very large almost 27 MB.....there is a 7MB limit here ...how do I post my logs??

Compress it (or not) and upload to Dropbox, Google Drive, Mediafire etc. then share it. If you don't want to, no problem, but the more people bringing this to the dev's attention, the more likely it will be addressed. Either it is a problem or it is not. To me there's no middle ground here.

I can't speak for everyone, but having confidence in the software/firmware is most important. If there are conflicts with hardware, it needs to be figured out or at least acknowledged.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service