LibrePilot Forum

Users => Vehicles - Helicopters => Topic started by: karla on November 16, 2017, 01:30:56 am

Title: GPS assist and Heli
Post by: karla on November 16, 2017, 01:30:56 am
Doesn't GPS assist work for Heli vehicles?
I get a red config error on the flight mode setting as soon as I change to gps assist.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6886;image)

I am using a Revo with Librepilot 16.09. Think I have used GPS assist before on another Heli with no problem...
Maybe something else is causing this?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 16, 2017, 04:16:36 am
Do you have INS13 for Attitude->Settings->AttEstAlgo
and mags calibrated
and HomeLocation set

all these are required for GPS use (other than OpMap)

It should work with CruiseControl, but you could try changing that too.
Title: Re: GPS assist and Heli
Post by: karla on November 16, 2017, 06:18:41 am
INS13 yes,
Homelocation set yes,
Mags are calibrated, but at the moment in-house and no sats of course and mags mostly red inside, should still be possible to set the GPS assist.
Have already tried all options for the thrust setting, but no change.
Odd...

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6888;image)

it say the mag source is invalid here ...

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6888;image)

But in the system it seems Valid...

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6890;image)
Title: Re: GPS assist and Heli
Post by: f5soh on November 16, 2017, 07:27:16 am
This is the normal behavior, only Multirotors frames allow "GPS assisted" flight modes.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 16, 2017, 07:31:09 am
Hmmm.  I always assumed that helis could be configured like quads.

I knew there was a problem in that it does not control both motor and collective, but that is a different story.  We need a mix curve for that and the thrust channel should control both motor and collective via the new mix curves.
Title: Re: GPS assist and Heli
Post by: karla on November 16, 2017, 07:39:01 am
Oh  :'(
I can live without GPS assist i guess, but it's very useful and simplifies flying especially for FPV/Photo missions, like my current project.
Title: Re: GPS assist and Heli
Post by: f5soh on November 16, 2017, 07:02:34 pm
You can use VelocityRoam as well ?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 16, 2017, 09:43:17 pm
Uhhh...

So VelocityRoam is allowed on a heli, but GPS Assist is not allowed?  That doesn't make sense from my viewpoint...
Title: Re: GPS assist and Heli
Post by: karla on November 17, 2017, 08:04:32 am
Yes, VelocityRoam does not give a red error on the config page.

VelocityRoam
Hold position, and control it with stick inputs
Position is adjusted in vehicle's own orientation, pitch forward makes vehicle go forward
See also Gps assist page for something similar.

This description is a bit short for me.
Is it like GPS assist but without the break sequence?
If i let go of sticks, will it hold current position and hover?

Good thing is that Position hold, RTB and Pathplanner works for a Heli.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 17, 2017, 10:11:37 am
Yes. Velocity Roam with neutral sticks is Position Hold.

It is a lot like Attitude mode with GPS Assist.
Title: Re: GPS assist and Heli
Post by: karla on November 17, 2017, 10:27:06 am
Thanks, great, then I will explore that.
In a way i wonder like you why the gps assist can't work for a heli, but my question is more academic...
Title: Re: GPS assist and Heli
Post by: f5soh on November 17, 2017, 07:19:46 pm
Uhhh...
So VelocityRoam is allowed on a heli, but GPS Assist is not allowed?

Yes, you're right  ???
That's a known "issue" since some time now: https://librepilot.atlassian.net/browse/LP-375
The only cause of GPSAssist only enabled for Multirotors is a lack of testers with Heli + GPS and Heli vehicles in general. Look Heli tab story.
Title: Re: GPS assist and Heli
Post by: karla on November 17, 2017, 11:38:49 pm
The only cause of GPSAssist only enabled for Multirotors is a lack of testers with Heli + GPS and Heli vehicles in general. Look Heli tab story.

Oh, but I can test it on a Trex450L with a revo.
How do I go about that?
In the link you just posted you ask Volker to first start a Forum thread, but I can't see he ever did.
Can we use this thread instead?
Title: Re: GPS assist and Heli
Post by: f5soh on November 17, 2017, 11:58:42 pm
Try setting the FlightModeSettings > DisableSanityChecks to True, this may help as a start.
Be safe...
Title: Re: GPS assist and Heli
Post by: karla on November 18, 2017, 12:33:19 am
Okay and then I just try using it and report back here, right?
I have a quad that I could test at the same time so there is something to compare with.
Title: Re: GPS assist and Heli
Post by: f5soh on November 18, 2017, 09:45:44 am
You need to test the PositionHold first, be sure is solid without toilet bowling in all cases.
Be prepared to go back in Attitude mode if something wrong occurs.

Title: Re: GPS assist and Heli
Post by: karla on November 18, 2017, 10:36:35 am
Tried position hold today - toilet bowl  ::)
Whats the first actions to fix it?
The mags and calibration looks good, but I noticed the compass is spinning round.

Title: Re: GPS assist and Heli
Post by: f5soh on November 18, 2017, 12:52:03 pm
Toilet bowling means the heli do a correction of position, but not in the right direction/heading.
Can be a mag disturbed by strong currents or wrong orientation of AuxMag.

Be sure the Mag alarm still green while main motor is running at full load.
Set Mag usage to AuxMag only and keep away your GPS/Mag away from strong currents.
Twist all power wires or at least keep red/black wires close together.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 19, 2017, 12:43:20 am
aux mag orientation is important

look at Flight Data page.  Is PFD stable or is it flipping around violently, like completely upside down and flipping around like a fish out of water.
Title: Re: GPS assist and Heli
Post by: karla on November 19, 2017, 05:05:27 am
Thank you both.
I will double check all what you mentioned and test in the field later today.

Just want to confirm something.
The Revo board is mounted inside the Trex frame, on one of the sides and therefor needs to be virtually rotated like this:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6918;image)

But the external mag is a OP v9 GPS (kind of) and mounted pointing forward on the tail boom, so it should be rotated 0,0,0. Now, does the fact that the Revo and the external Mag are mounted differently make a problem for the mags to align and the INS13 attitude estimation algorithm?

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6924;image)

In the PFD the model is turning correctly when I move the heli around, yaw left right, pitch and roll. The fc also make compensations in the correct directions.

To further complicate this a bit, is the compensation of 5 degrees roll I use to make this heli hover at zero stick input (the tail rotor effect). This is how I set it up.
First a put in the virtual rotate the board in the Attitude | Settings, then using complementary attitude estimation algorithm I do the Board level calibration. Then I fly it in Attitude mode and adjust the BoardLevelTrip roll and pitch until it hovers without any stick input.
After this I change to INS13 and hover in attitude mode and adjust the external mag rotation to hover without any stick input. As good as it allows.
Maybe there is a better procedure?

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6922;image)

In the field, the external mag is always green and internal mag at warning or red. I have not worried so much that they don't align since the internal mag is almost always wrong... should I?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 19, 2017, 05:37:32 am
Different FC vs. aux mag orientations is fine if you configure it correctly; just remember that the angles (FC and uax mag) are relative to the driftless Attitude mode hover orientation.  I have to scratch my head and check the code or read wiki and extrapolate/empirical when doing strange FC mounting.  If the PFD moves correctly (including roll left makes PFD go right) and stabilization moves in the correct direction, then you have  proven it is correct.

Level hover:  That is the way I set it up:  RotateVirtual (Attitude mode using CF/Basic) and aux mag orientation trimming (Attitude mode using INS13).  It makes sense and I haven't found anyone to say it wasn't the way to do it if you want it perfect.

That OnBoard mag does really look bad.  Is there a magnet close by the FC?

I sometimes use an FC or GPS/mag sitting still on the wooden table and view a mag sensor (not mag state) scope while I move the thing under test close to it.  If there is a mag field in the thing, this will show you.  It will also show you how close you can get before the mag sensor is affected.  This helps when deciding how far the aux mag needs to be away from component X.  You could move the heli FC close to the table FC and look for a change...
Title: Re: GPS assist and Heli
Post by: f5soh on November 19, 2017, 11:17:00 am
Quote
Level hover:  That is the way I set it up:  RotateVirtual (Attitude mode using CF/Basic) and aux mag orientation trimming (Attitude mode using INS13).  It makes sense and I haven't found anyone to say it wasn't the way to do it if you want it perfect.

Latest INS13 used in Next will not need anymore this level of precision because Mag will not contradict the roll+pitch estimate derived from accelerometers. Complementary+Mag+GPS can be used as well using Next.

@karla Can you post your config file ?
Title: Re: GPS assist and Heli
Post by: karla on November 19, 2017, 11:19:00 am
I sometimes use an FC or GPS/mag sitting still on the wooden table and view a mag sensor (not mag state) scope while I move the thing under test close to it.  If there is a mag field in the thing, this will show you.  It will also show you how close you can get before the mag sensor is affected.  This helps when deciding how far the aux mag needs to be away from component X.  You could move the heli FC close to the table FC and look for a change...
Thanks. I will remember this one.
K
Title: Re: GPS assist and Heli
Post by: karla on November 19, 2017, 11:24:43 am
That OnBoard mag does really look bad.  Is there a magnet close by the FC?

I know, its really messy inside the heli, power cables close, 600mW FPV transmitter back to back and OSD board 2 mm away plus a Video source switch. The onboard mag is doomed and forever confused :) Forget him.
Title: Re: GPS assist and Heli
Post by: karla on November 19, 2017, 12:02:21 pm
I checked all things you mentioned
. Aux mag mounted correct way - yes forward looking
. Aux mag orientation okay (0.0.0) - yes
. Mag only Aux - yes
. Mag green - yes
. Mag green at full throttle - yes still at 0.0-1.5% error
. PFD horizon not jumping around like fish without water - calm when good # of sats, bit jumpy when less.
. Alignment of Onboard and Aux mag - well, when onboard gets better then alignment better so I don't worry.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6926;image)

First when I got to the field I had, smack 11 sats on 3 minutes! flew one lipo pack.
Next round I had to wait for 45 min get a 3D position, and not a very good one. Flew another lipo pack.

I could only engage Position hold mode for some seconds each time since it was obviously not going well, and I want to regain control before out of control. It was typically first reducing throttle and then increasing it and then compensating too much, too abrupt with pitch backwards, then I did not want to experience more of that but bailed out ...

When sats where good then the flight with Attitude was much smoother and just like flying with Complimentary. When sats where just barley ok then flying was unpredictable and not locked in.

I am not using Next now but LP 16.09.

@Laurent,
Attached is the oav file and one log file where I engage Position hold some 3 times very short.

My own thinking is that the mags a pretty okay, the sats and my GPS might be crappy and maybe I should just try to calibrate my PIDs better, since now they are very laxed and could get much more snappy.
Any other settings to make the position hold adjustments not so violent?
Title: Re: GPS assist and Heli
Post by: f5soh on November 19, 2017, 12:50:46 pm
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.
Title: Re: GPS assist and Heli
Post by: karla on November 20, 2017, 03:22:04 am
Thanks, that was a bunch of good tips.
When this is reasonably resolved I will come back to the GPS assist, I could not enable it even though I disabled the sanity check of the flight modes. Its due to an Error of the ? -symbol (config), that prevents it from arming.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 20, 2017, 04:14:29 am
Quote
Level hover:  That is the way I set it up:  RotateVirtual (Attitude mode using CF/Basic) and aux mag orientation trimming (Attitude mode using INS13).  It makes sense and I haven't found anyone to say it wasn't the way to do it if you want it perfect.

Latest INS13 used in Next will not need anymore this level of precision because Mag will not contradict the roll+pitch estimate derived from accelerometers. Complementary+Mag+GPS can be used as well using Next.

I remember hearing about that.  Is it an option to use 2D vs. 3D mags?  I imagine that 3D mags are better in the following use case which (as I imagine) causes problems in Basic/CF AttiEstAlgo and now will cause the same problem in INS13:

Fly a quad in Attitude mode for a long time in a straight line using forward pitch stick (like flying 2km FPV).  After a while, you must add more and more pitch to keep it flying forward.
Title: Re: GPS assist and Heli
Post by: f5soh on November 20, 2017, 10:26:54 am
Quote
Fly a quad in Attitude mode for a long time in a straight line using forward pitch stick (like flying 2km FPV).  After a while, you must add more and more pitch to keep it flying forward.
Think when you are in a train, after the acceleration phase at start and when speed is stabilized for hundreds of kilometers in a straight line:
- do you fell horizontal acceleration ?
- do you need to bank your body to compensate something ?
- when you take a drink, liquid surface is inclined ?
In my opinion this situation do not cause any issues.

One known situation is when you are flying circles for some time, due to centrifugal forces.
Title: Re: GPS assist and Heli
Post by: f5soh on November 20, 2017, 11:24:39 am
Quote
When this is reasonably resolved I will come back to the GPS assist, I could not enable it even though I disabled the sanity check of the flight modes. Its due to an Error of the ? -symbol (config), that prevents it from arming.
Maybe you are trying to arm while the flightmode switch is one GPS/GPSAssisted mode ?
You must choose one flightmode with only primary stabilization for arming.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 20, 2017, 04:48:05 pm
Quote
Fly a quad in Attitude mode for a long time in a straight line using forward pitch stick (like flying 2km FPV).  After a while, you must add more and more pitch to keep it flying forward.
In my opinion this situation do not cause any issues.

I'm just saying that there should be an option to allow it to heading only or 3D mag with the new INS13 ... if there is not currently an option.

If I understand Basic AttiEstAlgo...

I know that most advanced FPV fliers don't use Attitude mode, but beginners do.  This would also be an issue when hovering in a constant wind for a long time (with the same compass heading).  You need more and more stick to counteract the wind.  That's not right.

It seems to me that needing more and more stick (or a similar issue that comes from flying continuous coordinated circles) is wrong (I know it's hard to fight this issue) ... and that always needing the same amount of stick to get the same bank angle is right.  And if my understanding is correct, then an INS13 with a 3D mag will be better at doing this correctly than an INS13 with a heading only mag.
Title: Re: GPS assist and Heli
Post by: f5soh on November 20, 2017, 05:13:26 pm
Quote
This would also be an issue when hovering in a constant wind for a long time (with the same compass heading).  You need more and more stick to counteract the wind.  That's not right.
Flying in a constant wind changes nothing to the Attitude estimation, simply need bank angle or more bank angle than expected if moving for a multirotor. There is no issue here.
Put your quad in a car and go to the highway, run at stabilized speed for 10km. Is the Attitude (complementary) wrong after a while ?

Quote
It seems to me that needing more and more stick (or a similar issue that comes from flying continuous coordinated circles) is wrong (I know it's hard to fight this issue) ...
You can easily reproduce the issue with complementary, attach your quad to a 3m rope and do turns around you for some time.
A carousel for kids can be used as well.
Title: Re: GPS assist and Heli
Post by: karla on November 21, 2017, 07:10:42 am
Maybe you are trying to arm while the flightmode switch is one GPS/GPSAssisted mode ?
You must choose one flightmode with only primary stabilization for arming.

Nope, I use mode stab5 and stab4 got the GPS assist.
Any other possible reason?
Title: Re: GPS assist and Heli
Post by: f5soh on November 21, 2017, 08:56:34 am
Maybe remove CruizeControl in Stab4

You should do testing in this order:
- basic AltitudeVario
- PosHold
- VelocityRoam and others modes
- GpsAssist

GPSAssist is the latest step and can be properly enabled Heli at end.
Title: Re: GPS assist and Heli
Post by: karla on November 21, 2017, 09:04:20 am
Thanks.
I will try it in that order.
I have tried with all possible combinations for the thrust setting on stab4
- no change, same error.
Will take me a while to get to GPS assist it seems :) so no hurry
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 21, 2017, 10:42:02 am
Quote
This would also be an issue when hovering in a constant wind for a long time (with the same compass heading).  You need more and more stick to counteract the wind.  That's not right.
Flying in a constant wind changes nothing to the Attitude estimation, simply need bank angle or more bank angle than expected if moving for a multirotor. There is no issue here.
Put your quad in a car and go to the highway, run at stabilized speed for 10km. Is the Attitude (complementary) wrong after a while ?

Attitude mode: Hovering in wind in one place at same heading is exactly the same as flying in a straight line for the same length of time, so it is not just FPV that has this issue.  Hovering in the wind would need more and more stick the same way as a long straight flight with no turns.  This is also the same issue as using transmitter trims (instead of Rotate Virtual) to adjust level Attitude mode hover.

This of course assumes I am correct about how Attitude mode works.
Title: Re: GPS assist and Heli
Post by: f5soh on November 21, 2017, 06:19:15 pm
Quote
Hovering in the wind would need more and more stick the same way as a long straight flight with no turns.
Still no issue.

Why more and more stick input ?
What's the limit ?
There is a point where you cannot counteract the wind due to a limited attitude response ?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 22, 2017, 05:10:11 am
Maybe asking a question will help.  If you only use Attitude mode, can you use transmitter trims to stop/reduce the drift or do you need to keep adjusting the trims?
Title: Re: GPS assist and Heli
Post by: f5soh on November 22, 2017, 07:22:20 am
There is already plenty of questions before.
Can you explain why there is a issue flying in a straight line and no issue flying circles using complementary ?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 22, 2017, 08:33:44 am
(Attitude mode) They are both problems.  It sounded like you agree there is a problem when flying in circles, but not that there is a problem when flying for a long time in a straight line, which is the same as hovering in the wind, which is the same as using transmitter trims to stop drift.

In my opinion this situation do not cause any issues.
Title: Re: GPS assist and Heli
Post by: karla on November 22, 2017, 01:26:36 pm
You should do testing in this order:
- basic AltitudeVario
- PosHold
- VelocityRoam and others modes
- GpsAssist

Today basic AltitudeVario completed reasonably well.

It was very gusty winds today and a heli is really sensitive in vertical stab with sudden gusts gives a strong lift on the rotor. So, it was not ideal, but I think it kept altitude reasonably well. Did some adjustments on the Stabilization-Altitude page, but it had limited impact. What had more impact was to adjust the combination of throttle and pitch curves on the transmitter around where hover takes place. Also checked the barometers, they seem okay and fluctuate in less than 1 meter. Next time I will redo it to make sure.
Title: Re: GPS assist and Heli
Post by: karla on November 22, 2017, 02:53:54 pm
Did some adjustments on the Stabilization-Altitude page, but it had limited impact.
What had more impact was to adjust the combination of throttle and pitch curves on the transmitter around where hover takes place.

I have a suspicion here:
the FC in AltitudeVario/AltitudeHold is trying to correct altitude just by altering the thrust, and not by changing the collective pitch of the heli.

This would be logical, its a mode to be set for the thrust.
Also, since both throttle- and collective pitch curves are defined in the transmitter (in my case), there would be no way for the FC to know what pitch to change into, since the pilot is not changing the sticks.

Can anyone confirm if this is how it works?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 22, 2017, 06:37:22 pm
It's my understanding that that is a current deficiency in LP...  The FC will only control throttle or collective, but not both.

It would be fairly simple to add a curve and have the thrust channel control both throttle and collective, but no one has done this...  Sorry.

Do you have open cell foam covering the baro sensor?  That is needed to keep air gusts from affecting baro sensor readings too much.
Title: Re: GPS assist and Heli
Post by: f5soh on November 22, 2017, 07:55:40 pm
Quote
(Attitude mode) They are both problems.  It sounded like you agree there is a problem when flying in circles, but not that there is a problem when flying for a long time in a straight line, which is the same as hovering in the wind, which is the same as using transmitter trims to stop drift.

Yes, there is a issue with attitude estimation using complementary when flying in circles.
Flying in a straight line should not cause issue with complementary, if there is a issue in this situation it should be great if you can explain why.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 23, 2017, 02:05:36 am
Do you agree that there is a problem with using transmitter trims to correct drift in Attitude mode (even when Attitude is the only mode you use)?  I know that changing trims for Attitude mode will mess up Rate mode but that is not what I am talking about.
Title: Re: GPS assist and Heli
Post by: karla on November 24, 2017, 03:19:17 pm
I have a suspicion here:
the FC in AltitudeVario/AltitudeHold is trying to correct altitude just by altering the thrust, and not by changing the collective pitch of the heli.

Unfortunately, I feel pretty sure this is the case.
This is not good news.
The main way to control the vertical position for a heli is not done with the throttle.
The head speed (rpm of rotor) changes little and the collective pitch angle does most of the job.

I am afraid this will be the case for the other autonomous altitude modes as well, like PositionHold, RTB, Pathplanner and GPSassist.
Well true, the vertical component can be disabled, but that makes for example RTB or Pathplanner questionable to use.

I have an idea how to get around this.
If the throttle when controlled by the FC during AltitudeVario is following the throttle curve set in the GCS, then possibly if I can set the Collective curve to follow the throttle, then the pitch will change as well but using its own curve.

To do this I need to move the definition of the throttle- and collective curves from the transmitter to the GCS.
Did that, no problem, its done by un-clicking the option Collective Pass through and set up the two curves in the GCS instead. In the transmitter I just pt them linear. The two curves are very different.
It works and output is controlled by these new curves.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6965;image)


(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6963;image)

However, I want the source of Curve2 to be the throttle, and not as before the Collective. But when I change the source setting from collective to Throttle, then the servos do not move at all when moving the throttle stick. It just moves to what ever value is on the Min position of collective curve. Change the Min value and save and then servos will move to new position and stay there regardless of stick movement.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6967;image)

Any ideas here?
Should be possible to chose Throttle as a valid option since its in the dropdown list box right?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 25, 2017, 05:49:25 pm
Sorry that LP doesn't have a really full heli setup...

If I were doing this, I would start with a governor mode ESC and let the FC control collective.  I think that even BLHeli and SimonK have governor options.
Title: Re: GPS assist and Heli
Post by: karla on November 26, 2017, 03:07:14 am
Thanks Cliff.
The thought has crossed my mind.
The Align ECS, RCE-BL45X, aboard do support Governor mode.

I might look in to it, however, it will be a new way of flying for me and likely present several unforeseen configurational issues and undesired consequences.

Meanwhile, I am tempted to have a look at the code and understand why the curve2source not seem to like the option throttle as source. If that can be sorted its preferred and much more useful for heli users than going governor mode. I have a build environment and next on my MS win 10 machine, so its more to find my way around. Do you guys have some forum for detailed code discussion?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 26, 2017, 05:12:09 am
I'm going to make a guess that there are not a lot of developers that do helis.

Maybe someone else can come by here to suggest a better discussion place.
Title: Re: GPS assist and Heli
Post by: f5soh on November 26, 2017, 08:18:24 pm
Quote
It sounded like you agree there is a problem when flying in circles, but not that there is a problem when flying for a long time in a straight line, which is the same as hovering in the wind, which is the same as using transmitter trims to stop drift.
Did some testing this afternoon, setting a 10 degrees virtual rotation for Pitch and adding Pitch trim using Complementary.
Looks working and didn't see a issue related to attitude estimation after 5 flights.
https://www.youtube.com/watch?v=ve3YnX1yWtw
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 27, 2017, 03:14:32 am
If I'm not mistaken, it would be a problem with long stationary hover with same heading and would reset with each new battery.

Trim transmitter trim for no drift and hover as described.  The problem would be that the trim you start out with is not the trim you need after a long hover with it misconfigured the way you have your quad set.

One of the accel settings, I forget which one, when you turn it up, the issue is more noticeable.  And there was a reason we used to tell people to try changing it.
AttitudeSettings->AccelKp
AttitudeSettings->AccelKi
AttitudeSettings->AccelTau

I will see if I can recreate...
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 27, 2017, 10:21:31 pm
I tried.  I cannot recreate any issue with this.  So I have no problem with the idea of INS13 using only heading from the compass.  Recall that this discussion was whether we needed an option to allow the current (16.09) 3D compass in the new INS13 because inclusion of 3D mag may give better attitude estimation in certain cases.

In this testing, Rattitude mode transmitter trims work just as well as RotateVirtual.  I would never recommend that since changing transmitter trims will mess up Rate mode flight...

I tried Rattitude (forgot it was Rattitude till late in flight; would have used Attitude) with CF/Basic with RotateVirtual roll +10 degrees and could not recreate any issue within the limits of human noticing and fine mode transmitter trims in a 3 minute hover.  I then tried just AccelTau = max; no problem.  I then tried just AccelP *= 4 and Acceli *= 10; no problem.  I didn't check the code to verify whether these are even used in CF/Basic.

AccelTau change recommendations may have been needed more when we had that "base 2" vs. "base 1" sensor data conversion error.  That may be where we suggested increasing the value.  Increased throttle -> increased vibration -> sensor overflow -> bad attitude estimation because of conversion error at max value.

As to whether we ever had an issue where Attitude mode worked better by adjusting RotateVirtual than by adjusting transmitter trims I don't know but assume not...  Maybe I am remembering problems from different firmware brand long ago.  Edit: Or it is a CC3D only issue with the different flight code base, but that doesn't matter for this discussion which was raised because of changes in INS13.
Title: Re: GPS assist and Heli
Post by: karla on November 30, 2017, 10:51:46 am
I have a suspicion here:
the FC in AltitudeVario/AltitudeHold is trying to correct altitude just by altering the thrust, and not by changing the collective pitch of the heli.

When looking more in to this, I get more and more puzzled.
I meant to say in the above post that the FC is trying to correct the altitude by altering the throttle, not really the thrust.
I realize now that I don't understand the difference between these two terms.

In the System Settings, you have these settings:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6983;image)

But in the Systems - Data Settings, you have this additional concept of Thrust:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=6985;image)

Is the throttle the values that comes from the transmitter and the thrust is what actually gets out to the motor(s)/collective via the actuator as lift after the FC tampered with it?

When I look at the values the thrust takes on, its just identical to the values of the throttle...

What is this Thrust thing?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on November 30, 2017, 01:22:34 pm
calculations all use the thrust variable

At the end, the calculated thrust is either put out on the throttle or on the collective.  There is a setting somewhere in System page (I think SystemSettings) that says whether to use throttle or collective.
Title: Re: GPS assist and Heli
Post by: karla on December 03, 2017, 02:53:56 pm
You may switch to Next and get rid of INS13 / 3D Mag issues in 16.09 and also made possible Complementary+Mag+GPS usage.

For now I have put aside all ambitions with the vertical altitude automation.
This weekend I flew some 8 lipo packs, each some 15 min, trying to get the PIDs good and locked-in and the magnetometer to be very stable.
I think it became better and can do position hold on gps for some time (thrust = manual though). However, after a while it gets out of hand and starts making increasingly larger corrections and must be aborted.
When just using attitude mode and INS13 its difficult to get a stable hover without drift by adjusting the mag roll and pitch settings.
I will try the advice to convert to Next and see if that will get a more stable attitude hover in INS13.
If so, then my hope is that the position hold will also work better.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on December 04, 2017, 08:00:50 pm
Just some thoughts...

If you have good Attitude mode flight with Basic AttiEstAlgo, You could test if Attitude mode is good with INS13.  If Attitude flies better with Basic than with INS13, it is probably a mag issue.

You could also try to fly in Rate mode which removes accels from the question.

If bad in both Basic and INS13, you could record telemetry (so you can replay the same flight several times) during a difficult flight and look at accels and gyros for excess noise maybe caused by vibration.

I wonder if mag issues are caused by increased current needs toward the end of flight or when using old batteries.  Voltage drop due to low battery or old battery voltage sag means you need more current to hover.  More current = worse mags?

Good luck.
Title: Re: GPS assist and Heli
Post by: karla on December 05, 2017, 08:20:43 am
Thanks Cliff,

and for sure, Attitude mode with Basic AttiEstAlgo flies like a charm, very stable, no drift, but Attitude with AttiEstAlgo INS13 then its moving around. My conclusion also, its a mag issue. So before I upgrade to Next I should move the Mag to an even better mounting location on the heli and see if that solves all. However, I want the new video gadget for the OSD PFD only available on Next so I will upgrade, and also move mount to a better location.

This will involve some serious soldering to extend the gps/mag cables. I will try make an extension cable rather than a fix soldering of them. I think this is not the problem so I like to revert easily to the original set up.

By this, I (we) will not know if the issue will be fixed by moving the mount of the mag/pgs or if its due to Next software.

I have several log files from last weekend but don't really know what to look for in terms of vibrations... I attach one small one here, if you care to have a look (have a beer instead? or just hint where to look :- )

For mag issues at end of lipo life due to higher current and higher interference, I don't think its likely for this set up. All Lipos new and its the same over 15 min of each lipo flight.
I would have noticed.
Title: Re: GPS assist and Heli
Post by: karla on December 07, 2017, 08:31:44 am
Today I moved the gps-mag unit to better location on heli tail boom,
completed the conversion to Next,
calibrated Attitude using Basic.
It flies well.

Then calibrated mags and turned to INS13 and Attitude.
It flies well.
Then did Pos Hold.
Its really gusty around 6 m/s but it show clear tendencies of 'bowling'.
However, its at a new and better level than before, but still not where I can trust it or where I want it to be :(

My conclusion is I still have mag issues, too much disturbances.
Will try to improve the mount location on heli but it will involve some serious reconfiguration of transmitters etc etc

This feels like a long march...
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on December 07, 2017, 05:08:37 pm
Do you have all your high current wire pairs/triples twisted?  Battery to connector, connector to ESC, ESC to motor?
Title: Re: GPS assist and Heli
Post by: f5soh on December 07, 2017, 09:25:15 pm
Did you do a simple check looking if compass in PFD matches a known North heading ?
Remove the Roll/Pitch in Auxmag orientation and redo a test.
Title: Re: GPS assist and Heli
Post by: karla on December 08, 2017, 01:57:45 am
Thanks guys,
Yes, power cables twisted as fas it allows, even to servos, can't be done everywhere.
Yes, I did the simple compass check, north is where the fc think it is.
Title: Re: GPS assist and Heli
Post by: karla on December 08, 2017, 02:47:54 am
Remove the Roll/Pitch in Auxmag orientation and redo a test.

Well, I removed the trims and put the values back to 0,0 before doing mag calibration. Then I simply left them at that.
Title: Re: GPS assist and Heli
Post by: f5soh on December 08, 2017, 07:17:57 am
Auxmag orientation has no effect while calibrating Mag.

Remember you can test the Complementary+Mag+GPS fusion algorithm assuming you are using Next branch.
Maybe post some log, while flying at same heading may help.
Title: Re: GPS assist and Heli
Post by: karla on December 08, 2017, 07:38:05 am
Thanks. Yes this heli is now using Next branch.
If using Complementary+Mag+GPS instead of INS13, what could be expected? Does it rule out some sensors?
Yes, I can do some logs while flying in same direction, once I got the heli re-configured with the mag/gps mounted further out on the tail boom. I have another trex450 with the gps installed at that location and its doing very stable position hold with a DJI Naza-H FC and GPS.
Title: Re: GPS assist and Heli
Post by: f5soh on December 08, 2017, 09:22:52 pm
If you're happy with Basic (Complementary) in Attitude stabilization, Complementary+Mag+GPS will work fine for all GPS modes.
Title: Re: GPS assist and Heli
Post by: karla on December 09, 2017, 01:29:28 pm
okay, lets see.
Have completed the hardware readjustments today.
tomorrow if weather allows will try it
K
Title: Re: GPS assist and Heli
Post by: karla on December 12, 2017, 03:27:02 am
Too windy this weekend but did fly a bit anyway, ended up with a bad soldering on the power cable and had to abort testing. Next time...
Title: Re: GPS assist and Heli
Post by: karla on December 22, 2017, 05:50:58 am
Finally, yesterday I got to fly some 3 packs and try the improved location of the mag/gps unit and the Position Hold.
It holds position better.
Still have bowling motions, but not always and not as much as before, but still more than acceptable. So I conclude I still have remaining disturbances with the compass.
I only fly in Attitude mode and using Next.
It flies good in Basic, INS13 and 'Basic+Mag+Gps'. Tried PS in both INS13 and B+M+G, with no noticeable difference what I can see.

There might be additional issues with my Heli, though.
At the end of the last flight there was a sudden drop of engine power. Then motor spin back up again but enough late to almost end on ground.
I would need some help to determine (if possible) Was this because of a radio link failure (failsafe) or was the failsafe due to a short power outage from the LiPo's, a cable disconnect ?
Where to look in the log-file?

It happens during the last 20 seconds of the log file.
During this flight I move in and out of PH several times.

Thanks a lot
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on December 22, 2017, 10:55:20 am
I forget:  Are you flying 16.09 or recent "next" or some other version?

There is a thing called "bumpless transition" in the thrust/throttle management PID for PH.  A safety fix was put in to "next" that broke this "bumpless transition" and I don't know if that breakage itself got fixed.  "Bumpless transition" is supposed to make sure the thrust actuator has the same value when you switch into PH, rather than some other value and the aircraft say descends before determining that it needs to add thrust.

If I am correct though, this would be for the thrust channel, so if your motor power dropped (to zero) but you are configured to use collective for thrust control, this is probably not your issue.  If you are configured to use throttle for thrust control then this could be the cause.

You could replay the log file and watch the bottom status line of the PFD to see if it went into failsafe.  There are also some alarms you could check by configuring and watching a scope on the chance that it was so brief that it did not show up on the PFD long enough to see easily.

If you use DJI/Naza GPS, you might try the patch 16.09 firmware I did or patch the next source with the same changes from that thread.
Title: Re: GPS assist and Heli
Post by: karla on December 30, 2017, 01:55:05 pm
Hello and thank you cliff!
Christmas came in between :)

I forget:  Are you flying 16.09 or recent "next" or some other version?
Next

There is a thing called "bumpless transition" in the thrust/throttle management PID for PH.  A safety fix was put in to "next" that broke this "bumpless transition" and I don't know if that breakage itself got fixed.  "Bumpless transition" is supposed to make sure the thrust actuator has the same value when you switch into PH, rather than some other value and the aircraft say descends before determining that it needs to add thrust.
Right now its pretty Bumpy when switching from Manual to AltitudeVario thrust mode. However, much less so, after I adjusted the Thrust limit for Neutral, it was way off.

If I am correct though, this would be for the thrust channel, so if your motor power dropped (to zero) but you are configured to use collective for thrust control, this is probably not your issue.  If you are configured to use throttle for thrust control then this could be the cause.
Now, this is a really interesting idea you have. Really.
However, I don't think it works like this at all.
There is no way or place you can select if 'Thrust' is managed via throttle or collective.
Please prove me wrong, it would be fantastic :)

You could replay the log file and watch the bottom status line of the PFD to see if it went into failsafe.  There are also some alarms you could check by configuring and watching a scope on the chance that it was so brief that it did not show up on the PFD long enough to see easily.
Did replay it and looking for useful variables to check, but was unable to determine if the motor outage was due to a power outage from LiPo or a radio glitch causing the failsafe (and shutting motor down). Anyways, last soldering of power cables seems good. The OPLM unit on the heli did have a bad connector of the antenna and have swopped for another unit now. Also changed the 'Air Data Rate' up to 100.000 baud from 64.000 as suggested by Laurent.
Now it seems a good stable connection and I dont expect any motor or failsafe issues going forward.

If you use DJI/Naza GPS, you might try the patch 16.09 firmware I did or patch the next source with the same changes from that thread.
I use a OP gps unit now. However, I consider a DJI unit if this do not show improvement.
I have one on another Trex450 mounted at the same place and it holds position just fine.


The heli is set up fine now and I plan to head for the field tomorrow to test position hold :)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on December 30, 2017, 06:20:03 pm
It has been a long time since I looked at heli thrust, but back then, you use your transmitter throttle stick to control something called Thrust (called thrust for all vehicle types), then in the setup you tell it (SystemSetting->ThrustControl) whether Thrust controls the throttle channel (coming out of the FC) or the collective channel.

It should be possible to use a governor mode ESC (same RPM at any load) connected to an aux channel, then use Thrust=Collective for good heli setup ??
Title: Re: GPS assist and Heli
Post by: karla on December 31, 2017, 05:47:24 am
OMG, you are right, I found it.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7046;image)

This gives me new hope, will explore it.
But after I get the 'bowling' to a complete stop
Thanks
Title: Re: GPS assist and Heli
Post by: f5soh on December 31, 2017, 01:02:24 pm
Quote
OMG, you are right, I found it.

:D
https://forum.librepilot.org/index.php?topic=3999.msg27035#msg27035
Title: Re: GPS assist and Heli
Post by: karla on January 01, 2018, 05:21:48 am
Yes, I missed that.
It was not my focus at the time, sorry laurent.

Meanwhile, I flew some more yesterday.
Its still 'bowling' while in position hold more than I think is acceptable.
I compared the direction of north to my iPhone compass and noticed it points to the same direction but during a 60 sec period the direction is moving around +10 to -10 degrees.
This is when standing on ground and mags are different there, however it can't be good.

I think already did my best to twist cables and find best possible location to mount the mag/gps on heli. Now will try another unit.
If that will not work I think need to find a drastically different mounting.
Or maybe its the material on the whole tail boom...
I tried to have another unit with mag standing still and then move the heli over and around it, it is showing some more error % but its difficult to draw any firm conclusions.

 
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 01, 2018, 09:49:46 am
Once you start calibrating mag, it is always getting data until procedure is complete.

You should not set model on the ground or set it on anything metal or even calibrate close to big metal things (car, metal tanks, etc.) at any time once you start the procedure until it is complete.

You can click the GCS mag cal "next position" button 5 times before you even start, and leave it on the 6th position, and then do all the positions, then click the button the 6th time.

You can just do the "Naza dance" instead of the 6 positions.  I do a different 6 position dance where I simply point (and wiggle a little) each of the 6 directions of the model (nose, tail, left, right, top, bottom) at the north mag field which for me is north and 60 degrees down.

World magnetic inclination map
https://en.wikipedia.org/wiki/File:World_Magnetic_Inclination_2015.pdf

LiPo alarms have magnets in them.

You can find the limits of the mag fields of things by setting a spare FC on the table.  Connecting it to GCS.  Watching mag scope in GCS while you move the model close to it.  When you see the scope change you have found a mag field in the model and have found how large it is.
Title: Re: GPS assist and Heli
Post by: karla on January 02, 2018, 12:33:43 pm
Thanks Cliff, as always.

I got all of those points.

Today, i was flying with a new unit, another OP though. Also fixed it loser with 3m thing not tied down so hard to prevent vibrations. I was really hoping it would make a difference. However it did not.
I had a bad crash, could not prevent it from hitting some trees after going in to position hold mode.

Damage report:
. Main shaft bent - must be replaced
. Feathering shaft bent - must be replaced
. Tail shaft bent - must be replaced
. both main rotor blades smashed - must be replaced
. one power cable to motor snitched off  - must be resoldered
. battery holder string torn off - must be amended
. 3D gimbal camera totally smashed - need to be replaced :(
. Video tx antenna broken - needs to be replaced

Today I don't feel happy,
maybe this hobby is not for me ...
 :-\
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 02, 2018, 05:01:33 pm
Oh man.  Sorry about that.  :(

One time I had an oscillation that seems to be caused by GPS in NMEA mode.

Does it hover well (no toilet bowl) in Rate mode and Attitude mode?  Maybe reduce some PIDs in VtolPathFollowerSettings.

I've got an old 300 size clunker that I have been planning to get back out and put an FC on...

Good luck.  :)
Title: Re: GPS assist and Heli
Post by: karla on January 05, 2018, 09:42:40 am
Thanks a lot Cliff.
Where I come from we don't give up easily so I am back on to this,
eventhough I might be wiser just to drop it and move on in life  ::)

I am really curious why it behaves like this.
There must be a reason. I dont belive in mystries.

To your direct questions,
yes it hovers nicely in rate (thats up to the pilot) and also in attitude mode, provided i use Basic est.

When using est of INS13 its a different story. Its totally nice to fly in INS13 and Attitude when the mags settings are in 0,0,0 for roll, pitch and yaw. But when I tried to compensate for the strong drift (to the right, having tail in), it does not seem to matter how much I put in there. I start with 5 degrees up and moved to 20 degrees roll compensation for the mag. Bare in mind this is after the Basic Attititude is perfectly stable with the board oreintation settings. The only thing changed is the INS13 est.
It becomes incontrollable.
Ended up in tree  :'(

(I noticed the wiki recently been edited/changed - at Fine tuning... talking of INS13 compensation https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/18382863/Aux+Mag+Setup+and+Calibration )
so now it make more sense in what direction to compensate drift :)
Unless its wrong :( and should be as before?

Anyways, it does not work for me.
i have tried to increase and decrease companesation but it does not do much change at all to the real movements of the heli.
Maybe the mag axis i am trying to correct is not the correct one? Its yaw or pitch and not roll ???


In addition to this question, i just want to share two different configurations,
maybe someone can spot someting obvious that i am missing?

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7052;image)

To the left in the picture is a really nice working postition hold trex 450 with DJI gps and Naze-H flight controller.
To the right is the LibrePilot FC with OPLM radio link and gps.

You spot anything that would disturb mags a lot more?

Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 06, 2018, 09:07:53 am
Your toilet bowl sounds like it is caused by mag not aligned with other sensors.

I see that you are using "next".  I understand that next effectively uses 2D mag.  I greatly suspect that you must leave the mag alignment / orientation / rotation numbers at 0,0,0 for OpGpsV9/DJI GPS/mag (0,180,0 for APM/I2C mags) for "next".  It is OK to change the 0,0,0 to correct for the case where you visually see that the mag is not mounted straight.  You should not change it to fix hover drift like the wiki says.  I will edit the wiki right now.
Title: Re: GPS assist and Heli
Post by: karla on January 07, 2018, 12:40:29 am
Yes, using Next.
I also think they better be left at 0,0,0 since it really don't seem to make any noticeable change on the drift when flying Attitude in INS13 or Basic + Mag + GPS.
I noticed that I need to re-adjust the board trim every time I change LiPo.
I adjust the trim while flying Basic and Attitude.
I was thinking that these battery packs are much larger and heavier than the stock ones and therefor Heli becomes more sensitive to how they are mounted (a little bit forward or aft or left, right have more impact).
But could the drifting in attitude be caused by the Accelerometers not being calibrated in a good way?
Its been difficult to put the heli in all the positions that is required and its not been straight at all times...

Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 07, 2018, 06:25:13 am
Transmitter trims should be centered where they were when you did transmitter wizard.  You can check trim centers on the Input page with flight battery plugged in and transmitter on.  Of course set RotateVirtual to make it hover without drifting in Attitude mode.

Stabilization -> ZeroTheIntegral... should be enabled or it will go a bit crazy at takeoff

Stabilization -> Advanced -> EnablePirouetteCompensation should be disabled or an unbalanced aircraft will become unlevel when you pirouette with yaw in some flight modes.

What all modes do you use that you have problems with?  Rate and Attitude have different causes.

Quote
I noticed that I need to re-adjust the board trim every time I change LiPo.
Trim will change when you change from Rate to Attitude if transmitter trims are not centered.  Also, does this happen with Basic and INS13 AttiEstAlgo or just INS13?  Just INS13 should only happen in 16.09 with fairly bad mag problems.
Title: Re: GPS assist and Heli
Post by: karla on January 08, 2018, 06:18:59 am
It’s in Attitude mode - the problem is getting a steady hover without drifting, once and for all.

It first happens in Basic AttiEstAlgo after changing LiPo.
The drifting can be fixed by adjusting System Settings BoardLevelTrim +/- some 3-6 degrees
(I usually don't touch the BoardRotation setting since its the main mounting of the board).
But, for the next LiPo pack, then I will most likely need to adjust the settings again to compensate drift.
I was just thinking if this can have anything to do with poorly calibrated accelerometers?

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7054;image)

After I have completed a good trim in Basic, then I switch over to AttiEstAlgo INS13 (still using Attitude and same LiPo).
Then it will drift a lot (like 10 degrees off), most often drifting to the right and some backwards.

I am aware that Mags are treated differently in Attitude in INS13 when using LP 16.09 from using LP Next.
You may switch to Next and get rid of INS13 / 3D Mag issues in 16.09 and also made possible Complementary+Mag+GPS usage.
I was actually hoping LP Next would be the solution and fix the drift in INS13 - but it did not, so this might be a different issue  :-\
b t w I have also tested with AttiEstAlgo 'Complementary+Mag+GPS', but behave similarly.

It was after that, lacking other things to try, I changed the Mag rotation setting for Pitch anyway  ::)
After raising it gradually and nothing happened i was up to -40 degrees (drift was forward), then I lost it in the tree unable to apply enough neg pitch.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7056;image)

. Trims - I never use the trims on the transmitter, they are always centered (easily checked on the display of TX).
. ZeroTheIntegral - enabled
. EnablePirouetteCompensation - disabled
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 08, 2018, 07:31:51 am
Just some thoughts.  Maybe some are new...

If it happens in Basic, then maybe:
- FC mounting is loose or frame is loose and some screws need to be tightened
- vibration
- gyro calibration/bias issue

Are you running the stock settings that delay gyro calibration (in Basic AttiEstAlgo) until the FC is motionless, or did you change them?  Could it be that gyro is not calibrating well each new battery because vehicle is moving a little?  If that is the case, then INS13 might not have the issue.

I can sort of imagine that it could be a warmup issue where the board is warmer the second battery than the first battery.

Maybe you should redo the thermal calibration.  I presume you have at least done it once.  You might consider redoing all calibrations...

Thermal calibration and INS13:  I have found that after doing thermal calibration, you must recalibrate gyros to get the gyro scope to center at 0,0,0 but I wouldn't think that would drift from battery to battery.

Check your accel filter settings (pages: Stabilization and maybe Attitude) to make sure they are default.

Does it only need roll changes?  If so, I wonder whether "more throttle with less collective" vs. "less throttle with more collective" is changing the roll angle required for level hover.  The more collective you use, the more drag and the more tail rotor it needs to correct for the drag and the more bank angle the main rotor needs to compensate for the tail rotor thrust.  Similarly, a different weight (bigger battery or adding a camera) would do this too.  I wouldn't imagine this would be 6 degrees difference though.

Maybe tightening the battery strap a different amount warps something that is springy and causes the FC to be at a different angle.

FlySky transmitters have a problem with loose wires.  Really.  This is a problem with wires to pins connecting the pots.  Moving the vertical axis wiggles the wire to the horizontal pot.  If you have a FlySky transmitter, please read this for a video to prove if you have the issue and a fix I found:
https://www.rcgroups.com/forums/showthread.php?p=38300831&postcount=1755

Settings don't save permanently when FC is armed.  Maybe you are just moving it from 1.0 to 5.0 over and over?
Title: Re: GPS assist and Heli
Post by: karla on January 08, 2018, 08:03:09 am
Wow :)
thanks for thoughts - some very new. I will run the list one by one later, but for now I trigger on the thermal calibration.

No I have not done a thermal calibration on this board. I have many and only did it once with one Revo and saved the settings and then update all my other Revos with those settings. The reason is that its troublesome and time consuming to do that calibration and don't really seem to matter.

But now I really have a reason to ask something I been thinking about for a long time.
Can I use the calibration details here below and just update the board?

Code: [Select]
<!DOCTYPE UAVObjects>
<uavobjects>
    <settings>
        <object name="AccelGyroSettings" id="0x1262B2D0">
            <field name="accel_bias" values="-0.000841957,-0.0601984,-0.569099"/>
            <field name="accel_scale" values="1.00235,0.994619,0.988395"/>
            <field name="accel_temp_coeff" values="0,0,0"/>
            <field name="gyro_bias" values="0.0322891,0.00425314,0.00241962"/>
            <field name="gyro_scale" values="1,1,1"/>
            <field name="gyro_temp_coeff" values="-0.0186192,-0.00151585,-0.0267329,0.000716467,-0.0101649,0.00010742"/>
            <field name="temp_calibrated_extent" values="-15.8235,72.0824"/>
        </object>
        <object name="RevoSettings" id="0xC456EB9A">
            <field name="BaroGPSOffsetCorrectionAlpha" values="0.999334"/>
            <field name="MagnetometerMaxDeviation" values="0.05,0.15"/>
            <field name="BaroTempCorrectionPolynomial" values="-0.0644952,0.00604459,-0.000197262,1.42936e-06"/>
            <field name="BaroTempCorrectionExtent" values="-17.42,72.04"/>
            <field name="VelocityPostProcessingLowPassAlpha" values="0.999"/>
            <field name="FusionAlgorithm" values="Basic (Complementary)"/>
        </object>
    </settings>
</uavobjects>

its from the LP Wiki https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/12058675/Sensor+calibration#Sensorcalibration-Thermalcalibration (https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/12058675/Sensor+calibration#Sensorcalibration-Thermalcalibration)


If yes, great!
If no, why not?
Can these boards be so different?
Is it better to not do the calibration at all, or to import these settings?

Thanks for being around Cliff and - Happy New year!
/Karlitos
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 08, 2018, 05:11:42 pm
Using any calibrations from Revo#1 on Revo#2 is about as bad as not doing calibrations at all.  That includes thermal calibration.

Yes, I do cut out those calibrations and save them as a separate uav file, but I mark each board and mark each file to match the board it goes with.

I do the following to upgrade to newest LP version where UAVOs changed:
- export UAV file twice, to two different names (one of them will be modified, one kept for fallback) old.uav and new.uav
- use uavofix to modify new.uav so that name comes first (before value) on each line
- erase settings and export that UAV file to olddefault.uav
- use uavofix to modify olddefault.uav (not usually needed) so that name comes first (before value) on each line
- upgrade to new version
- export UAV file to newdefault.uav
- use uavofix to modify newdefault.uav (not usually needed) so that name comes first (before value) on each line
- use grep or a text editor that can quickly and easily switch between two files so you can flip back and forth between exactly the same page in olddefault.uav and newdefault.uav and the "blink test" will make changes obvious.
- where ever you find a change between olddefault.uav and newdefault.uav, understand what the change ls (insert new default value, rename variable, add extra value, etc.) and make a change in new.uav.  Any change in a UAVO will change the object ID, so you will change a lot of those.  Important to decide if you think that what you are doing for that line is safe.

Here is a set of 16.09 "calibrations only" for my Sparky2#1
Code: [Select]
<!DOCTYPE UAVObjects>
<uavobjects>
    <settings>
        <object id="0x1262B2D0" name="AccelGyroSettings">
            <field name="accel_bias" values="0.0518125482,0.125044808,0.728489697"/>
            <field name="accel_scale" values="1.00152528,1.00071549,0.983911216"/>
            <field name="accel_temp_coeff" values="0,0,0"/>
            <field name="gyro_bias" values="-0.578340948,-0.517927885,-0.588053286"/>
            <field name="gyro_scale" values="1,1,1"/>
            <field name="gyro_temp_coeff" values="-0.00543077243,0.000153706147,0.0181076545,-0.000194396431,0.000825154886,4.76835885e-05"/>
            <field name="temp_calibrated_extent" values="-1.91499996,81.534996"/>
        </object>
        <object id="0xB20D3DE" name="AttitudeSettings">
            <field name="BoardSteadyMaxVariance" values="5"/>
            <field name="InitialZeroWhenBoardSteady" values="True"/>
        </object>
        <object id="0x9A5BA08" name="RevoCalibration">
            <field name="mag_bias" values="-114.978195,-195.573441,-47.4925842"/>
            <field name="mag_transform" values="1.7704668,0,0,0,1.73121321,0,0,0,1.77277255"/>
        </object>
        <object id="0xC456EB9A" name="RevoSettings">
            <field name="BaroTempCorrectionPolynomial" values="-43.4937019,2.87412429,-0.0833765119,0.000425159669"/>
            <field name="BaroTempCorrectionExtent" values="-4.36000013,75.0400009"/>
        </object>
    </settings>
</uavobjects>:

I removed some "non calibration" fields from some UAVOs

I included mag calibrations but you should really redo mag calibrations when you move the FC to a new model.

I included BoardSteadyMaxVariance and InitialZeroWhenBoardSteady.  These are only modified if you are using Basic AttiEstAlgo and you have a marginal FC, but if you change them, you probably want to keep the values.  This is documentation for others that may read this.

Here is the (Linux) command that I wrote to fix the name / value order; I call it uavofix:
Code: [Select]
#!/bin/bash

if (( $# != 1 )); then
  echo Usage: uavofix filename.uav
  exit 1
fi

if [ -f "$1" ]; then
  directory="$(dirname "$1")"
  original="$directory/original"
  mkdir "$original" 2>/dev/null
  if [ -f "$original/$(basename "$1")" ]; then
    echo Backup file exists: \"original/$1\"
    exit 2
  fi
  mv "$1" original
  sed -e 's/\(values=\".*\"\) \(name=\".*\"\)/\2 \1/g' -e 's/\(id=\".*\"\) \(name=\".*\"\)/\2 \1/g' < "$original/$(basename "$1")" > "$1"
  # beware that this touch makes some editors blind to the changes (they won't ask for reload)
  touch -r "$original/$(basename "$1")" "$1"
else
  echo File not found: \"$1\"
  exit 3
fi

To do thermal calibration I connect USB cable to FC, put FC in a fairly sealed (keep moisture out) plastic bag with usb cable extended to come out of bag.  Put in freezer for 10 minutes.  Get it out of freezer and put it in the bottom of a small box with paper or cloth towels wadded on top to hold it against the bottom.  Sit box firmly on a hot light bulb in a way where it won't move.  Immediately start thermal calibration.  Don't let the box move at all until thermal cal is complete.  Unplug light bulb a bit before FC it gets to temperature you want.  I go from 0 degrees C (I may want to fly when it is freezing) to 70 degrees C (one of my quad FC is inside a dome and it gets to 70C in mid summer when sitting in the sun and powered on).  These extremes (especially the 70C hot side) may do more harm than good, both to the FC and to the polynomial which may not handle such a wide range very well.
Title: Re: GPS assist and Heli
Post by: karla on January 09, 2018, 03:55:12 am
Thanks.
A question when coming to the Accelerometer calibration.
Since my fc is mounted standing on the side inside Heli, it needs a virtual rotation setting.
Should I zero out the virtual rotation 0,0,0 before doing the calibration?
And follow the instructions in the GCS on what side up, down etc.
Then change virtual rotation back to adjust for the mounting after calibration is completed.
It should matter right?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 09, 2018, 04:27:03 am
There are two accel calibrations.  The one called accel calibration is the board only "removed from vehicle" (if reasonable).  It shouldn't matter how RotateVirtual is set for that.  The other one is leveling calibration.  You should have RotateVirtual set correctly before running that.  So I would just leave RotateVirtual set correctly for both.  Read the help (last tab) for some info, but assume you need all calibrations, and redo gyro calibration after thermal calibration.
Title: Re: GPS assist and Heli
Post by: karla on January 09, 2018, 11:20:15 am
This is the one I want to discuss.
Skip the other one, I got it covered.

What you say is totally unexpected to my expectations ...

The one called accel calibration is the board only "removed from vehicle" (if reasonable).  It shouldn't matter how RotateVirtual is set for that. 

How, can that be possible?
The data collected during calibration must be wrong:
when for example: Turn board Up side Down, when it its not upside down at all?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 10, 2018, 05:56:02 am
"Accelerometer calibration" is best done with board removed from model (see calibration help tab).  If you don't remove it from model, you should pretend it is removed from model and know that the rotations are all about the board orientation.  This is one of the low level calibrations.  It really just calibrates the raw accel bias (zero point) and scale (multiplicative factor) and doesn't know anything about vehicle leveling or gyros, like gyro calibration is low level and only knows gyro bias.

I would consider it a bug if this needs to have RotateVirtual set to 0,0,0 ... but I have not tested that.
Title: Re: GPS assist and Heli
Post by: karla on January 10, 2018, 06:29:06 am
Thank you Cliff.

This part of the calibration is so difficult for me to understand - the Accelerometer part.

It is measuring/calibrating the gravitation, so I have to set home location first, since that is different where you are located on the globe and especially the hight over sea level, I would take it.

If it dosn't matter what orientation the board has when they ask for Turn it upside down, Turn it left side down etc etc,
is it more like the magnetometer calibration - no need to know where north is, the important thing is to move it around in all possible orientations?

I thought the point was to measure the gravity acceleration values for each orientation, for example,  Upside down, for later usage in the AttEstAlg.

Anyway,
This time I need to rip the FC out of the heli to complete the magnetometer cal anyway, can't fit the whole heli in my freezer :)
So I will put orientation to 0,0,0 and do the Accel cal by the book.
My only concern is that, when mounting it back again in heli and add the virtual rotation, that the accel will be bad and AttEstAlg be confused  :-\

When I go to Europe next time the Accel cal should have to be re-done?






Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 11, 2018, 02:08:36 am
As far as I know, the accel cal has never used a home location, but your point that it could use one for best accuracy is true...

I think this is because CC3D and Basic don't need it (no home location) and INS13 allows calibration with home location values farther up the stack and that could take it into account.

It does matter what orientation the board has.  That is what it asks you for.  If you do it with it still mounted in the vehicle, just hold the vehicle so the board is in the desired orientation.

I would not rip it out just to put in in the freezer.  Most people just do it from cool room temperature to full warm temperature.  a 10C difference is all that is required IIRC.  If above the equator, maybe just put it outside in the winter for a few minutes...
Title: Re: GPS assist and Heli
Post by: karla on January 11, 2018, 03:49:10 am
Ah.
It would save me a lot of trouble and time if I can leave it mounted inside heli while doing these calibrations (thermo and accelerometer).
Its minus 5 C outside today so I will try that.
Also will try just keep the virtual orientation setting but placing the board in the positions GCS asks me.

In the previous accelerometer calibration i have been flying with, I did it with the virtual orientation set, but placing the whole heli in the positions GCS asked me.
This should make a difference... maybe this is one reason why Attitude is confused...
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 11, 2018, 04:59:54 am
for accel calibration:
-------------------------
Make sure the board orientation is as requested, as exactly as possible and as motionless as possible.

Heli landing gear on floor, on wall (joint with floor for completely locked in orientation), ceiling upside down...  The motionless part is probably the hardest issue.  Good luck.

for thermal calibration:
----------------------------
The main issue is that it needs to be completely motionless for the whole time.  Afterward, you may want to look at gyro scope and notice there is a slight bias now.  The gyro noise is not centered exactly on zero.  To fix this, just make sure to run the gyro calibration again, after the thermal calibration.  The scope will show you that it is fixed now.
Title: Re: GPS assist and Heli
Post by: karla on January 12, 2018, 09:12:57 am
Ah thats a great idea to do floor, wall, ceiling for support.
I might need to redo it later, but I think I got the thermo calibration okay.
It was tied down heavily and I applied a hair dryer gently blowing hot air over the frame.
It said the range was some 60 degrees range from 3-4 C up to over 60.
I am still waiting for the delivery of my main shaft before I can do any flying.

Title: Re: GPS assist and Heli
Post by: karla on January 17, 2018, 10:42:36 am
Hehe, very happy now the main shaft arrived.

So, i have already repaired/completed the following:
. Both main rotor blades now balanced with each other
. Rotor blade tracking now okay
. Swashplate levelling, smooth and horizontal all from Max down to Min position
. Collective pitch angles of blades now set okay for Hover, Max and Min (stock Align angles)
. Throttle curves for recommended Head speed now set okay

This time I want to go about the 'Hover without drift' differently than from before, that was by settings of the virtual rotation of the board.
(Helis need compensate the tail rotor thrust giving a roll angel to the whole craft)
Now, I want to adjust the swash plate angle instead to accomplish the same end.
Reason is to easier pilot take off and landings in Attitude mode (especially when flying fpv) and a more consistent behavior of craft when flying in rate and attitude modes.

So, to adjust the swash tilt angle, there are some 3 ways of doing it (personally I prefer option 3).
1. Using GCS Vehicle, Helicopter, Swashplate levelling:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7080;image)
 
Maybe most user friendly, but has many process steps we don't need just for tilting swash to stable hover.

2. Using the Output tab

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7082;image)
 
This is very clear and good overview and don't have unnecessary process steps for our purposes, but it involves the scary part of motor also be active. You can unplugg at least 2 wires to the motor to avoid this though.

3. Using Settings Actuator ChannelMax Neutral and Min
 
(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7084;image)

This is not a user friendly interface but it does the job - smack on.
Just enter a new number and press the red upward looking arrow button to save to the board.

One useful thing to know is which servo to adjust when using your selected option.
For most trex450 size helis the servo swash plate setup will be:

                   West servo | East servo | South servo
                   Left servo  | Right servo | Aft servo

Option1:   1                3                2
Option2:   Roll1         Elevator   Roll2
Option3:  [ 0]           [ 1]             [ 2]

Now, you only need to fly the heli (in Rate stabilization and Basic AttEstAlg)
and adjust the 3 servos so you get a hover without drifting.
Just adjust the Min, Max and Neutral values equally much. For example drifting to the right - then increase (if not channel reversed, if so then decrease it) the East servo by 25 units increments for each Min, Max and Neutral value. Then fly it and see the result. Adjust again.

When successfully completed, the swash plate will be tilted in such a way that the heli is hovering without drift. Furthermore, it will keep this tilt all through to travel of collective pitch from min to max.

That's what I'm going to do now.
Title: Re: GPS assist and Heli
Post by: karla on January 21, 2018, 12:48:29 pm
Wow, this was fun.
Completed the swash level hover bit okay. It flies fine in rate mode in basic.

Then moved on and set my Heli Align ESC to governor mode (never tried that before) and the GCS to System | System setting | ThrustControl to  Collective (from throttle).
And it works!
The fc is using the collective only, to control altitude in altitudeHold mode, no throttle.
The ESC is trying its best to keep the head spead rpm constant as the load increased with more collective.

I am using Basic as AttEstAlg, since I do have problems with vibrations after having to replace a lot of parts on the heli.
I need to work more on these vibrations and having heli experience, i know what i am up against. can not move to EST13 until its resolved.

However, I have more crucial problem.
I am getting these failsafe disconnects often, every 30 sec or so, and just for some half second than it connects again. But as you can imagine it disrupts everything.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7097;image)

I have a OPLM on the heli feeding in to a Revo board (that particular revo has a non functional radio) and I have a transmitter OPLM feeding PPMs from my tx training port.

If anyone of the gurus here can take a look at the log file from today and maybe spot something pointing to where i should look, i would be very appretiative.

especially the
OPLinkStatus.LinkState (function)
OPLinkStatus.RSSI (dBm)
Why does it disconnect when the dB is so good?

Added the log file and configuration file.

Really don't understand why this flip out now, it worked fine before, only thing change is maybe vibrations ...

Title: Re: GPS assist and Heli
Post by: f5soh on January 22, 2018, 12:25:08 pm
You can remove the PPM wire and get channels using the OPLinkReceiver object so the only wiring between board and OPLink (in heli) is the telemetry connection. You may need to just remove the PPM port configured in OPLink receiver.
Using this method you will be able to monitor the remote OPLink, at least when connected and see if the RSSI levels are ok in both sides.


Title: Re: GPS assist and Heli
Post by: karla on January 22, 2018, 12:56:41 pm
Thank you Laurent,

It sounds interesting, and I am really willing to try it,
but I just dont understand how that will work.
Please take this very slow and step by step please  :)

Here is the current OPLM configuration on the transmitter side:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7101;image)

Here is the OPLM on the receiver side on the Heli:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7103;image)

What should I change?
And how will it work without ppm? Remember the Revo board in the heli do not have a working oplink radio (it will hang if i put transmitting watt higher than 0).

To be as clear as I can, here is also the Remote Control set up with PPM:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7105;image)
 
Title: Re: GPS assist and Heli
Post by: f5soh on January 22, 2018, 01:26:54 pm
Just remove the PPM/FlexiPort set in OPLink Receiver. Save

Reboot all and try moving stick, you will see "OPLinkReceiver" or just "OPLink" activity, don't remember.
Later channel input configuration uses "OPlink" type instead of "PPM" type


Title: Re: GPS assist and Heli
Post by: karla on January 22, 2018, 02:01:57 pm
I did disable the PPM/FlexiPort setting in OPLink Receiver.
Did save it, and reboot.

Next, I changed all PPM to OPlink for each of the 7 radio channels in the Remote Control Input tab.
Saved. rebooted.

Now the telemetry works fine.
But I have a big red alarm for INPUT in the system health gadget.

I then even tried to change the Receiver Port settings from PPM+Telemetry to just Telemetry and saved and rebooted.

Still red on INPUT.

Maybe something else is needed?

 
Title: Re: GPS assist and Heli
Post by: f5soh on January 22, 2018, 02:29:11 pm
Red input means there is a channel not set or something bad in Input configuration.

Just done a test with a Revo Nano and RC control over telemetry works fine.
Title: Re: GPS assist and Heli
Post by: karla on January 23, 2018, 01:27:28 am
Good to hear it works there.
Yes Input show red and when I move the sticks around the Receiver Activity field is dead and show a steady green No activity.

The only thing I changed (from before with the working PPM setup) was
. to disable the PPM/FlexiPort setting in OPLink Receiver and
. change the channel Type from PPM to OPlink for each of the 7 radio channels in the Remote Control Input tab. All the channel numbers, min max neutral etc are kept the same.

Any other setting needed to accomplish RC control over telemetry?
Title: Re: GPS assist and Heli
Post by: f5soh on January 23, 2018, 01:45:41 am
Quote
Any other setting needed to accomplish RC control over telemetry?

No
Post your config file.

** Edit I think the PPM over telemetry cannot work since the Revo should already work using his internal modem...
Title: Re: GPS assist and Heli
Post by: karla on January 23, 2018, 02:42:11 am
Yes, you may have a point there.
I will try another Revo with a functional radio.
Title: Re: GPS assist and Heli
Post by: karla on January 23, 2018, 03:55:34 am
Yes, confirmed. With another revo board where the radio is working, the transmitter show activity, OPLink input... when I move the sticks. That even the Type is set to PPM and not OPLink.
Thank you.
Now I need take a step back and consider how to set this up  :-\
Title: Re: GPS assist and Heli
Post by: karla on January 23, 2018, 07:20:42 am
Is RC control over telemetry also supposed to work on LP 16.09?
Title: Re: GPS assist and Heli
Post by: f5soh on January 23, 2018, 10:46:57 am
No, this feature is introduced with LP-548 (https://librepilot.atlassian.net/browse/LP-548)
Title: Re: GPS assist and Heli
Post by: karla on January 23, 2018, 12:36:10 pm
okay thats why :)
I think this is a really nice improvement.
Seems so redundant to have a separate PPM thing going separately while you have a perfect data communication going anyway with telemetry.
I have some unexpected results using it though and maybe I start a separate thread about this.
It feels very much worth it to get it running smooth.
Thanks a lot
Karl
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 23, 2018, 10:16:55 pm
One of my new, cheap clone OpLinks has a 43khz AFC Correction shown when testing it with next.  That is more than a whole 40khz channel.  It seems to work better than expected in low power testing, but one of the things I noticed was that the Rx Level jumps back and forth from OK (say 50) to bad (say 75) without moving anything.

If I were to move these apart a little more, the 75 would turn into a regular drop out like you are seeing.

I suspect that the "channel order" of this device doesn't match the good devices.  "Off by one channel" would cause the 43khz AFC Correction, but maybe the "channel order table" (actually frequency synthesizer divisor) is wrong in other ways too.  I have played with the min and max channel settings (didn't help).  I could have tried different combinations of OpLinkSettings->HopChannel but I just grabbed a different OpLink when I found this problem.
Title: Re: GPS assist and Heli
Post by: f5soh on January 23, 2018, 11:24:14 pm
OpLinkSettings->HopChannel setting is related to OpenLRS, nothing to do with OplinkReceiver or OPlinkCoordinator usage.
In all cases the OpLinkSettings->HopChannel do not need changes at all, this is populated according to the OpenLRS binding and updated on binding.

In OPlink setup channels used for hopping are simply generated using min/max channels defined by user.
Since the limits are the same in both devices the channel list are the same and "in phase" in both devices.

Except if you are using low baudrates the frequency deviation (and almost channel bandwidth) is set as follow:
 100 kbps - 60 khz
 128 kbps - 90 khz
 192 kbps - 128 khz
 256 kbps - 150 khz

A AFC correction is not really a problem at short range but a Xtal tuned (aka AFC~0Khz) can help for quick reconnect when link is lost at larger range.
Title: Re: GPS assist and Heli
Post by: xfce on January 25, 2018, 01:58:24 am
Hi all,
does GPS assist flight mode have be supported by Heli now ?
Title: Re: GPS assist and Heli
Post by: karla on January 25, 2018, 03:29:05 am
Hi xfce, nothing has changed yet.
Still working to complete a successful position hold using Next.

The progress is
. verifying, setting and using Collective as Thrust and using Governor mode on heli ESC, this works as expected using AltitudeHold in Basic AttEstAlg.

The remaining issues for me are
. the RC control and telemetry is not stable, many unexpected failsafe's.
. vibrations must be sorted out before even attempting INS13 AttEstAlg and position hold.
. the compass had too much disturbances last time (have changed to a DJI unit now).

Please go ahead and try it yourself.
You need to change setting the FlightModeSettings > DisableSanityChecks to True.
Otherwise it will be a Red CONFIG.
Title: Re: GPS assist and Heli
Post by: karla on February 26, 2018, 09:55:46 am
Lots of work here, will not bore you with it all but seems
. I got the RC control and Telemetry okay now (touch wood).
. the vibrations under control (sooo much time to locate it and order new parts).
Done AttEstAlg Basic and next is to do INS13 and see how the new compass will behave.
/K
Title: Re: GPS assist and Heli
Post by: karla on March 02, 2018, 11:23:31 am
Oh, two steps forward and one step back today ...

Good news first

Very happy with the AltHold using AttEstAlgo basic, really!
This Heli is an align trex450L with the onboard ESC set to Governor mode, and the LibrePilot GCS set to
System - SystemsSettings, ThrustControl = Collective (not throttle)
This setting is not often around here ...

The video show that after the sudden drop of altitude its all controlled by the LP fc on AltHold with EstAttAlgo basic. Lovely, who could ask for more?
Maybe the initial drop is to adjust the setting in Settings, AltitudeHoldSettings, ThurstLimits - neutral?

https://www.youtube.com/watch?v=U87Xt3ug_0o

This could go one forever keeping the Altitude and felt very stable.
But then I had a disconnect of the radio control channel.
This have nothing do to with barometers, but a lot to do with OPLM.

https://www.youtube.com/watch?v=za0Q6OZb-7o

1. There is a disconnect and system goes to fail safe. Means Throttle zero and collective up 70% to let it land smooth.
2. Pilot understand the state and switch to Attitude mode (not AltHold).
3. System OPLM reconnects and resumes controls.
4. Pilot fighting to get control and land
5. Successfully land.

I am unable to locate the problem of the disconnect of the OPLM :(


I have attached the Config file as well as the log file from the whole flight below if anyone can spot something to change.

Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 02, 2018, 07:21:36 pm
If you are using "next" there is an issue with AltHold/AltVario; it drops and then holds:
https://forum.librepilot.org/index.php?topic=4155.msg28197#msg28197

If you have good antennas, you do not need much OpLink power to fly locally.

One of my OpLinks has an issue.  It seemed to work.  I finally tested it with next and the tuning is off by 46khz (too much to tune) and the RSSI signal level looks OK for a while, but will suddenly jump down about 30db and then will come back up to normal.  I am just suggesting that for a bench test you run everything at 1.25mw and just watch the RSSI and error/reset counts.

Also, your OpLink/Revo must have matching Data+Control on both sides.  You shouldn't have for instance Control Only on one and Data+Control on the other, or Data Only on one and Data+Control on the other.
Title: Re: GPS assist and Heli
Post by: karla on March 03, 2018, 03:32:27 am
Ah, I saw that post but was not sure it was about this issue. I can live with this, no problem at all.
Good to hear also others have 'mysterious' drop of signal. This is the 3rd OPLM I am testing.
I thought it was was a good one.

I tested having both OPLM units connected indoors at 1.25mw.
Heli is in another room with a concrete wall in between. It appeared stable to me, OPLinkStatus RSSI show mostly less than 10db fluctuation, like between 68-78db, mostly 3db fluctuation during any 1 min period of time. I don't know if normal or not but AFC correction usually at 45khz or more. Typical values in picture below.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7232;image)

However, if I move around in the room, (tx and rx are stationary, but i move) then there will be short disconnects, like in the picture, and similar to when I was flying. In the picture and in the attached short log file (some 30 seconds) there are 3 disconnects with immediate reconnects, just to show it.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7234;image)

Is this normal behavior? I think its surprising it goes from a pretty good signal to a total disconnect directly. I would expect the signal to drop much lower first then lose connection. Right?

If I was flying, this would have been a failsafe and most likely a crash.
In the flight video i was using 100mw at both OPLMs and was standing not more that 10m away.

I have tested the OPLM units and there are no short circuit in the antenna like some have.
Title: Re: GPS assist and Heli
Post by: f5soh on March 03, 2018, 11:06:30 am
Quote
I don't know if normal or not but AFC correction usually at 45khz or more.
You should not see big AFC value like this, this mean at least one side is untuned.
Check if the Xtal frequency value is set to 127 in both sides.
You should keep the side usually working with zero AFC value with others OPLink devices with a 127 value.
Some Oplink clones like the one provided with Revo mini will need tuning.

Before changing xtal value you may try increasing the air data rate to 256000 if the disconnect issue still.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 03, 2018, 11:21:51 am
I had problems where it was 46khz off and tuning would not bring it all the way back.  I don't use that OpLink any more.

1 - It is a style of OpLink that I liked because it has an SMA connector on it.  It also has the CPU/MCU mounted diagonally.  Does your "bad OpLink" have an SMA connector and have CPU mounted diagonally?

2 - I wonder if it is the clone RFM22B module that is the issue.  I have several other clones with no problems, but this OpLink even has the CPU/MCU mounted diagonally where the originals have it mounted square to the PC board.

It may be coincidence but I get the feeling that it is off by whole 40khz channel width which may mean that it is a problem with the frequency synthesizer, maybe something wrong (crystal, tuning cap, code, etc.) with the clone RFM22B.   I am actually hoping it is a bad RFM22B and that I can reuse the OpLinks by replacing the RFM22B (I have two of these OpLinks, I haven't tested the second one).  I already have the 1 watt modules.  :)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 03, 2018, 11:32:56 am
However, if I move around in the room, (tx and rx are stationary, but i move) then there will be short disconnects...

Is this normal behavior? I think its surprising it goes from a pretty good signal to a total disconnect directly. I would expect the signal to drop much lower first then lose connection. Right?

OpLink disconnects/reconnects are not normal, at least I never see disconnections at -70dBm with my good setups.

I loose link at maybe -85dBm.  You are playing around -70dBm.  I see a drop of about 30 dBm sometimes.  -70-30 is -100 which would be disconnected.  For a test, do you get disconnections at a distance where you have about -40dBm?  At that distance, -40-30 is -70 and maybe you will stay connected.  This may show that you have the same issue I do.  Well it is a thought anyway.  :)

Then again, I have two of these OpLinks and I should test them together to see if they then work correctly so we know they are all "bad" and the frequency is always wrong for some reason.
Title: Re: GPS assist and Heli
Post by: karla on March 03, 2018, 12:32:05 pm
Thanks guys, let me digest this and come back :)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 03, 2018, 07:54:00 pm
Questions:  :)

1 - It is a style of OpLink that I liked because it has an SMA connector on it.  It also has the CPU/MCU mounted diagonally.  Does your "bad OpLink" have an SMA connector and have CPU mounted diagonally?
Title: Re: GPS assist and Heli
Post by: f5soh on March 03, 2018, 09:17:33 pm
The tuning feature was added to support correctly those OPlink version with cpu diagonally mounted + SMA called "OPLink Ground" or "OPLink Air".
Since they are tuned, there is no issue. Sometimes, when frequency offset is too big a "untune" is needed into the other side.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 03, 2018, 11:29:42 pm
I wanted to know if his OpLink was the same as mine which might say that his can't be tuned (without untuning others).  And mine does this thing where it drops 30 dB and then comes back up to "normal" in 10s of seconds.  That could be his disconnects.  I had complete disconnect with this bad OpLink at 50-100mw and good antennas at only about 200-300m.

It might be good to have code that actually adds a constant number to the frequency divisor.  It should be simple to hard code for a test.  Doing that would require configuring to not use the top or bottom channel.  Could even offer this hard coded version for +40khz and another for -40hkz for a quick fix.  :)  Or does it only for certain channels if that is required.
Title: Re: GPS assist and Heli
Post by: f5soh on March 03, 2018, 11:57:04 pm
Quote
It might be good to have code that actually adds a constant number to the frequency divisor.  It should be simple to hard code for a test.
I wonder how you can play with divider in one side and get a matching set of channels with the other side.
Quick fix is use the tuning feature, as documented by the manufacturer.
From user point of view, moving the slider in the OPLink tab, saving and check the AFC value.
40Khz can be done easily and even if small AFC value still, there is no issue where a oplink cannot connect at lower rates while untuned.
Title: Re: GPS assist and Heli
Post by: karla on March 04, 2018, 01:53:02 am
Sorry for delay. Here are some answers.

. yes, both OPLMs are set for data and control
. yes, both have Xtal capacitor set to 127
. no, the bad OPLM has the standard MMCX antenna connector and CPU not mounted diagonally (see pic)
. yes, I will keep the OPLM that nomally work with little AFC corrections (-4Khz I noticed when connected to a Revo)
. When changing the air data rate to 256000 the AFC correction goes to a steady Zero!?
(but the RX Good drops to just around 15% and it disconnects and reconnects every 2-3 seconds)

Cliff, It seems I do not get disconnections at a distance where I have about -40dBm. I can first make it happen  at lower then -65dBm.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 04, 2018, 06:43:01 am
@karla it sounds like your 256khz test is so bad that it can't even calculate the deviation correctly.  That is my guess anyway. f5soh talked about it working better at lower data rates.

Quote
It might be good to have code that actually adds a constant number to the frequency divisor.  It should be simple to hard code for a test.
I wonder how you can play with divider in one side and get a matching set of channels with the other side.
Quick fix is use the tuning feature, as documented by the manufacturer.
From user point of view, moving the slider in the OPLink tab, saving and check the AFC value.
40Khz can be done easily and even if small AFC value still, there is no issue where a oplink cannot connect at lower rates while untuned.

I tried next and even with full tuning offset, it (my bad OpLink with 46khz offset) was not even close to 0khz.  I tried larger and larger tuning offset so it was not that I went too far.

I am assuming that all channels are off by 46khz, so shifting all channels by say 40khz (one standard 40khz channel width) in the correct direction would bring all channels to "just off by 6khz".  If it is "just some (not all) channels are off by 46khz" then it would need a list of which channels to perform offset on.

With his OpLink off by 45khz and mine off by 46khz it seems that there is a batch (of clone RFM22B) that have this same problem.  If a fixed offset works then it would be easy to hack a firmware that everyone with this problem could use.
Title: Re: GPS assist and Heli
Post by: f5soh on March 04, 2018, 10:22:29 am
Quote
That is my guess anyway. f5soh talked about it working better at lower data rates.

No, it's the contrary.
While using faster baudrates the Tx deviation is wider (150 khz@256Kbps) and also the Rx bandwidth is a bit wider than tx deviation so a 46Khz offset has less effect using faster baudrate.
This also mean a untuned OPLink will not connect at all using the "PPM only" (control) @9600bps.

If the disconnect issue still @256Kbps, you can assume the issue is not related to fine tuning.
Can you try changing the channel range (like min 80 - max 120) and look if you get similar disconnects ?

Quote
If it is "just some (not all) channels are off by 46khz" then it would need a list of which channels to perform offset on.
All the channels will have similar offset assuming they use the same reference clock.
Title: Re: GPS assist and Heli
Post by: karla on March 04, 2018, 12:06:17 pm
Tested 100kbps air data rate, 1.25mw power, Bands from 80 to 120.
That gives around -75 dBm, AFC correction at 64-65kHz and lots of connects and reconnects.
I did not provoke it by walking around, sitting still, location of tx and rx same as before.

Then tested with all else same but changed over the air data rate at 256kbps
Then its same dBm, AFC correction at 0kHz but more disconnected than connected. But if just improve the location ot the tx a little bit, then connected with disconnects like above.


Title: Re: GPS assist and Heli
Post by: f5soh on March 04, 2018, 12:57:46 pm
When using a Revo or a Sparky2 you can do a simple test allowing to monitor both sides at same time.
Oplink ground still connected using HID and give the local RSSI.
Remote radio stream is redirected to VCP and a second GCS window can show the remote RSSI from Sparky2/Revo.
This test can highlight one side not transmitting correctly or one side with noisy Rx.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7246)
Title: Re: GPS assist and Heli
Post by: karla on March 04, 2018, 01:36:15 pm
hm... yes I have been thinking, how this link looks from the Heli side, so far we only monitor from the OPLink ground perspective.

I have an OPLM unit on the Heli side, not a Revo/Sparky2. Can your set up be accomplished in such case?

I notice you use Link type Data and not Data and Control, as in my case. Will it make a difference for the radio link quality (Control being more important than Data) if I change to Data only?

Also, for the OPLink ground I use a bluetooth link to PC, will it make a difference to the radio link quality if I connect it via a USB cable?
Title: Re: GPS assist and Heli
Post by: f5soh on March 04, 2018, 02:41:35 pm
Dual monitoring can be done only using a revo/sparky2.
Data or Data+Control do not change anything about the disconnect/connect behaviour, just a little more data to send from ground to air.
Since your bluetooth link do not cause issues using others remote, it will work the same using the remote oplink in this particular setup.
Bluetooth module will not disturb the UHF link since the frequency is above.

You should change your remote Oplink and see if issue still, or fix the modem in your Revo.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 04, 2018, 09:09:35 pm
By the way, are there actually 251 (40kHz) channels (0 to and including 250)?  It seems to say that we put a 40kHz channel at 430.0 mhz which would actually splatter down to 429.980 and the same at 440.0 actually goes up to 440.020

It should be 40khz channels centered at 430.020 through 439.980 for a total of 250 channels?

===================================

Quote from: TheOtherCliff
That is my guess anyway. f5soh talked about it working better at lower data rates.

No, it's the contrary.
This is the piece that made me think you implied lower rates are easier to connect.  :)
40Khz can be done easily and even if small AFC value still, there is no issue where a oplink cannot connect at lower rates while untuned.
(can always connect at lower rates, so maybe there is an issue at higher rates)


Can you try changing the channel range (like min 80 - max 120) and look if you get similar disconnects ?
Assuming that KarlaDisconnects==Cliff-30dB I tried changing channel range from 0-31 32-64 16-47 1-32 I forget now.  Still had same 30dB drops.


Quote from: TheOtherCliff
If it is "just some (not all) channels are off by 46khz" then it would need a list of which channels to perform offset on.
All the channels will have similar offset assuming they use the same reference clock.
That is my assumption too, but I am at a loss to explain why there is a -30dB change in RSSI sometimes (while showing constant 46kHz deviation), so I wonder if these clone RFM22B have some problem such as only some channels are offset.
Title: Re: GPS assist and Heli
Post by: f5soh on March 04, 2018, 09:43:30 pm
Quote
It should be 40khz channels centered at 430.020 through 439.980 for a total of 250 channels?
What's the issue here ?
We simply talk about the nominal frequency, like every transmitter/receiver in the world and user need to define the min/max channel according to the local regulations.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 05, 2018, 12:44:05 am
Nominal frequency at 430.000mhz with 40khz width is actually a range from 429.980 to 430.020
Transmitting on 429.980 is illegal (but OK in USA).

Same at top end where if it truly is nominal frequency of 440.000mhz then it actually is a range from 439.980 to 440.020 ... and transmitting on 440.020 with this license is illegal everywhere in the world.

Splitting 10mhz of band (from 430.000mhz to 440.000mhz) into separate 40khz channels yields exactly 250 channels, not 251.

it is like saying the band is from 10.0 to 20.0 with bandwidth of 5.0
you should have just two channels, one from 10 to 15 and another from 15 to 20:
- a channel from 10.0 to 15.0 with center at 12.5
- and another at 15.0 to 20.0 with center at 17.5

but we have 3 channels, one centered on 10, another centered on 15 and third centered on 20:
- a channel at 10.0 which is really from 7.5 to 12.5
- a channel at 15.0 which is really from 12.5 to 17.5
- a channel at 20.0 which is really from 17.5 to 22.5

I raise this because the hardware may not even allow 251 channels and that may also cause an issue.  It could even be that the clone RFM22B is working correctly, but handles a presumed 251 channel setup differently than the authentic RFM22B does.  I don't think this is it because I have personally tested it with it configured to avoid channels 0, 124, 125, 126, and 250.

I just wonder if you already know what goes on in the code and have an answer to this.
Title: Re: GPS assist and Heli
Post by: karla on March 05, 2018, 01:39:23 am
Okay, thanks for all answers and advice both of you.
/Karl
Title: Re: GPS assist and Heli
Post by: karla on March 05, 2018, 05:46:26 am
@Cliff,

... For a test, do you get disconnections at a distance where you have about -40dBm?

It seems in one of my earlier posts here, using the first of three bad OPLMs, it did drop out at -40dBm even -35.
Thats when I was flying it.
Look again here https://forum.librepilot.org/index.php?topic=3999.msg27694#msg27694
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 05, 2018, 09:18:26 am
I will take that with just a grain of salt considering that (I recall) you have no dropouts when bench testing close, but do have dropouts when bench testing a bit farther or with moving around.

I imagine that antenna orientations etc when flying can make it vary a lot.  :)
Title: Re: GPS assist and Heli
Post by: f5soh on March 05, 2018, 10:04:20 am
Quote
Splitting 10mhz of band (from 430.000mhz to 440.000mhz) into separate 40khz channels yields exactly 250 channels, not 251.
First seems you do a mistake between channel spacing and "40khz channels" so related to the frequency bandwidth while transmitting or receiving.

Dividing a 10Mhz band by 40KHz (the channel spacing we use, see bellow why) give channels numbers from channel 0 to channel 250 (as displayed in GUI) and the total channel count is 251.
Those 251 channels are possible hopping channels available for link, and the spacing between this hopping channels is not related to tx/rx bandwidth.
Simply we have a 10Mhz band (430-440), hopping channel value from 0 to 255 and 10Khz step size: answer is divide by 40Khz and get the maximum of hopping channels.
Next a set of channels is generated, at this point the tx/rx bandwidth is taken in account assuming the bandwidth is bigger at higher baudrates. This means two channels effectively used cannot be #10 and #11 @100Kbps but more likely #10 and #13 @100Kbps.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 05, 2018, 05:22:39 pm
But you are not allowed to go outside the band and using 251 channels forces it outside the band

Imagine that the band is 10mhz wide and we use 1mhz channels.  You can fit 10 such channels "inside" the band, but we fit 11 channels (in this example it would be channels 0 through 10).  Both the bottom channel and top channel overflow outside of the band.  This is not legal band usage.

I have no idea whether or not this causes any RF problem other than band compliance.  I would guess not, but it's possible that these bad clone RFM22B would work correctly if this were changed.

https://forum.librepilot.org/index.php?topic=3999.msg28276;topicseen#msg28276
Title: Re: GPS assist and Heli
Post by: f5soh on March 05, 2018, 05:38:27 pm
Quote
But you are not allowed to go outside the band and using 251 channels forces it outside the band
This is not legal band usage.
Already answered:
Quote
We simply talk about the nominal frequency, like every transmitter/receiver in the world and user need to define the min/max channel according to the local regulations.
Last time you buy a legal FM Tx/Rx you may ask the seller to disable first and latest channel into the band used.
For reference, the UHF bandplan from ARRL:
(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7256)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 05, 2018, 05:48:35 pm
This is wrong.  Ask Brian.

Default should be what is right.  And if the GCS describes channel centers as it seems, then the channel centers are displaced by 20khz.  There is a very minor chance that is what causes the issue with these particular clone RFM22B.
Title: Re: GPS assist and Heli
Post by: f5soh on March 05, 2018, 06:29:33 pm
Quote
This is wrong.
What's wrong ? The fact the first channel (0) is 430Mhz ?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 06, 2018, 05:55:04 pm
Yes.  First (40hkz) channel should be centered at 430.020 so that the first channel extends from 430.000 to 430.040

In addition, there should be only 250 channels and the last channel should be centered at 439.980

Users (especially non-technical users) whose country allows 430.000 to 440.000 will think the 430.000 to 440.000 default is set up correctly for them when it is actually illegal in their country because GCS saying 430.000 to 440.000 actually means 429.980 to 440.020

Yes, you can say that people living in such countries should just override the default and skip channel 0 and channel 250 and change it to start at channel 1 and end at channel 249.
Title: Re: GPS assist and Heli
Post by: f5soh on March 06, 2018, 08:16:41 pm
40Khz spacing is not related to frequency deviation (frequency deviation can be 30KHz, up to 150Khz), read message above.
So your logic about the channel centered at 430.020 or 439.980 still not "legal" from your point of view.

Just a remark about the so precise 430-440Mhz band where you can't have any frequency deviation outside: Why the 430 or 440 limits are not even mentioned in ARRL bandplan ?
According to the bandplan, the 430 and 440Mhz frequencies are in ranges dedicated to ATV. Especially the upper limit should be avoided to transmit because the 439.250Mhz used for input in ATV repeaters.
Again, your 40Khz limitation at upper limit changes nothing here assuming the ATV uses more bandwidth and you are transmitting in frequency range where a repeater can receive your signal.

User should select carefully the channel range, not only thinking about a 40Khz (unrelated freq. deviation) but according to the bandplan and local regulations.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 07, 2018, 05:47:43 pm
No matter how you do channel width vs. separation, putting channel center on the exact edge of the band is wrong.

If someone were trying to get this certified, say in a country where the band was 430 to 440, the certification would fail because emissions extend outside the band.

It looks like UK allows exactly 430 to 440.  The average UK user would think the default is perfect for them.  But it isn't if it actually uses 430.000 as a channel center.  (at any baud rate)

The best way to handle this would be to input the min and max frequency and have the code determine min and max channel centers and channel separation based on air baud rate.

I do understand that the deviation goes up as air data rate goes up.
Title: Re: GPS assist and Heli
Post by: f5soh on March 07, 2018, 08:21:22 pm
Glad you finally understand your "40Khz rule" was unrelated.

Since you talk about the "average UK user", here is what (https://www.ofcom.org.uk/spectrum/radio-spectrum-and-the-law/licence-exempt-radio-use/licence-exempt-devices/Radio-controlled-models?SQ_VARIATION_73584=0) the Ofcom (the communications regulator in the UK) says:
Quote
Can I use an Amateur Radio licence for model control including airborne use?

No. Amateur Radio is a service intended to allow hobbyists and enthusiasts to experiment with radio. As licensed Radio Amateurs may operate transmitters at relatively high power levels in various frequency bands, the licence is available only to those who have demonstrated the necessary competence by studying for and passing a special examination.
We receive enquiries from those (principally non-amateurs) who wish to fly radio-controlled aircraft, such as quad-copters, fitted with video cameras (used to view the ground from the aircraft or to provide First Person View (FPV) to aid the control of the aircraft.).
There is a belief that the use of higher power equipment can be authorised by applying for an Amateur Radio licence. This is wrong. Amateur Radio licence expressly prohibits use in any aircraft or airborne vehicle. This restriction is not relaxed for radio-controlled models, airplanes and balloons.

This is not only UK, but most countries do not allow transmitting from a aircraft.
There is many others rules violated implying "the certification would fail", and anyway you transmit in ranges where the digital mode / hopping / bandwidth we use do not match the bandplan rules.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 07, 2018, 09:49:39 pm
The point I have been making all along is that using a center frequency that is actually at the exact edge of a band is illegal and that the way it is currently written it looks to the less technical user that he is set up according to his country's rules, but it is not.  I also would guess that no one else (other than OP derivatives) breaks up a 10mhz band into 251 channels.

In 16.09 where the user does not even know the air data rate (and thus can't determine the bandwidth), he can't set it up without knowing the baud rate relationship to the air data rate.  He would have to read the code or ask someone who knows what the air data rate is to cross reference the bandwidth in the RFM22B doc to be able to determine what channels to use.

In next where the user can see the air data rate, he guesses at air data rate that is necessary to make his baud rate work.
Title: Re: GPS assist and Heli
Post by: f5soh on March 07, 2018, 09:58:33 pm
Where you see the band is "430-440Mhz only" in the place you live ?
Assuming you are is ITU region 2 (https://en.wikipedia.org/wiki/ITU_Region), the UHF band limits are 420-450MHz (https://www.w5yi.org/page.php?id=181) as detailed in previous ARRL bandplan posted where a 430 or 440 number do not even appears.
Title: Re: GPS assist and Heli
Post by: f5soh on March 07, 2018, 10:40:25 pm
Quote
I also would guess that no one else (other than OP derivatives) breaks up a 10mhz band into 251 channels.
At least for OpenLRSng, used in common UHF rc modules, the min/max limits you can use are 413-463MHz...
(https://raw.githubusercontent.com/openLRSng/openLRSngWiki/master/images/TX_screen.jpg)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 08, 2018, 01:04:10 am
Where you see the band is "430-440Mhz only" in the place you live ?
Assuming you are is ITU region 2 (https://en.wikipedia.org/wiki/ITU_Region), the UHF band limits are 420-450MHz (https://www.w5yi.org/page.php?id=181) as detailed in previous ARRL bandplan posted where a 430 or 440 number do not even appears.

I never said this was the range where I live, but someone may live where there is either a 430 min or a 440 max.  And for those, refer to my previous statement about looking like it is configured for them but it is not.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 08, 2018, 01:12:49 am
Quote
I also would guess that no one else (other than OP derivatives) breaks up a 10mhz band into 251 channels.
At least for OpenLRSng, used in common UHF rc modules, the min/max limits you can use are 413-463MHz...

LP GCS shows a 4khz channel width for what it calls a channel.  When you divide 10mhz into 4khz channels, you get 250 of them, not 251 because you are breaking up the range from 430 to 440 mhz into 4khz chunks, and with that you get 250 chunks.

Speaking of OpenLRSng, it looks like they do it the way I suggested:
The best way to handle this would be to input the min and max frequency and have the code determine min and max channel centers and channel separation based on air baud rate.
Title: Re: GPS assist and Heli
Post by: karla on March 12, 2018, 02:38:47 pm
Some news here,
I got delivery of 4 new OPLM from source mentioned as okay over here ... Cliff

First I put the new OPLM in the heli and kept the other OPLM as before on the ground side.
Then not so impressive, having lower dBm and still disconnects like before.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7276)

Then decided to use them in pair, so swopped the tx side at ground to one of the new batch OPLMs. Then much better, no disconnects even operating at a lower dBm level.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7278)
This makes me think I should try the old 'bad' OPLMs in pairs, like tx and rx and see if they are good to go.

I dont understand the reasons of this, and i am really frustrated with the unpredictability of the OPLMs. They hold a big promise of ease of use if working, but seem very difficult to get to work.
The new pair is oprating with only 1 to - 1kHz correction.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 12, 2018, 08:35:29 pm
I bought two of the OpLink Ground / OpLink Air combination.  I can't use the Air since I don't have that kind of Revo, but I wanted the Ground because it has SMA.  Both sets show the -46khz deviation.  The RFM22B on these has the main IC chip identification ground/etched away in a square area.

My checkout procedure for anything with OP RF now includes testing (with next) with a known good OpLink for the -45/-46khz deviation issue.  I have some 1 watt RFM modules that I might get around to soldering on the bad OpLinks some day.

The best OpLinks seem to be from Kevin Finisterre : Sasquatch Labs.  All his stuff (Nanos too) seem to be OpenPilot "new old stock" from old OP store.
https://sasquatchlabs.org/product/openpilot-oplink-mini-modem-bundle/
Title: Re: GPS assist and Heli
Post by: karla on March 13, 2018, 03:08:07 am
Is he still in operation?
Did send an email just the other days since I wanted some backup Nano and working OPLMs but never got answer back.
He has limited list of countries he can ship to...

Found these OPLMs from your other thread about good/bad suppliers (can't find that threat at the moment though).
I would like to report back where I got the bad ones.

These good OPLMs (so far) got here:
https://www.ebay.com/itm/172353558651? They also have a real store in Hong Kong and their own site http://www.porcupinerc.com
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 13, 2018, 06:05:08 am
I buy OpLinks, Nanos, etc from Sasquatch Labs once or twice a year.  Probably 5 orders total with the one I made just now.

I have never had problems with orders but I am in USA.  ... While writing this I ordered some OpLinks from Sasquatch since the two I had in stock ( :) ) were the -46khz bad frequency offset kind (OpLink Ground/Air NOT from Sasquatch).

He has the previously mentioned bundle of 2 OpLinks with some goodies for $29, but shipping is $15.  Getting 2 bundles the shipping is $30 so no quantity discount for shipping.  So I bought some single unbundled ones for $13 each because shipping was only $5, and shipping for 4 was only $6 so $14.50 each, shipped.  This shipping is to USA though.
https://sasquatchlabs.org/product/genuine-oplink-mini-modem/  (sasquatchlabs.org web store has closed)

If you want real OP Nanos, Sasquatch is the only game in town.  $25 + $4 shipping.
Title: Re: GPS assist and Heli
Post by: karla on March 13, 2018, 07:04:17 am
Very glad to hear he is still out there :)
I will ask a friend in CA if he can receive delivery and resend to me.
Thanks
Title: Re: GPS assist and Heli
Post by: karla on March 13, 2018, 07:10:19 am
Ill be darned,

This makes me think I should try the old 'bad' OPLMs in pairs, like tx and rx and see if they are good to go.

Did try the 'bad' OPLMs, one as tx and other one as rx, worked as good as the new 'good' ones.
Corrections at 0, 1 or -1 kHz and link quality similar and not disconnects.

Not sure what to make of this, but I will move on with the GPS assist :)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 13, 2018, 07:50:04 am
So it seems that they just use the wrong frequency, and it is consistent.  It would be nice if we had an LP option to shift by +45khz so these could be used with normal OpLinks.  Even just a compile option to have two different OpLink firmwares.  I will look into doing this in the next few days if someone doesn't beat me to it.  :)

It worries me that when testing with a good OpLink, it runs along with -46khz offset, at say -40dBm and once in a while jumps to -70dBm.  It makes me worry that it could possibly be offset by a changing amount when compared to a good OpLink.
Title: Re: GPS assist and Heli (-45khz OpLink freq offset patch)
Post by: TheOtherCliff on March 13, 2018, 09:25:43 am
Well that was pretty easy.  -45khz frequency offset fixed, but bad news.  The occasional 23dBm drop is still there, so it may be that individual channels need to be shifted differently, or that I have a doubly strange OpLink.  I originally called this about a 30dBm drop, but with this fix and on a different bad OpLink, I now see a 23dBm drop?

Here is the change if you want to play with it or check to see if your disconnects still happen.  I assume that your disconnects are the same as my 23dBm drop.

About line 75 in file:
flight/pios/common/pios_rfm22b.c
you will find this:
Code: [Select]
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_433 430000000
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_868 860000000
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_915 900000000

Change it to this to fix the -45khz issue.  Build ONLY the oplinkmini because everything you build will have the frequency offset in it (see below how to easily disable that):
Code: [Select]
// enter whatever your delta frequency shows when that device is connected to the GCS
// my oplink shows -46khz when connected to the GCS
// if it were my Revo had this problem and the oplink was good
// then the good oplink would probably show +46khz
// which means that if the Revo were connected it would show -46khz
#define DELTA_FREQUENCY                      (-45000)
#if !defined(DELTA_FREQUENCY)
#define DELTA_FREQUENCY                      (0)
#endif
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_433 (430000000 + DELTA_FREQUENCY)
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_868 (860000000 + DELTA_FREQUENCY)
#define RFM22B_NOMINAL_CARRIER_FREQUENCY_915 (900000000 + DELTA_FREQUENCY)

After you build oplinkmini and save off the fw_oplinkmini.opfw file to something appropriately renamed, disable this built in frequency offset by commenting out one line.  Change it from:
Code: [Select]
#define DELTA_FREQUENCY                      (-45000)to:
Code: [Select]
//#define DELTA_FREQUENCY                      (-45000)
Recall that maxing out the Xtal Capacitor tuning it would only bring it back to -17khz from -46khz, so this helps you to run bad OpLinks with other good stuff without detuning the good stuff.
Title: Re: GPS assist and Heli
Post by: karla on March 13, 2018, 09:31:55 am
Holy macaroni Cliff
This is way beyond my level of comprehension

Maybe you are right, I do not know.
I can just add to my findings, that the bad OPLMs do not connect at all to my other Revo boards when i use them as transmitters :(
They are off ~ 40kHz and do not work as TXs from the ground to the flight side based Revolution modems.
However, the new ones connects just beautifully.
I will scrap these bad OPLMS...
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 13, 2018, 09:56:43 am
If you are interested in tinkering with it you could try the code change.  You will probably see the -45khz deviation go away.  I expect that your Revos will connect with it then, but you would need to test to see if you still get disconnects.  I bet you do.

I get random decreases of 23dBm several times a minute.  You have to watch it for 10 seconds to see it happen sometimes.

Oh yea, I guess it's possible that it is made worse by the fact that I run my channel set from 0 to 31, not 0 to 250.  That shouldn't matter, but there is an issue somewhere so it might matter.
Title: Re: GPS assist and Heli
Post by: karla on April 20, 2018, 06:17:36 am
Last weekend I had rebuilt the crashed heli and calibrated everything and had some test rounds in the field.
.OPLM issue solved
.Vibration issue solved
.Seems the new position of the mag/gps unit is good and I swopped to a DJI one.

Before I crashed it again (basically just clumsy)  ::) I got some experience trying Positionhold.

www.youtube.com/watch?v=cjoWqkQTN5M

This initial drop issues has been discusses here https://forum.librepilot.org/index.php?topic=4155.0 (https://forum.librepilot.org/index.php?topic=4155.0)
If I use that next version, could I also expect this big drop in switching from manual to PositionHold to disappear?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on April 20, 2018, 06:40:38 am
It is not merged into next yet.

If you follow instructions here to edit pid.c then you can just use the version you are already using.  It works without any changes to settings, so just change file, build firmware, flash firmware, fly.  :)
https://forum.librepilot.org/index.php?topic=4155.msg28197#msg28197

By the way, I find that VelocityRoam is better than PositionHold since you can move around with VR but not PH and VR is the same as PH if the sticks are in the center.
Title: Re: GPS assist and Heli
Post by: karla on April 20, 2018, 06:51:25 am
Thanks Cliff.
If I venture to try edit pid.c, will that also effect PositionHold? Not just AltitudeHold/AltitudeVario.

My final goal is GPS assist, but Velocityroam could maybe work as well, just have not tried it much yet. Thanks.
PositionHold is a useful mode for me in any case, to park the heli firmly if someone (construction workers) grabbing my arm or worse  :)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on April 20, 2018, 07:41:29 am
Yes, PositionHold.  I think it is anywhere the GPS / baro are used to (help) control altitude.  So even AltitudeVario and AltitudeHold thrust modes.
Title: Re: GPS assist and Heli
Post by: karla on April 20, 2018, 11:07:49 am
Got it. Thanks. Will for sure try this.
Title: Re: GPS assist and Heli
Post by: karla on April 29, 2018, 01:26:36 pm
Now ready to try the new fix code but need some help on the procedure please.
I think I need first to get the Revo firmware source code from Next 589.

I am using my MS pc machine for this using wiki: https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/14876735/Windows+Building+and+Packaging
this is the command to check out the "next" source code branch
Code: [Select]
cd librepilot
git checkout next

But what command to get the next 589?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on April 30, 2018, 03:54:10 am
Been a while since I did it, but I'm pretty sure you just change 'next' to the git hash number of the version (r589?) you want.  Find the hash number like this:

GCS "Help About" or the popup from mismatch firmware/GCS will tell you the git hash.

If git hash is 123456789876.....

then just "git checkout 12345678"

if the first 8 digits uniquely identify the exact version then that is all you need.

If you are already running r589 then there is no need to do anything but build the Revo firmware and flash it.

Then "make revolution_clean" and something like "make -j4 revolution" will clean and build just the part you need.

For Windows, use the backward slash \ everywhere instead of the forward slash / I have typed.

Are you running r589 from an installation of a build that someone else did?  You can just flash the firmware from there.  You will find the new firmware at: /your_r589_build_dir/build/firmware/fw_revolution/fw_revolution.opfw after you do the build.

Or you can build GCS with something like "make gcs_clean" and something like "make -j4 gcs"
and the new GCS exe is found somewhere like:
./build/librepilot-gcs_release/bin/librepilot-gcs
Title: Re: GPS assist and Heli
Post by: karla on April 30, 2018, 10:21:09 am
Thanks Cliff,

This is the screen when hitting about in the GCS,
not sure what number to use in the Git command.
Can you please advise?

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7471;image)

I am running a Windows version of LP next that was an executable, i did not make it locally. Any chance someone else did make the excutable with this fix? That would be a shortcut :)


Title: Re: GPS assist and Heli
Post by: f5soh on April 30, 2018, 02:54:15 pm
You can simply download the Librepilot GCS r711 (https://forum.librepilot.org/index.php?topic=4263.0)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on April 30, 2018, 03:36:27 pm
looks like its: 4c9c3c20
I should have described the exact wording.

Its a good thing to know that you can build it yourself, but as @f5soh says, there is a more recent 'next' version.  It looks like this fix was recently merged into latest next.
Title: Re: GPS assist and Heli
Post by: karla on April 30, 2018, 07:28:24 pm
Fantastic!  ;D
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on April 30, 2018, 09:06:38 pm
Of course be aware that you will be basically starting over with configuration if you go with the latest next, and probably again with later nexts and future releases.

Make sure to export uav settings, and it is helpful to make screen captures of all important GCS settings pages ... from r589 before updating anything.
Title: Re: GPS assist and Heli
Post by: f5soh on April 30, 2018, 09:33:13 pm
A config file from r589 can be imported to a running r711 board without any issues.
No UAVO changes except a new UAVO into r711, but not used by normal user.
Title: Re: GPS assist and Heli
Post by: karla on May 01, 2018, 02:56:54 am
f5soh, can you confirm I do not need to redo the thermo calibration and the gyro/accel calibration, if I import my old uav-setting file to the new version?
Title: Re: GPS assist and Heli
Post by: f5soh on May 01, 2018, 11:41:52 am
If worked before with previous r589 the r711 will work the same.
If you redo gyro/acc calibration, they will be a little better.
Title: Re: GPS assist and Heli
Post by: karla on May 01, 2018, 11:55:00 am
Okay, that's an incentive to re do it  :)
Thanks
Title: Re: GPS assist and Heli
Post by: karla on May 16, 2018, 07:40:22 am
Hello again and Thanks

Implemented LP r711 and re-did all calibrations except thermo.
Did fly it last weekend.
(+) The shift to AltitudeHold from Attitude is now smooth and as before the Altitude is held very good.
(+) Shift to PosHold from Attitude also smooth.
(- ) In Pos Hold, the Toilet-bowl effect is less but still there (AttEstAlgo=INS13+CF).
(- ) Mag have some +- 10 degrees difference from my iphone, intermittently.

Just today, i discovered that the settings in GCS, Configuration, Mag, Mag type = has always been 'GPSV9'
However, it should be 'DJI' since thats the HW on the heli.

My question: Does this really matter? Can I expect other readings/performance after correcting it to DJI?

It will take some time before I can test in the field...
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on May 16, 2018, 05:45:09 pm
I imagine your GPS health is not green if you have the wrong GPS type configured.  Select correct GPS type, recalibrate mags, and see if toilet bowl goes away.

If it were me, I would then disconnect the GPS/mag and fly again.  If toilet bowl comes back it sounds like an issue in INS13+CF in that it does not work correctly if GPS fails.
Title: Re: GPS assist and Heli
Post by: karla on May 17, 2018, 02:23:25 am
The GPS type is correctly set.
Its the Mag type that is wrongly set.
I was not aware that the mag also has to be set, when changing to a dji/naza gps/mag unit.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7516;image)

I realize it should be some difference, my question is if I can expect a significantly better result or not.
Not so important, I think I have an opportunity this weekend to test it in the field, then I will know :)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on May 17, 2018, 07:08:35 am
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
Title: Re: GPS assist and Heli
Post by: karla on May 17, 2018, 08:09:15 am
Okay will look out for it and if have that issue, will test the dji.c fix
Thanks
K
Title: Re: GPS assist and Heli
Post by: karla on May 20, 2018, 03:07:37 pm
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 :)

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=7518;image)

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

https://www.youtube.com/watch?v=6NyrfNwyu6k&feature

B t w Altitudehold is rock steady and just a delight. Always something :)
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on May 20, 2018, 06:08:07 pm
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.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on May 21, 2018, 08:48:38 am
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.
Title: Re: GPS assist and Heli
Post by: karla on May 21, 2018, 01:54:33 pm
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?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on May 21, 2018, 07:58:39 pm
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.
Title: Re: GPS assist and Heli
Post by: karla on May 22, 2018, 07:01:37 am
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?

https://www.youtube.com/watch?v=aVJBr1074v0
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on May 22, 2018, 10:59:45 am
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.   :P )  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).
Title: Re: GPS assist and Heli
Post by: karla on May 24, 2018, 02:24:48 am
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.
Title: Re: GPS assist and Heli
Post by: karla on January 08, 2019, 06:07:13 am
Long pause in this project due to lack of suitable flying sites,
but now still have some time fly to okay here :P

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:

https://www.youtube.com/watch?v=bWaQzlkytaM

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:

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=8016;image)

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?

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=8018;image)

Thanks a lot
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 08, 2019, 06:38:21 am
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.
Title: Re: GPS assist and Heli
Post by: karla on January 09, 2019, 09:21:11 am
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.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 11, 2019, 04:47:02 pm
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.
Title: Re: GPS assist and Heli
Post by: karla on January 12, 2019, 07:02:30 am
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?
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 12, 2019, 09:19:15 am
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...  :)
Title: Re: GPS assist and Heli
Post by: karla on January 14, 2019, 08:32:38 am
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  :'(
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on January 14, 2019, 10:54:37 am
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.
Title: Re: GPS assist and Heli
Post by: karla on February 25, 2020, 03:27:41 am
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.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=8475)

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.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on February 25, 2020, 03:56:40 am
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!!
Title: Re: GPS assist and Heli
Post by: karla on February 26, 2020, 06:26:35 am
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  ;D

Quote
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.
 
Quote
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.


Title: Re: GPS assist and Heli
Post by: TheOtherCliff on February 26, 2020, 07:32:07 pm
Quote
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
Title: Re: GPS assist and Heli
Post by: karla on February 29, 2020, 04:50:38 am
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.
Quote
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...
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on February 29, 2020, 05:45:09 am
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.
Title: Re: GPS assist and Heli
Post by: karla on March 07, 2020, 08:01:20 am
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).

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=8484)

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.

(https://forum.librepilot.org/index.php?action=dlattach;topic=3999.0;attach=8482)

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  :o

p.s.
I just uploaded the logfile from the flight here.
d.s.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 07, 2020, 08:07:20 pm
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.
Title: Re: GPS assist and Heli
Post by: karla on March 17, 2020, 08:34:51 am
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.
Title: Re: GPS assist and Heli
Post by: TheOtherCliff on March 17, 2020, 07:39:41 pm
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?

Quote
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
Title: Re: GPS assist and Heli
Post by: karla on March 23, 2020, 07:30:09 am
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.

Quote
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.