karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #75 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 ...
 :-\
« Last Edit: January 02, 2018, 12:52:07 pm by karla »

Re: GPS assist and Heli
« Reply #76 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.  :)

karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #77 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?



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?

« Last Edit: January 05, 2018, 10:48:35 am by karla »

Re: GPS assist and Heli
« Reply #78 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.
« Last Edit: January 06, 2018, 09:12:02 am by TheOtherCliff »

karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #79 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...


Re: GPS assist and Heli
« Reply #80 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.

karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #81 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?



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.



. Trims - I never use the trims on the transmitter, they are always centered (easily checked on the display of TX).
. ZeroTheIntegral - enabled
. EnablePirouetteCompensation - disabled
« Last Edit: January 08, 2018, 06:30:29 am by karla »

Re: GPS assist and Heli
« Reply #82 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?

karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #83 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


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
« Last Edit: January 08, 2018, 08:09:03 am by karla »

Re: GPS assist and Heli
« Reply #84 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.
« Last Edit: January 08, 2018, 05:29:01 pm by TheOtherCliff »

karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #85 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?

Re: GPS assist and Heli
« Reply #86 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.

karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #87 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?

Re: GPS assist and Heli
« Reply #88 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.

karla

  • ****
  • 294
Re: GPS assist and Heli
« Reply #89 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?