[TheOtherCliff]

If you have an east / west oscillation that seems worse when pointed in some directions (when flying in PositionHold or VelocityRoam or probably GPSAssist'ed modes) you might look at this post and use the DJI.c that is attached there to compile your own firmware to match whatever version of next you are flying.

https://forum.librepilot.org/index.php?topic=3012.msg21154#msg21154

[karla]

Okay will look out for it and if have that issue, will test the dji.c fix
Thanks
K

[karla]

This weekend I had some experience and development
Saturday:
Flying some 30 min with the clone dji gps and concluded it was off some 11 to 29 degrees from direction of north, compared to my iPhone. Not always but randomly. Also showed toilet bowl OR slow oscillations in PositionHold (using AttEstAlgo= INS13+CF).
Decided to swop it for a genuine DJI unit (as much as anyone can check its genuine



The reason I did this is because I have another 450 heli with a dji unit and naza-h flight controller that can hover position hold rock steady. So at least the hardware will be okay.

Sunday:
After a 30 min wait and a really good GPS fix I redid the mag calibration. After that mag only off 0.1 - 0.3% and always green during the 30 min flights following. The dji mag and my iPhone agree all the time where north is located.

However, in Position hold it first hold position well but then increasingly start to move around on its own.
I can not determine if this is a toilet bowl behavior or the slow est/west oscillations.
I know this video do not give a clear view of whats going on but if anyone can spot the difference please check it.
Stab1 = rate mode, just lift off
Stab2 = attitude mode
then, Pos hold
then, VelocityRoam



B t w Altitudehold is rock steady and just a delight. Always something

[TheOtherCliff]

An easy way to see how much the GPS drifts is to leave (not flying) in one place on the ground, bring up the Flight data page, then wait a half hour or so and look at the GPS map.  It will drift my several meters at times, and if in city with buildings (or other GPS reflective places) it may drift by much more.

At beginning of this, I recommend right click on GPS map, "Enable Diagnostics" so you can see the raw GPS data (added as diagnostics) as well as the cooked INS13 data.

I wonder if a simple recalibration with the clone GPS mag would have worked OK.

[TheOtherCliff]

I have several of those same authentic DJI Naza GPS units.  They are small and work very well.

The only down side as compared to clones is that the authentic units have Ublox Neo6 GPSs inside, while the clones almost always have Ublox Neo8 or Neo7 GPSs.  That means the authentic ones only use USA satellites, and can't even see the Chinese Russia, etc, satellites.

[karla]

Up until now I have identified the Mags to be my key problem and not the GPS.
Having a long hard march of toilet bowl I could not get rid of, and the analysis that its the mags telling the FC to go in a wrong direction and then compensation for the wrong in a wrong way will make it bowl eternally.
But now I think I have a reliable mag but maybe an unreliable GPS
However, the GPS is all green using 9 or more sats in an open field. I stays green until cuddly just go black for a second and then come green again.
What you think about trying your dji.c fix?

[TheOtherCliff]

Which GPS goes black, authentic or clone?  How often?  Using GCS or Android?

If GPS works at all, there should be only (GCS colors, I don't know about Android):
 - red X with black background (usually bad wiring or maybe bad GPS)
 - red block (GPS working but no satellites)
 - yellow block (GPS working, some satellites, but not enough)
 - green block (GPS working, enough satellites to fly)

Do you have FC powered by 5 volts or more or less?

dji.c fix only addresses the east-west oscillation issue which is worse when nose is pointing some compass headings.  For me I recall it was worst when nose was pointing north.  This is not toilet bowl.

Toilet bowl is usually caused by bad mag calibration or bad mag sensor mounting angle or aux mag orientation not set correct (example race mount motors).  Or aux mag Usage not set to AuxOnly.  Mag calibration is picky.  It gathers data the whole time, not just when you press button 6 times.  You cannot set it on ground or metal, etc. before/between/after button presses.  It takes two people to do it well and easily unless you have something like a waist high wooden table with no nails / bolts in say a 1x1m area to put quad on.

Magnets, like those in some Lipo alarms must be long way away from mag sensor.  My closest Lipo alarm is about 22cm from mag sensor, and I have watched GCS scopes and seen that is almost too close.  I can see mag graph change if I wave around a Lipo alarm any closer than that.

[karla]

Thank you!
. GPS used is the DJI authentic unit.
. Its a red X with black background.
. happens like 5 times during 11 minutes.
. Using GCS (win 10 pc and lp next r711)
. Power from LiPo 6s via Align BEC to flight controller at 5.0V (not more not less)
. It start slow oscillation east-west but then pick up north-south (it feels like toilet bowl but mags are super okay!).
. Only tried Pos hold with nose pointing North.
. Mag orientation should be fine, it does not differ more than 1-2 degrees from internal external mag.
. Mags are always green and show 0.1 to 0.3% error in GCS (best ever in years !).

I will do Mag calibration again several times for sure, (am aware of the common pitfalls).
However, something else might be wrong here...

This is what the Black out duration looks like:
However, it never happened during Position Hold flight, so if this is significant, then its telling something is wrong in general with this GPS?

[TheOtherCliff]

All the authentic DJI GPSs that I have do not do that, only some brands of clones (most clones).

I recall that you are running next.  I worked on that code back in 16.09 version and red X was supposed to mean "bad data / no data received".  It is supposed to mean that you have some sort of hardware issue like cable disconnected or GPS sending bad data or GPS not sending any data.  I am guessing that next is the same as 16.09 in this regard.

My experience is that authentic DJI GPS does not send bad data, but some types of clones do.  Your report of how often it happens matches my observation of the clones that have bad firmware in them.  The good thing is that this is not noticeable in flight.

It actually garbles and drops about one GPS packet per second, so I have the system health ignore that.  (It looks like the person who wrote the GPS internal code increased the packet rate to compensate for that.    )  It drops two GPS packets in a row about once every minute or two and from what I recall, that is what you are seeing (red X).  It drops three packets in a row sometimes, maybe once an hour?  But that is still only 1/2 second without GPS data.  etc.

I have seen one of my clone GPSs lock up about every 24 hours of use.  I recommend that you do some long term testing to see what yours does.  Connect your aircraft to a 12 volt supply to bypass the battery and let it run for a week or whatever time you have if you don't have a week.  If the GPS is still running (no red X) (even red block is OK if the reason is that it is indoors) then I would not worry about it.  Beware that INS13 can diverge after sitting still for a long time (10 minutes or so?), causing ATTI/STAB health issues, but that isn't important for this test.

Beware that sometimes the FC will reset when you plug in USB with it already running on 12 volt power.  This shouldn't cause you problems (I don't expect the GPS to reset, so rebooted FC will still show if GPS is bad), but will reset the FlightTime counter (on Firmware page).  I like to see the FlightTime counter to make sure it has been powered the whole time (e.g. didn't reset last night from power failure, resetting the GPS).

[karla]

Thank you Cliff,
I got a quad running Librepilot next r711, were the gps is fully green at all times and now it do PositionHold very stable. I think I will move that unit over to the heli first to rule out if there is any issues with the frame. If that unit works well on the heli (its an OP v9) and can manage position hold I will know the dji naza unit is the culprit.

[karla]

Long pause in this project due to lack of suitable flying sites,
but now still have some time fly to okay here

Short recap:
My goal is to get a stable posistion hold and then move on to other gps flight modes.
Problem is that it toilet bowls. At least it seems that the usual two causes are not the problem; 1. mag disturbed 2. mag incorrect orientation setting.

However, I have identified a possible mag disturbance source from poorly twisted cables from LiPo to ESC, its located almost 1m away from gps unit. And it will be a rather big surgery and I don't have any new wires or soldering gear here, so just first trying to find other possible causes.

Yesterday flights
. now using a gps unit I know to work well, so the unit should not be the problem,
. now upgraded to lp 16.09 next (r735), on a Revo Nano board
. using a OPLM unit on heli for both control and telemetry and another OPLM on ground side.
. thrust control set to collective,
. Thrust stab set to AltHold that uses the baro, works like a charm,
. AttEstAlgo set to INS13, all calibration done here at new site and horizon nice and stable in PFD gadget,

I did nine test flights, each around 2 min long.
Just to point out:
. GPS solid green in all flights and at all times.
. MAG solid green in all flights and at all times.
but
The typical bowling looks like this:



Afterwards, I checked the logs from the last six flights (where I did PosHold) and found that each time I switched to Pos Hold (stab 4), the System Health show CPU warning and the PFD Master Caution turns red.
Like this:



Can this point to another issue/cause for bowling, other than mags disturbed or mags orientation wrong?

. Attached the log files (can ff the first 1 minute to when arming).
Flights follow same pattern, Stab1 (rate) then Stab2 (Att) then Stab3 (AltHold) then Stab4 POS HOLD （usually for 2-3 sec only).
. Attached the uav file.

Also, back in Jan, TheOtherCliff suggested to maybe reduce some PIDs in VtolPathFollowerSettings.
These are my current settings (all default):
Which ones to try and change, if any?



Thanks a lot

[TheOtherCliff]

Does next INS13 do anything differently than 16.09?  I recall hearing that next INS13 uses Basic/CF under some conditions and that it can use just 2D mag instead of 3D mag.  (I can imagine that EKF could need different settings for 2D mag.)  These are things you could experiment with.

I recall that bad mag calibration caused me some toilet bowl in old versions, probably 16.09.  You could:
- select a Home Location close by and recalibrate mag
- make sure you are using 3D mag and INS13 without Basic and if that doesn't help, try changing the aux mag orientation a little (6 different ways, 6 tests) to see if that helps.  I would also tweak the aux mag orientation alignment using the Basic with Attitude mode vs INS13 with Attitude mode described in the aux mag wiki, but that is only useful for 3D mag.
- I suspect that tweaking some PID stuff in VtolPF might help.
- You could try the DJI GPS east-west oscillation fix.  Are you running a DJI GPS?  I recall even having oscillations with uBLox if I set the fix type to something slow like human walking on the ground as opposed to airborne xG.

[karla]

Thanks.
advances over 16.09... Well you got the fix of the initial altitude drop when first switching to some altitude stabilization modes.
But I was hoping a little extra on this fix of accelerometer & gyro calibration bug
https://librepilot.atlassian.net/browse/LP-590?src=confmacro
Since I thought it just might be relevant to this heli and the stubbordnes for pos hold.
There is also this mag 2D that f5soh pointed out very early on:

You may switch to Next and get rid of INS13 / 3D Mag issues in 16.09 and also made possible Complementary+Mag+GPS usage.

First at all, did you try a simple Attitude stabilization + AltitudeVario/AltitudeHold ?
Try setting the SystemSettings > ThrustControl to Collective maybe.
In all cases the Stabilization tab > AltitudeHold settings will need some tuning.
You can also set SystemSettings > VtolPathFollowerSettings > ThrustControl to Manual so you will remove the Throttle changes while switching to PositionHold and only check the position behavior (and possible toilet bowling)
Simple check about Mag: point the Heli to the North and check if the compass matches heading in PFD.

Tried that at the time, but did not improve significantly, so now I am shooting for full INS13 and finding the 'real' cause.

[TheOtherCliff]

You may be aware that Nano only has a 100Mhz CPU but Revo/Sparky2 has a 168Mhz CPU.  That is probably the cause of the CPU warning, and may be the cause of the toilet bowl.

Other than that, I would try tweaking the VTOLPF PIDs of various sorts.  Did you say this was FBL?  Even without a flybar, I would guess that it is slower to react than these PIDs were tuned for.  When the aircraft is slower than the PIDs are tuned for, you get oscillations of some sort.  The most common case is on a quad when people use a slow ESC protocol they get oscillations.

[karla]

That was two really interesting points Cliff.

Its difficult to fit a full size revo or sparky inside the 450 frame (I tried that already), but may work with one of those Revo boards called 'Revo mini'. Will bear this in mind.

Most interesting, the flybar etc and the vehicle slower that the PID tuning. Yes this is a no flybar setup.
But its really a slow vehicle now with an extra 3D gimbal that holds a full sized GoPro camera plus a mighty big LiPi.
This Trex 450L was built to be a ferrari, but I have turned it in to a very slow truck.
Can I change this PIDs somehow, I tried but if turned them down it will be hard to control since it does not respond.
Maybe add a real Fly bar?
Or maybe reconsider the load of GoPro and gimbal and big lipo ...

I did tweet a lot with the HorizontalVelPID, Kp and Ki but that had the limited effect that it only delayed the time when the toilet bows started a little. I tuned them down from 8.0 to 0.00008
What do you think about working on the HorizontalPosP, now at 0,25?