Are you using USB 3.0? It creates havoc on GNSS receivers.
Make a test to disable INS FAST SAMPLE
Your link has an access requirement. Get rid of that for help.
Yes, you’re right.
Used to have a Navio2 and had those odd GPS glitch issues. Turns out many others reported the same thing. I was also very active on their forum but eventually closed my account as it became clear Emlid won’t do anything about it as they clearly focus on the GPS receivers for survey work.
This is further confirmed by a lack of any updates in recent years whilst there used to be multiple updates every year.
Also the price dropped of the Navio2 - at least in the US and I’ve questioned them about it.
Clearly they they just want to sell out remaining stock and stop with the whole thing altogether. - But they wouldn’t admit to that when asked on the forum.
The underlying issue is that for some reason the GPS data is being ignored at times leading to those GPS glitch messages. To make matters worse other sensor input can also be temporary delayed which causes a crash. I and many others had various crashes of that nature and hence walked away from that FC.
I’m now using a Pixhawk 6X and never had a sensor glitch or problem since then.
(The Navio2 is now collecting dust - Perhaps one day I’ll use it in a rover or boat but certainly not in any aircraft)
Like so many Raspberry Pi projects, this looks like a great idea at face value but doesn’t quite live up to the high expectations one might have. I love the Pi. I dislike it as the brain for an autopilot. There are far better options at similar price points. In my opinion, the Pi is far better suited as a companion. I do hope you’re able to solve the issue, and I’m afraid I’m not much specific help there.
thanks for your responses. I am sorry, I have now gave permission in my google drive so that anyone can access my attached datalogs. datalogs.zip - Google Drive
@amilcarlucas yes. I have a 4G LTE usb stick attached to the raspberry and in that way it is connected to internet. So, drone is connected to mission planner through a vpn connection. This connectivity is and was very robust and never had problems with it. I have the GPS antenna on a ground shield plate and its cable is wrapped with copper tape. This is the reason i bought navio2, to make use of raspberry’s capabilities. Regarding the GPS , as far as I udnerstood my signal was good with many sats and a high number of Hdop. Do you mean, that even with these facts, the USB connection still creates problems? Is there a solution to this, other than simply to not use any USB port at all ?
@juvinski I could try that tomorrow.
@dkemxr sorry, check link again. I changed permissions.
@Karl_Schoelpple i couldnt even find it in their products page anymore. Its like this product is hidden in their website. This is what i also understood, that they want to get rid of it.
Yes, re. website not having product listed anymore was also a question I’ve asked two years ago.
Unfortunately no matter what you do with the GPS it won’t fix the problem.
I’ve done some extensive testing back then to see if anything helps:
The underlying issues is that the GPS provides a consistent good data stream but the Navio simply ignores that at times. - This has been confirmed by various data collected and by some others who had the same issue.
It can be so bad with that issue that within seconds of each other you might get a GPS glitch message followed by an IMU glitch message which might then trigger a failsafe response.
- In my case the failsafe (landing mode) wasn’t such a good thing as it happened over trees. (Needless to say would also be bad over water) - As a consequence I’ve changed the failsafe setting in my system.
I also used the 4G connectivity back then. Alright for telemetry but not very useful for video transmission due to the delays encountered in signal processing. (not lined to Navio)
Here is some more info regarding this issue:
…and the list goes on…just search on the Navio forum.
You are switching to RTL and back to Loiter many times via the flight mode switch.
Number of Sats is good
HDOP is good
GPA.Delta is good
You just need to re-examine battery voltages and failsafes, then proceed with normal tuning and also set:
INS_ACCEL_FILTER,20
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
PSC_ACCZ_I,0.66
PSC_ACCZ_P,0.33
@juvinski @xfacta I have tried again a flight with INS FAST SAMPLE=0.
INS ACCEL FILTER=20 (was already 20)
INS LOG BAT MASK = 1
INS LOG BAT OPT = 4
For PSC ACCZ I and PSC ACCZ P i kept the default values of arducopter.
It looks like i didnt have any kind of problem during flight in Loiter mode. I didnt see any error messages in Mission Planer. If you can confirm that the datalog looks very normal i would be glad.
This is the parameters list i was using best_working_params_15082023.param - Google Drive
and this is the datalog 2023-08-15 20-31-13.bin - Google Drive
Thanks a lot
I meant to put INS_ACCEL_FILTER,10 sorry
These values should help a bit with holding altitude
PSC_ACCZ_I,0.66
PSC_ACCZ_P,0.33
and it is normal to set these after gaining a valid hover thrust value.
You’ve probably got some frame twist or motor mount twist, since Motors 1 and 2 (CCW) are working consistently harder than motors 3 and 4 (CW). Apart from impeding yaw ability slightly, it also generates a spread of noise frequencies instead of a nice easily-filterable band of noise.
You battery was starting to take the nose-dive into “relegated to bench testing forever more” territory. Definitely set the battery-related parameters I recommend and hopefully the battery will be OK.
I assume you have a 3S Li Ion battery, because a LiPo wouldnt have survived.
Looking at that latest log, I would set all of these:
ATC_THR_MIX_MAN,0.5
BATT_LOW_VOLT,9.30
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2 or 3
INS_ACCEL_FILTER,10
INS_HNTCH_ENABLE,1 // write this then refresh params to see the rest
INS_HNTCH_BW,40
INS_HNTCH_FREQ,88
INS_HNTCH_FM_RAT,0.7
INS_HNTCH_HMNCS,3
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.30
PSC_ACCZ_I,0.68
PSC_ACCZ_P,0.34
for this effect, they grey areas are where the harmonic notch filter will reduce the noise
If you can improve the frame twist or motor mount alignment, those peaks will be more clearly defined and we can improve the noise filtering further and be more targeted.
If it flies Ok after this, I would try a pitch or roll Autotune.
@xfacta thanks for all this valuable information.
Probably you are right about the motors 1 and 2 since it seems that their bearings is oscilating a little bit due to previous fall accidents of the drone. But anyway, I am now waiting a new quadcopter frame and will use it with another set of motors and a 4S li-ion battery.
I am using a Li-Ion 3S battery currently on DJI F450 frame. As far as i know the min voltage per cell is 2.5V for Li-Ion. So I kept it flying until i would see a total voltage of 8.5V while the copter was in air. Is that wrong?
I have a voltage meter attached to the battery to compare itsvoltage with the voltage that mission planner shows.
Mission planner was showing almost the same voltage with the voltmeter whily copter was hovering , but when battery reached around 9V, mission planner was showing much lower values compared to the voltmeter. I dont know why. Do you know any reason for this ?
Also, should i continue flying with INS FAST SAMPLE=0 ?
I will definetely try your parameter recommendations asap.
Thank for all support
8.5V is way to low. Lucky the ESC’s didn’t turn the motors off and cause a crash.
You should also set a battery low level which will alarm you when battery is getting low and also set a failsafe level which will trigger a landing when battery is at a critical level.
Those kind of basic settings are very important to prevent fatal crashes.
See also:
https://ardupilot.org/copter/docs/failsafe-battery.html
When using your voltmeter and comparing that to MP, did you have battery capacity and voltage divider set correctly?
https://ardupilot.org/copter/docs/common-power-module-configuration-in-mission-planner.html
the discharge curve for li-ion is not linier, most of the power is between 3.5-4.2v the voltage starts to plummet when the battery is almost empty 3v to 2.5v is probably less than 3% of capacity so you want to be landing before it hits 3.3v so you still have reserve. landing at 8.5v means you are landing as its falling out the sky.
@Karl_Schoelpple yes I have already set battery capacity and voltage divider and was seeing correct voltage in mission planner until the 9V mark. Below that, there was a difference between the voltmeter and missionplanner values.
@geofrancis Ok, so i will have in mind to stop flying and start landing as long as the per cell voltage in the air has reached ~3.3V.
Thanks for the info.
I have - since 4.1 a high load average in the beaglebone boards, and that was caused by the spi reading.
With ins_fast enabled the load is more than 5.0 meanwhile without that the load is around 1.0, and that was the reason or the behavior from an impossible flight vehicle - with high load average, from something flyable with a good performance.
I believe to confirm that, you can check the load average with the ins_fast enable and disabled.
In logs PM.Load and PM.NLon are key values to check.
I had looked at them in your log and they were acceptable.
Do a ssh or connect a monitor and a keyboard, login in the raspberry and run the top or htop command