[TheOtherCliff]

Can I change this PIDs somehow, I tried but if turned them down it will be hard to control since it does not respond.

Only adjust the normal (Stabilization page) PIDs when flying Attitude or Rate mode, not GPS modes.  And adjust them for best operation.  Then adjust the VTOLPF PIDs, but only when flying GPS modes like PH or VR.

Maybe add a real Fly bar?

That should not help anything.  And it would only slow down the response and potentially make it toilet bowl worse I suspect.

Or maybe reconsider the load of GoPro and gimbal and big lipo ...

If it carries it in Attitude mode, it should be possible to make it carry it in GPS modes.

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

8.0 to 0.00008 with minimal effect means that setting is not affecting it.  Some of the settings work in this GPS mode and some in that GPS mode.  Example: I recall VelocityRoam has a separate set of PIDs.  Generally VR and PH use the same code.  They may or may not use the same PIDs.

What do you think about working on the HorizontalPosP, now at 0,25?

That is a logical one to try.  I would try all the logical ones... 

[karla]

Thanks. It makes sense.
I think know what to try next.
Unfortunately, will not be able to get down to south of china and try it until march though 

[TheOtherCliff]

I don't much like that CPU error.  There is an "Update Period" setting in VTOLPF.  I would be tempted to increase it till the CPU error went away.  Of course I haven't tested that myself, so be ready to switch back to Attitude or maybe even plan on switching back in 1 second the first time.

Mag alignment and GPS lag are the two things I have seen that make GPS modes oscillate when Attitude mode doesn't oscillate.  You could try changing the aux mag orientation angle numbers by say 5 degrees.  Try both adding and subtracting to see if either one helps.  I would try yaw, then pitch, then roll.

When flying in Manual mode when you give forward pitch only, does it tilt exactly forward or a little off to one side like it had a little roll too?  That would affect both Attitude and VR modes, but VR may just be closer to oscillation (toilet bowl).  Does it act the same in Attitude?

Good luck when you finally get to fly again.

[karla]

A couple of days ago they let us out from the virus confinement and I got a chance to fly the heli.

Finally found out it is the HorizontalPosP value in the VtolPathFollowerSettings that caused what I called 'toilet bowl'. The default value is 0.25 and after gradually tuning it down to 0.035 it was making PositionHold much better but not perfect. I did not have a chance yet to tune it down further but in good hope it will sit rock steady when done

This lesson came at a high price though 
While trying other settings I lost control in a wind gust and it ended up in a tree.

These are other things I experienced:
. Upgraded to next r782 and re-calibrated, now the CPU warning comes on every 5 sec, not just in PH.
. The heli behaves very similar in PositionHold both in INS13 and in Complementary+Mag+GPSoutdoor.
. When in Complementary+Mag+GPSoutdoor there is no CPU warnings, all health items nice and green.
. It makes no difference if the GPS UbxDynamicModel is set to Airborn1, 2 or 4G.
. Odd thing: did switch from attitude to VelocityRoam and the heli shot straight up in altitude. It never does that switching from attitude to PH. Maybe it has something to do with using Collective as the ThrustControl in SystemSettings? There some other ThrustControl settings, hard to understand what they do...
VelocityRoam does not have any own settings for thrust limits, that would have been a logical cause I think.



Damages
. motor and ESC toasted
. main drive gear missing teeth
. both main rotor linkage rods to swashplate snapped
. tail rotor torque gears and torque tube

Amazingly the things usually get damaged seems to have survived
. main rotor shaft
. main rotor feathering shaft
. tail rotor shaft
. rotor blades

I dont know if i can find spare parts anymore but will try.
This might have been the last flight with this heli.
If i find parts then i might upgrade from Nano to a Revo mini at the same time.

[TheOtherCliff]

The HorizontalPosP value in the VtolPathFollowerSettings that caused what I called 'toilet bowl'. The default value is 0.25 and after gradually tuning it down to 0.035 it was making PositionHold much better but not perfect.

I've never had to tweak HorizontalPosP nearly that much in 16.09.  I still have 16.09 on a lot of stuff.

The CPU warning comes on every 5 sec, not just in PH.

Are you using a RevoMini or other FC that has less CPU power than full Revo?  There is an UpdatePeriod setting in VTOLPF (maybe some similar elsewhere?) have you tried adjusting that (I don't know how safe changing it is)?

Glad to hear you are safely out of quarantine!!

[karla]

Thanks, after 20 days basically confined to my apartment it was a great feeling of freedom to get out and walk on the empty beach 

I've never had to tweak HorizontalPosP nearly that much in 16.09.  I still have 16.09 on a lot of stuff.

Hm, not surprised really, over time I think I build 5 quads with Open/Librepilot and I have never changed this from defaults.
However, this is a helicopter collective pitch frame that also differs from the standard t-rex set up, its mutch heavier due to GoPro, 3d gimbal and 2800 mAh 6s LiPo. So tuning can be expected to be different from a mainstream quad.
Reason I feel HorizontalPosP is crucial is when I set it back to default it immediately starts to toilet bowl. It might not be the only thing needed to be tune, but finally found at least one parameter that have effect.
This is actually the first Heli I tried with GPS modes with Open/Librepilot. Seems no one have done it before, with the possible exception a user back in the LP times, but he did not use the collective thrust setting and used manual control of altitude and as you can see this has been a looooong thread.
I just have a feeling its nothing wrong with the code, just needs to be tuned. I might be wrong.
 

Are you using a RevoMini or other FC that has less CPU power than full Revo?  There is an UpdatePeriod setting in VTOLPF (maybe some similar elsewhere?) have you tried adjusting that (I don't know how safe changing it is)?

. I use a Nano board with less computing power than a Revo.
. I was not aware Revo mini has lesser computing power than the a size Revo board?
. I have looked in to the option of adjusting Update period settings, but I have no idea what I am doing so decide to not mess with it. Does not seem to be important since other AttEst work as well as INS13. Besides its just a warning cpu is at 80% of capacity.

[TheOtherCliff]

Are you using a RevoMini or other FC that has less CPU power

Sorry, I meant Nano, not Mini.

Just some thoughts on a lazy day ...

Telemetry would be handy.  Can you free up an FC port and hang an OpLink on it?  Record telemetry for a long (say 5 seconds) straight pass forward no wind Attitude mode.  Play back and compare GPSPositionSensor.Heading to GCS compass heading toward the end of the pass.

Remembering your USB issues, I wonder the tiniest wonder if there is a problem with your mag calibrations because you have several versions of LP/OP installed.  We had a mag cal issue fixed in GCS in some old version.  Work around was to reset the all mag calibrations to defaults before doing calibration.

Developers never had a problem with multiple versions of LP/OP installed.  We generally don't actually run the install program.  We run the compiled code from where it is built and everything is in the "build" directory, so just save that off somewhere and rename it for each version you want to keep.  Even things like "first working version of my new feature" and "I made a change for a friend and didn't bother to check the code in".  You can even copy the build directory to another similar computer.  I know LP put significant work into allowing multiple versions to be installed, but I don't know more.

I think the trick to getting good onboard mag calibrations with USB is to demagnetize the USB cable's connector and to use battery power and make sure USB voltage is lower than BEC voltage (can even cut red USB wire in cable to remove USB power).  That way the FC power flows from BEC like it does in flight.  I use the magnetic field of a big triggered soldering gun where you can feel the mag field on a loose nail.  Slowly move it around in strongest part of field and slowly move it away from field before releasing trigger.

About toilet bowl:
- mag calibration can definitely cause it, that is maybe most common.  If you point the copter north using a non magnetic reference (like a road or map feature you know is straight north), does GCS say it is straight north say within 10 degrees at worst (low motor power)?  Does either copter yaw direction or GCS compass direction change with flight load (flight motor power)?
- home location badly wrong or local magnetic variance from what the World Magnetic Model says could cause it and it would probably show up with the above map test.
- aux mag alignment to body being off can cause it, could need tweaking different than what looks correct?
- in Velocity Roam mode do you notice that forward stick starts moving in one direction (magnetic), but a short time later, corrects back to a slightly different direction (GPS trail)?  I have seen that.  I would be tempted to rotate GPS/auxmag mount that angle amount, ?in the opposite direction? (or change Aux Mag orientation setting using GCS) if you are still using an aux mag in GPS.
- does it do toilet bowl worse when copter is pointed say north or east etc?  This is that issue with DJI Naza GPS, but I can make it happen with Ublox GPS by changing GPSSettings.UbxDynamicModel from "Airborne1G" to something slower like "Pedestrian" or such.  I guess DJI issue can be toilet bowl too.  I suppose that running a ridiculously slow GPS baud rate on Ublox, or setting UbxRate too high (drops data) or too low would delay the GPS data and could cause it.
- FC alignment to body will cause it, but I suspect you have that reasonably aligned (say < 5 degree error)
- another thing is that manual mode cyclic forward may actually tilt a little left or right too, that may cause it, adjust head so that manual mode banks are accurate to what stick requests

[karla]

Thanks Cliff,
Seems spare parts will not be a problem at all, just takes some times these days.

Yes, using telemetry via an oplm unit connected to the nano flexi port already.
That was a pretty good and simple idea. No problem to find GPSPositionSensor.Heading and display it in Scopes, but what about the Mag heading? There are MagState and MagSensor with x, y and z fields but non of them seems relate to a 360 degree compass heading. Not very important, I can have use the Analog Dial or even the PFD's mag display. 

Since I have tried three different types of gps with compass in them and at least two were known to work fine on quads with LP, I have pretty much ruled out the calibration. However, the test you suggest would provide the answer.

We had a mag cal issue fixed in GCS in some old version. 
Work around was to reset the all mag calibrations to defaults before doing calibration.

How to reset to defaults? I use only the external mag.

For further adjustment of the HorizontalPosP values, I will continue a trial and error method and bring it from default value 0.25 and lower than 0.035, considering default P terms in the stabilization settings for Roll, Pitch, Yaw are typically 0.003, ten times smaller. I would be a bit hesitant to put it to zero though, maybe it will not hold position...

[TheOtherCliff]

what about the Mag heading?

I was thinking PFD mag display, but I wonder if AttitudeState.Yaw is compass heading in INS13 or other GPS AttiEstAlgo.

How to reset (mag cal) to defaults? I use only the external mag.

I recall the problem was with some version before 16.09.  @f5soh has a trick to do it easily but I forget how.  Here he describes zeroing the onboard mag.  Aux mag settings are similar in AuxMagSettings.  Make these changes, save them, then do mag cal.  An easy way would be to save a default UAV file and remove all the other settings, then just import it to reset the mags.
https://forum.librepilot.org/index.php?topic=3239.msg22333#msg22333

For further adjustment of the HorizontalPosP values, I will continue a trial and error method and bring it from default value 0.25 and lower than 0.035, considering default P terms in the stabilization settings for Roll, Pitch, Yaw are typically 0.003, ten times smaller. I would be a bit hesitant to put it to zero though, maybe it will not hold position...

Zero PI means "no stabilization" for stabilization PID or "no position hold" for HorizontalPosP, and that is if you are lucky. 

PID1 type (normal PIDs) can do a zero P term and still work if I term is non-zero (I recall).
PID2 type (e.g. PathFollower PIDs with a Beta term) would blow up with divide by zero errors if you try to use a zero P term.  At one time I coded it to replace zero with a small number.  I don't recall if that is what it does now or not.

Well if your regular PID is 10 times smaller, then it makes sense that your HorizontalPosP is 10 times smaller.  Sounds like the copter is very slow to respond to need PIDs so small.  To speed up response, if it has a normal flybar with weights, I would move the flybar weights in as far as possible or remove them completely.  That will require retuning PIDs (higher) and HorizontalPosP also.  I imagine doing LP on a copter with flybar weights is like doing LP on a quad with 50Hz ESCs; to avoid oscillation it needs very low PIDs and because of that it wanders around badly and is barely controllable.

[karla]

Thank you Cliff.
Some update here.

Spare parts arrived, installed balanced and checked as routine for Helis 
All calibrations to the Nano was redone, and this time I reset to mag defaults using your post - thanks.
(both internal and external mags).
After mag calibration I placed the Heli in straight west orientation and it checked totally with my iPhone mag app.
So, I think I can trust the mag (at least at zero throttle).

Moved on to fly a straight line and check the heading readings from the GPS vs. the Mag (external used only).
I have been flying Complementary+Mag+GPSoutdoor (to avoid the cpu alarm with INS13).
The GPSPositionSensor.Heading is a compass 360 degree thing fine, however the AttitudeState.Yaw is different.
It shows 0 to 180 degrees just normal as the gps, but when passing South at 181 degrees it will show -179 degrees and then arrive at 0 degrees at 360 North. So the two are not directly comparable in one single scope diagram.
The AttitudeState.Yaw value needs to be converted in to a 360 degree scale to compare to the GPS.

Here is a 30sec flight (selection of it), starting in south pointing and then just arming, spooling up, lift off and fly some 50m to the west and land there.
It shows three curves
. the GPS heading (does not know the direction before moving)
. the Mag heading, and
. the throttle (its a straight line since using governor mode, so thx same but collective change).



Here is a table I made to compare the gps 360 values to the reported yaw values.
I just selected some timestamps and measured the values on the graph.
There might a much better way to do this by exporting the values to an excel file? anyway this is what I have now.



At the end of the table I also added on two data points from another flight where I engaged position hold.

I don't know how the code works in Position hold, Is it really important that the heading of the compass and the heading of the GPS are aligned? I would assume not, since the GPS responsibility is to report the location and the compass will determine the direction to compensate any discrepancy? So if the gps location is correct even if the head is wrong it should work?

If however their heading must align to keep PH then I think there is a big problem here.
But I dont know if its the mag or the gps that's the problem.

Any advise 

p.s.
I just uploaded the logfile from the flight here.
d.s.

[TheOtherCliff]

As always, just some ideas to throw out there. 

(With any attitude angles (e.g. yaw) you can add or subtract multiples of 360 to convert to another format like from 0,360 to -180,+180 so for instance 359 degrees is the same as -1 degrees.  It looks like you got that.  )

The idea with comparing GPS heading to mag heading is to verify that mag is accurate by using GPS, straight flight, straight ahead, no wind.

GPS heading is not used by code at all since a heli can fly sideways.  That brings up a question.  When you were flying straight line, was the heli flying straight or flying a little sideways?  5 degrees would be hard to tell, but 17 degrees should have been at least noticeable?  Maybe wiggling pitch or roll a little would help the eye make sure it is flying straight?  Do you have an on board video that you can calibrate by pointing heli straight along a line to find where straight ahead is in the video (also maybe 10 degrees left and 10 degrees right), then for testing you can review the video and estimate how much off of straight ahead you were flying?

Sounds like a lot of work just to determine if the mag alignment is bad, so you could also assume it is bad and just tweak it and see if it gets better or worse.  Aux mag can be tweaked either by rotating GPS puck or by adjusting aux mag orientation using GCS, but Onboard can't be tweaked.  Are you using Auxonly or Both mags?

Turn off Piro Comp if it is on.  This helps if heli is not balanced on shaft.
https://forum.librepilot.org/index.php?topic=4651.msg31493;topicseen#msg31493

Do you have a tachometer?  What is your head speed?  How does it compare to manufacturer recommendations?  I would guess it needs to be higher because of the added weight.

As I understand, there are two problems:
- Low PID, low HorizontalPosP and I assume stabilization is not the best and Position Hold is not the best.  This makes me wonder if it is flying well in Manual mode.
- toilet bowl, maybe made worse by mag inaccuracies

Given the problems, I would start by getting it flying very well in Manual mode, then Rate mode, then Attitude mode, all using Basic Atti Est Algo to remove any chance of mag affecting flight.  In all modes make sure that back and forth pitch is just pitch (straight forward and backward with no perceptible side to side roll), roll is also just roll, and yaw holds well.  Then switch to your preferred Atti Est Algo and retest to make sure it is still working well.

[karla]

As always, thanks for input Cliff.
Sorry for delay. Had to take a rest and fly some mature and fun helis for a while

I think you are on to the main problem here. The airframe don't fly well in any mode, in the current heavy configuration.
Also the test flights show a deviation mag to gps heading of +13 to -13 degrees. its not a bad mag causing this I think. It's struggling to stabilise the frame.

This is my experience.
Align recommends a head speed at hover of around 2600 rpm.
Even though I don't have a proper rpm measure tool, so I can't tell what the rmp really is, I know it most likely must be much slower than with my other 450 size helis  that fly well. I known this since way back, however, when I increase head speed to a 'normal' rate, then oscillations starts. To get rid or the oscillations I need to lower the PIDs. They need to be so low its very difficult to control the Heli. So better lower head speed a little bit.

What I have been using is the best balance I can strike between good head speed and high PIDs.
I have spend so much time on this so I am confident there is not a significantly better balance than this.
So, if it's not good enough for autonomous functions, I can accept it.

I think to make the Heli loose some weight by changing the configuration and try achieve some better balance.
Got your thinking when suggesting, first make it fly will in manual mode, however no one would really try to fly a flybarless Heli in manual mode - we humans are too slow to react 
Rate will do the job - now moving into the end-game for this project

some answers for your direct questions:
. no the heli do not go sideways a little bit when moving cyclic forward. Its very predictable in rate and attitude.
. the piro comp was enabled.

[TheOtherCliff]

Oh yea, flybarless...  I thought they could be hovered in Manual without a controller, but forward flight was not possible because of ballooning.

I've got several nitro helis (tail rotor gyro only) under my belt, but that has been many years ago, and I was competent with up to mild stunts.  With that in mind, some musings for your consideration:

If you are using digital servos, I would go to the Output page and set the PWM rate for the servos to their highest recommended speed.  I'm also guessing that you are using a generic RC receiver, not part of an "all in one" unit that came with the heli.

Have you flown it or tweaked it since you disabled Piro Comp?  PC is bad news if the aircraft is unbalanced.

Flying in Basic (Complementary) Atti Est Algo will remove any mag issue.  I would remove GPS flight modes from FMS and first get it working in Basic with Rate and Atti.

Have you tried to look at vibration with a fast scope update interval at high head speed to see if it is a problem?  A long USB cable and high head speed without liftoff is all that is needed.  If scopes show that accels are below 2Gs and there are no glitches in the gyros or attitude it should be OK.

Do FBL controllers have any settings that are special for FBL and that LP doesn't have?  If so and I had a flybarless controller, I would try that for a test to see if it can handle a higher head speed. 

Do you have any other flybarless helis with LP controllers on them?

no the heli does not go sideways a little bit when moving cyclic forward

In Manual mode with a flybar, the sideways would come from mechanical issues like slop or misalignment.  That was the part I was getting at fixing.  Stabilized modes like Rate and Atti will only go sideways if the FC is mounted sideways, but stabilized modes will oscillate if the underlying heli goes sideways in Manual.  I would play with things that can fix a presumed "sideways in Manual mode".  With good head speed, set the PID high enough so that you can see a little oscillation and then adjust the "sideways fix" one way or the other.  It might be that one way makes it better.  There are many ways to adjust the "sideways in Manual mode".  The easiest looks like "Swashplate Servo Angles" -> "Correction", but it only allows increments of 15 degrees; still it would be good for a test at +- 15 degrees.

I imagine it is one or more of:
- low head speed for the weight
- "sideways when you give forward in Manual"
- vibration
- CG badly out of balance

[karla]

Oh thanks again Cliff, so many ideas.

I have to park this project again since I am leaving here next weekend going back to BJ and can't fly it.
It's very good news for the world that CN got the spread under control (at least what it seems). Today they skipped all fever controls at the compound entry here, being up since Feb. I hear from my friends in eu and usa that situation feels gloomy and apocalyptic. Cheer up

I left off trying to reduce weight to get heli tuned more like a normal default 450 trex.
Stripped off camera and 3d gimbal but the LiPo is most of weight and the last test flight sets it showed no significant improvement of higher PID values vs head speed. Piro Comp was off.
I can rule out the two last of your factors, vibe and CG off.
I am working on the head speed now and to do that I need smaller size lipo's for next time. If that fails, next time, I will have a look at the 'sideways' thing.

I imagine it is one or more of:
- low head speed for the weight
- "sideways when you give forward in Manual"
- vibration
- CG badly out of balance

Since I have set up numerous FBL helis with OP/LP and currently have three tuned beautifully for non autonomous flights I feel confident I get this baby to fly well as well.