I wanted to ask whether other people have had any stability or any reliability issues (including maybe working in mild temp. that may still affect the pixhawk4) that manifest as control instabilities especially in yaw (with compass variance and velocity variance errors) using Holybro Pixhawk-4 with copter 4.0.5 and Holybro F9P H RTK GNSS unit (using standard GNSS navigation not RTK).
I have not found a previous post in this topic. If I missed something - I would appreciate a pointer.
I have both p4 and orange cube. I think most of the “instability” I experience comes from the cheap motors and esc I had. These cheap motor tends to overheat very fast.
Other than that, the only issue I had is with the gnss. Clearly it can’t compares to orange cube. But other than that, its about the same.
It’s not common for people to highlight issues with the Holybro Pixhawk4 itself so there may be a few things you can do to improve the situation. We would need a .bin log where the issues are occurring to know more. And also a list of major components and maybe a photo will help.
Certainly a Cube Orange is high end, but if there’s external physical issues it may not do any better, or maybe just be better at masking the issues. You would have to make a decision on the intended purpose too, about whether a more expensive flight controller is warranted for what you intend to do with it.
No necessarily because it depends on size, adrone type and most importantly budget. Orange cube, cuav uses high end parts but price is also much higher.
The size is also bigger. If you are using something smaller than 550mm drone orange cube might be alittle big.
Of course if you got the budget you can use the best for everything.
Components are the pixhawk-4 and F9P H RTK - both holybro. Which other components were you referring to @xfacta ?
Per size of orange - completely agree.
Can you recommend on methods/protocols/docs to tune the EKF2 , still within the normal range so as to address such issues? i.e. for instance the GATE params or others ? ref the tuning parameters section here EKF2 Estimation System — Dev documentation
You shouldnt need to specifically “tune EKF2”. It’s behaviour and default settings have been worked out over years and millions of flights (not to mention all the theory and maths). This learning and experience now carries over into EKF3. If you just want your multirotor to fly properly then it’s a well-understood process with plenty of documentation and examples of the process.
I can only assume you are worried about this Altitude versus Desired Altitude problem. It’s the only strange thing I could see in the log. Please say of there is some other specific issue.
You’ve got quite a few warning messages all related to position
I would look at reducing Z axis vibrations before flying more. Although not in the official danger zone they are getting into that grey area of “no one is sure what will happen” and clearly you have some issues going on there.
Also try GPS_GNSS_MODE,65 to see if that helps with the GPS glitches. A combination of an unsteady stream of GPS data and poor IMU position (vibrations) will trigger those GPS glitch messages.
Any reason you have every flight mode set to RTL ? What if you need to take control in Stabilize mode or even AltHold or Loiter?
You should definitely set these:
BATT_ARM_VOLT,22.10
MOT_BAT_VOLT_MAX,25.20
MOT_BAT_VOLT_MIN,19.80
Your MOT_THST_EXPO looks wrong and probably should be around 0.75 to 0.8
Just asking, but what’s with Bat and BAT2 having different scales? You should fix BAT2 or disable it.
After all that, your aircraft is quite responsive and relatively stable. You should be able to set up the Harmonic Notch filter and run Autotune once the vibration problem is fixed.
Next time just try some gentle hovering and movements, ascents and descents. No need to test to absolute limits at the fastest rates possible, that just hides problems amongst the data. Wait till everything is just right before that sort of testing.
I was actually also concerned about the divergence of the SV and SP of the NKF4 param as shown below. That occurred on almost all of the cases
Would you have any insights into this behavior?
Per the GPS glitches NSats vs Hdop does not indicate issues I don’t think so not sure why I get these throughout the flight. These glitches appear to show up and be cleared in about 10 sec but I don’t see that in the Nsat vs Hdop curves.
As I said the GPS glitches appear as a warning that GPS position and calculated position from IMUs using gyros and accells has diverged. This is almost always due to vibrations.
Rule 1 = fix vibrations, especially Z axis
Rule 2 = test fly and check logs for vibrations
Rule 3 = fix vibrations again until they are low
Rule 4 = attempt more tuning only if vibrations are fixed
Rule 5 = any more issues, check if they are vibration related, go to rule 1
Again - appreciate the advice Shawn.
Per the z-vibes, although within the normal range under 30, what should a normal difference b/w x/y and Z. Best I can observe now is below
Despite having relatively ow vibes (below vibe Z on right) - I still experience in flight EKF failures that I think begin from issues related to velocity innovations (left axis) but not certain yet on the real root cause.
In any case - I am using Holybro F9P configured for G, R, E, C constellations and L1/L2 - so I set this param to 0 to keep it all as configured on the F9P and I am running at 5Hz which is the default according to Holybro I believe.
I am not sure why using this param would affect the timing between updates?
Sure understood @Allister , but should there be an issue using all constellation on L1/L2 with the pair pixhawk4 + F9P from holybro and that’s why it is recommended to utilize only G and R sats? Is there some known issue on pixhawk4 side to handle 4 constellations at 5Hz?
Also, how is this mask connected to timing if at all?
I think the issues may be related to data traffic, possibly bursts on the I2C of the F9P.
I am thinking it may happen since I am trying to record RAWX messages as well for PPK purposes. I am not using RTK.
So I guess the question is what’s the recommended way to add the RAWX/SFRBX messages using the F9P with G,R,C,E,SBAS sats configured normally for navigation?
Use I2C for the NMEA only and RAWX/SFRBX on UART1?
Have all messages including the raw data on I2C?
UBX only on I2C and raw on UART1?
All on UART1? (say ubx and raw or just NMEA and raw)
