Rapid altitude change on PH/CRUISE

[DzikuVx]

I'm not sure if it's connected with recent GPS glitches from #431 or #346 or windy day, or new baro or whatever since SD card was loose in logger and I do not have a log from that mission.

Build based on 27822a5 , flying PH / CRUISE mission when suddenly FC decided that it is at least 15 meters lower than expected and started rapid climb. Climb was aborted after throttle movement. When landed, altitude drift was about 11m up.

Also, I've noticed, that enabling ALT_HOLD causes constant descend for few second before it settles down and works like expected again

[bk79]

I've experienced the same issue and increasing I gain doesn't help on the opposite it worsen things

Il 14/ago/2016 10:10, "Paweł Spychalski" notifications@github.com ha scritto:

I'm not sure if it's connected with recent GPS glitches from #431 https://github.com/iNavFlight/inav/issues/431 or #346 https://github.com/iNavFlight/inav/pull/346 or windy day, or new baro or whatever since SD card was loose in logger and I do not have a log from that mission.

Build based on 27822a5 https://github.com/iNavFlight/inav/commit/27822a59cb849266427084508146fab425d6a037 , flying PH / CRUISE mission when suddenly FC decided that it is at least 15 meters lower than expected and started rapid climb. Climb was aborted after throttle movement. When landed, altitude drift was about 11m up.

Also, I've noticed, that enabling ALT_HOLD causes constant descend for few second before it settles down and works like expected again

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWikwoKJMdNzmUfKa8V4sOaKQN5yD-ks5qfs18gaJpZM4Jj2Su .

[DzikuVx]

I suspect it is because #346 and will try to determine that today

[digitalentity]

It's possible. You can try to zero out w_z_gps_v and see if it makes the difference.

On Sun, Aug 14, 2016 at 8:23 PM, Paweł Spychalski notifications@github.com wrote:

I suspect it is because #346 https://github.com/iNavFlight/inav/pull/346 and will try to determine that today

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239666274, or mute the thread https://github.com/notifications/unsubscribe-auth/AKi_m7ltPCma4mdycGnOde8lcIwV5W1aks5qfuySgaJpZM4Jj2Su .

[DzikuVx]

I was thinking about reverting whole commit, but your idea is simpler 😉

[bk79]

I don't think so i have the same issue even indoor with no gps

Il 14/ago/2016 12:24, "Konstantin Sharlaimov" notifications@github.com ha scritto:

It's possible. You can try to zero out w_z_gps_v and see if it makes the difference.

On Sun, Aug 14, 2016 at 8:23 PM, Paweł Spychalski < notifications@github.com> wrote:

I suspect it is because #346 https://github.com/ iNavFlight/inav/pull/346 and will try to determine that today

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239666274, or mute the thread https://github.com/notifications/unsubscribe-auth/AKi_ m7ltPCma4mdycGnOde8lcIwV5W1aks5qfuySgaJpZM4Jj2Su .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239666332, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWivNrQzWMq1Ky8_jyhfb1_o_tbsLfks5qfuz1gaJpZM4Jj2Su .

[digitalentity]

@bk79 uncalibrated accelerometer may cause the issue

[DzikuVx]

Hmm... I just realized that this is new board and I restored calibration from old board.... hmmm.... let's try that too

[bk79]

Sorry wrong topic i was writing on the altitude hold issue looks like i opened by mistake this

Il 14/ago/2016 13:18, "Konstantin Sharlaimov" notifications@github.com ha scritto:

@bk79 https://github.com/bk79 uncalibrated accelerometer may cause the issue

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239668315, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWiiRgXd6aDYUgo4oglpvhaklw8vJ6ks5qfvlygaJpZM4Jj2Su .

[bk79]

Looks like the correct one accelerometer was calibrated properly following the wiki procedure and values were different from 4096, it just need to precharge the integrator to keep height, but increasing the gain does not solve it

Il 14/ago/2016 13:48, "luciano palermo" luciano.luca.palermo@gmail.com ha scritto:

Sorry wrong topic i was writing on the altitude hold issue looks like i opened by mistake this

Il 14/ago/2016 13:18, "Konstantin Sharlaimov" notifications@github.com ha scritto:

@bk79 https://github.com/bk79 uncalibrated accelerometer may cause the issue

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239668315, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWiiRgXd6aDYUgo4oglpvhaklw8vJ6ks5qfvlygaJpZM4Jj2Su .

[digitalentity]

Than it's easy - nav_mc_hover_throttle is incorrectly set.

On Sun, Aug 14, 2016 at 9:51 PM, bk79 notifications@github.com wrote:

Looks like the correct one accelerometer was calibrated properly following the wiki procedure and values were different from 4096, it just need to precharge the integrator to keep height, but increasing the gain does not solve it

Il 14/ago/2016 13:48, "luciano palermo" luciano.luca.palermo@gmail.com ha scritto:

Sorry wrong topic i was writing on the altitude hold issue looks like i opened by mistake this

Il 14/ago/2016 13:18, "Konstantin Sharlaimov" notifications@github.com ha scritto:

@bk79 https://github.com/bk79 uncalibrated accelerometer may cause the issue

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239668315, or mute the thread https://github.com/notifications/unsubscribe-auth/ ALSWiiRgXd6aDYUgo4oglpvhaklw8vJ6ks5qfvlygaJpZM4Jj2Su .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239669598, or mute the thread https://github.com/notifications/unsubscribe-auth/AKi_m4yS96Urf4IWf5z2y1160A2U9Silks5qfwFcgaJpZM4Jj2Su .

[bk79]

I thought that setting it to off makes that parameter not used and in any case i hover with less than 1500us

Il 14/ago/2016 13:53, "Konstantin Sharlaimov" notifications@github.com ha scritto:

Than it's easy - nav_mc_hover_throttle is incorrectly set.

On Sun, Aug 14, 2016 at 9:51 PM, bk79 notifications@github.com wrote:

Looks like the correct one accelerometer was calibrated properly following the wiki procedure and values were different from 4096, it just need to precharge the integrator to keep height, but increasing the gain does not solve it

Il 14/ago/2016 13:48, "luciano palermo" luciano.luca.palermo@gmail.com ha scritto:

Sorry wrong topic i was writing on the altitude hold issue looks like i opened by mistake this

Il 14/ago/2016 13:18, "Konstantin Sharlaimov" < notifications@github.com> ha scritto:

@bk79 https://github.com/bk79 uncalibrated accelerometer may cause the issue

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/iNavFlight/inav/issues/461#issuecomment-239668315 , or mute the thread https://github.com/notifications/unsubscribe-auth/ ALSWiiRgXd6aDYUgo4oglpvhaklw8vJ6ks5qfvlygaJpZM4Jj2Su .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239669598, or mute the thread https://github.com/notifications/unsubscribe-auth/AKi_ m4yS96Urf4IWf5z2y1160A2U9Silks5qfwFcgaJpZM4Jj2Su .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239669687, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWinxhlLrI_OPpIJkvkzaeyM8EnQf1ks5qfwHUgaJpZM4Jj2Su .

[digitalentity]

Do you have a log of your althold and a dump of your settings? Easier to debug that way.

[bk79]

I have several on spf3 deluxe but right now don't have to make a preliminary analysis so to give you exactly what you need if it ok for you to look inside the logs i'll send them in the afternoon

Il 14/ago/2016 14:01, "Konstantin Sharlaimov" notifications@github.com ha scritto:

Do you have a log of your althold and a dump of your settings? Easier to debug that way.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239669991, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWiuLuL3wZ-kOZE5IAuQqArd89NBBQks5qfwOKgaJpZM4Jj2Su .

[wilco1967]

Same problems here. nav_mc_hover_throttle set at 1375, where it hovers. GPS deactivated and disconnected. Still the same problem.

[digitalentity]

@wilco1967, logs please!

[bk79]

@digitalentity various logs consider that i arm always with althold enabled blackbox_log_2016-07-30_183430.TXT blackbox_log_2016-07-30_192042.TXT blackbox_log_2016-07-31_184620.TXT blackbox_log_2016-08-07_093933.TXT

[wilco1967]

Here you go.... just a very short flight RCExplorer F3FC board on a Tricopter V3.

For this flight, GPS disabled and disconnected. Mag still connected

iNav 1.2.0 CLI dump 2016.08.14.txt

LOG00199.TXT

[digitalentity]

@bk79 that's current espected behavior when taking off in BARO mode. Integrator goes very low while you are on the ground and it takes time to correct after you release the stick. A different issue.

[digitalentity]

@wilco1967

set acczero_x = -332
set acczero_y = -205
set acczero_z = 789
set accgain_x = 4103
set accgain_y = 4089
set accgain_z = 4243

This doesn't look like a good thing to me. This accelerometer graph doesn't look normal either:

Seems like serious vibration issues to me.

[bk79]

But i have sonar as well

Il 14/ago/2016 16:37, "Konstantin Sharlaimov" notifications@github.com ha scritto:

@wilco1967 https://github.com/wilco1967

set acczero_x = -332 set acczero_y = -205 set acczero_z = 789 set accgain_x = 4103 set accgain_y = 4089 set accgain_z = 4243

This doesn't look like a good thing to me. This accelerometer graph doesn't look normal either: [image: image] https://cloud.githubusercontent.com/assets/11059099/17649794/4c6ebd76-6280-11e6-9e29-4b6a96bbf44d.png

Seems like serious vibration issues to me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239676929, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWivR6FWBfWkAsDg7NBeUwRaNkBjY_ks5qfyglgaJpZM4Jj2Su .

[wilco1967]

Yes, there are vibrations, but there have always been. It's the same motors, props, frame I've always used without problem. Perhaps because the new frame has the ACC on the frame itself rather than on a separate board makes it more critical.... I'll see if I can dampen it somehow and try again. Props are balanced, but those prop adapters create some vibrations.

Just repeated the ACC calibration. Almost the same values.... They are not 4096, so it seems correct to me. What should I expect ?

EDIT: another try.... killed the vibrations completely (in software at least) using set acc_soft_lpf_hz = 1 set dterm_lpf_hz = 10 (Already had set gyro_lpf = 20HZ yesterday... just to try, suspecting vibrations might have an effect).

See attached log.

Not sure if this is the correct way, just tried something with extreme values (if a small change doesn't give the desired effect, a large change might).
I gave up on trying to balance motors long time ago, because you never get it perfect, and it always flew just fine.
With those settings, the ACC vibrations don't show up anymore on the blacklog.... But still, it cannot hold altitude... it still has this strange cycle of wanting to shoot up. it's clearly visible in the log.... you see the motors spin up, and ACC_Z responds to the motors spooling up / the copter accelerating upwards (not the other way around). It does feel different though. don't know how to explain. Other than alt holt, it still flies perfect with those LPF damping values...

LOG00201.TXT

[digitalentity]

@wilco1967, what's connected to i2c bus? do you have anything external connected to it? we might be seing the effect of https://github.com/iNavFlight/inav/issues/431#issuecomment-239733081 - corruption of data from accelerometer due to i2c bus problems.

[digitalentity]

@bk79 sonar support is rudimentary at the moment, I strongly advise against using it with current code.

[bk79]

It works better with than without...at least for what i've tested maybe it's just my impression

Il 15/ago/2016 11:42, "Konstantin Sharlaimov" notifications@github.com ha scritto:

@bk79 https://github.com/bk79 sonar support is rudimentary at the moment, I strongly advise against using it with current code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-239765273, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWiqo8zk7TZjzOk24-_IJ6hWcylsPYks5qgDSGgaJpZM4Jj2Su .

[wilco1967]

I got a external 5883 compass on the I2C bus. I get 1 or 2 I2C errors on start, and no more. It's an RCExplorer F3FC board, with the new drivers from Ikaino. See issue 438/439

The ACC is not on the I2C bus., but on SPI. The built in baro 5611 is on I2C

[DzikuVx]

For further reference: lowering inav_w_z_gps_v to 0.05 improved entering ALTHOLD mode greatly and there were not further problems

[digitalentity]

@DzikuVx this can be made new default.

[DzikuVx]

I would prefer to test it slightly more since I used that setting for like 5 take offs. Now I do not have a machine to continue tests here.

czw., 18.08.2016 o 12:10 użytkownik Konstantin Sharlaimov < notifications@github.com> napisał:

@DzikuVx https://github.com/DzikuVx this can be made new default.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-240681500, or mute the thread https://github.com/notifications/unsubscribe-auth/AA7Am-HeqjDnVYwnJ7invY5v76TV3IvEks5qhC-agaJpZM4Jj2Su .

Pozdrawiam, Paweł Spychalski

[wilco1967]

Tried that setting, inav_w_z_gps_v to 0.05, and even to 0.00.... still rocketing up....

if I hold the copter in my hand, set alt-hold on, and hold it really steady, it only slowly increases throttle.... If I shake it up/down, it increases power with every down-'shake', but doesn't reduce equally on up-shake.... I pretty soon end up with full throttle....

It seems to come purely from the vel controller.... the short burst still happen with Alt PID at 0,0,0 (=dead) Vel P at 0,1, and it seems gone, but at that setting there is no althold whatsoever.

my best settings I can find, are close to my erlier settings on the Flip32 board (naze target). Alt PID 10, 0, 0 Vel PID 10, 0,05, 20 sometimes, just sometimes, it seems to hold steady for a few seconds, but than these throttle bursts start again.... It will come down again after climbing say 10..20 meters, in this very slow up.down motion. That looks like a slow I-oscillation, but isn't (it's still there if I zero out all I,. it's these rapids bursts (which look like D action), that cause it to rise, but it isn't D as well, as I also zeroed that out, and it stays....

I do notice the baro going up/down a meter or so, but that always happened, also on the old flip32 board which flew just fine. the baro is inside this front spacer, and covered by some cotton. The throttle bursts don't match the baro 'noise'...

Looking at the blacklog files, there are some fluctuations on ACC-Z, which @digitalentity called 'vibrations'. But these are in fact the response to the throttle fluctuations.... They only show up when Alt-hold is activated (and even then not continuously). those fluctuations have about a 3 Hz cycle, which corresponds with throttle fluctuations....

If they were indeed vibration issues (from unbalanced props), the frequency would be a lot higher, and would also be there when not in Alt holt....

These are 9x5 props on a 900 kV T-motors, 4S battery.

Everything else works perfect.... just this alt-hold problem.... I've spent hours trying all kinds of (extreme) settings, and nothing works....

The I2C issues that I had before after the last change,, didn't change a thing on flying behaviour.

I'm about to put the old Flip32/Naze board back on again....

[digitalentity]

@wilco1967 interesting. I'll have another look at the logs.

[wilco1967]

Tried something else today.

Tried minimizing the effects of the GPS alt on alt hold controller. set inav_w_z_gps_p = 0.010 (default 0.2) set inav_w_z_gps_v = 0.010

Now the pulsations are a lot less, but there hardly is any alt hold effect anymore.... It either starts climbing, and only stops after climbing 30..40 meters, or it starts dropping, and it doesn't want to throttle up and I have to take over or it will slam into the ground ;-)... There is 'some' effect, but hardly anything.

Just a wild idea.... This looks like the same effect as if the alt controller doesn't 'see' the baro alt at all, but only very weak GPS alt... (and after almost zeroing the GPS part of it, almost nothing is left). Most likely I'm talking rubbish, but that sure is what it looks like....

ALT (and also GAlt) is however moving on telemetry and they seem to match pretty good (with some offset)....

Just guessing here, but could it be it was doing alt hold on just the GPS only, without the baro ?.

Is it possible that, although the baro sensor shows up correctly on telemetry / iNav config, the baro value doesn't actually make it to the alt control PID ?

Tomorrow I will try with completely zeroing out the GPS (inav_w_z_gps_p & v to 0.000. Today, I had just a little gain left).... if my theory is right, it should hold anything anymore....

This is the new RCExplorerF3 software I'm using (downloaded yesterday). Has anyone confirmed they have a good alt-hold on this ?

I have a 5 Hz GPS update cycle (old Ublox 6 GPS, new M8N one on the slow boat from China). but that flew just fine before..

Another observation: ACC-Z shows always as 0.92..0.94 when resting perfectly level at the telemetry screen (Taranis SmartPort). It shows 1.00 exactly on iNav configurator.

When I run the motors while holding it in my hand, the ACC-Z values stays perfectly at 1.00 (iNav sensors tab) from idle to full trottle. ACC-Z is not affected by motor vibrations. Neither are the other sensors (gyro/mag/ACC/baro).

I assume telemetry shows the raw, uncorrected value, and iNav the corrected (calibrated) value ? Which one is the ALT code using ? Should be corrected, but is it really ?

Any reason why telemetry and iNav configurator ACC-Z value are not the same ?

I noticed from the Taranis telemetry, that while it was climbing quite rapidly in 'Alt-hold', the Vspd was still showing zero most of the time.... very strange. When flying manual, it seems to show correct (although only positive)

Another strange thing. Vspd on telemetry only shows positive values when climbing, but never negative.... (no, I did't set 'positive' on Vspd Telemetry field on taranis). On the old naze clone it did show + & - values correctly...

Attached blackbox and Taranis log files..... F3FC-2016-08-19.csv.txt LOG00205.TXT

FYI: ALT-HOLD is currently activated by LS (left slider being >1300) in Taranis log.

Anything I could try ? I'm completely at a loss......

BTW: are these 'normal' values ? set magzero_x = 14 set magzero_y = -100 set magzero_z = -58 set acczero_x = -332 set acczero_y = -205 set acczero_z = 789 set accgain_x = 4103 set accgain_y = 4089 set accgain_z = 4243

these were the ALT settings on the last flights. set nav_alt_p = 100 set nav_alt_i = 0 set nav_alt_d = 0 set nav_vel_p = 100 set nav_vel_i = 50 set nav_vel_d = 20 iNav 1.2.0 CLI dump 2016.08.19.txt

[digitalentity]

set acczero_x = -332 set acczero_y = -205 set acczero_z = 789 set accgain_x = 4103 set accgain_y = 4089 set accgain_z = 4243

Try recalibrating. If values are consistent (with some small margin for error) - it's good, although it looks like the accelerometer chips is experiencing static stress - i.e. bent board.

[digitalentity]

Also try increasing INAV reliance on barometer by increasing inav_w_z_baro_p to 0.5 or 0.75 and report back. I have a hunch that your issue is related to accelerometer,

It's either calibration or vibration issues. I suspect vibration because at high throttle (~1700) you accelerometer starts to spike:

Low points are almost zero G (free fall). I doubt your machine starts free falling at 70% throttle. Also the very next moment acceleration spikes to 1.5G which I tend to believe.

Uncontrolled climb means that machine is thinking that it's below target altitude and not moving up fast enough. In general it's either misbehaving baro or whacked accelerometer.

[digitalentity]

@wilco1967 can you please try the latest master after #482 has been merged? Won't solve the issue but may help in debugging it.

[wilco1967]

Tried again, this is what I get. set acczero_x = -249 set acczero_y = -189 set acczero_z = 764 set accgain_x = 4104 set accgain_y = 4088 set accgain_z = 4209

another attempt set acczero_x = -250 set acczero_y = -194 set acczero_z = 750 set accgain_x = 4100 set accgain_y = 4091 set accgain_z = 4217

So this seems quite reproducable acczero_x has the largest change, (-332-> -249/250). The rest seem pretty close.

this is calibrated as per Resokk comment..... i.e. 1) up-side down 2) up-side up 3) usb up 4) tail down 5) usb down 6) nose down The F3FC is CW180FLIP mounted acc/gyro...

The board is as straight as can be. Never experienced a (hard) crash. Could this be an effect from soldering during manufacturing. Is it a problem ?

If you think that is a problem, I'll order another board, but any replacement board might just have the same issue (if it indeed is an issue).

BTW: in the meantime I tried flying with set inav_w_z_gps_p = 0.000 set inav_w_z_gps_v = 0.000 It doesn't change much. there still is 'some' alt hold, but 30..40 meters..... so my theory of the alt PID not seeing the baro was incorrect... So Back to default values.

What about my other observations ? Does the Vspd or ACC-Z give some indication on what might be wrong ? I've noticed quite a few times, Vspd shows still zero on a slow climb, and sometimes even slight positive when actually dropping slowly....

So you think motor vibrations are a concern ? They seem to have hardly any effect on Gyro / ACC values... I certainly have flewn with much worse without problems..... propellors are balanced...

I just saw your reply after I wrote above.... will try inav_w_z_baro_p and report back..... Thanks !

[digitalentity]

Telemetry is reporting raw acceleration, not the compensated one. However the velocity is indeed reported incorrectly and that's a telemetry problem. The reported value is unsigned. Fix on the way.

[digitalentity]

If FC PCB is part of the frame - it's a mechanical problem that can hardly be solved - when your Tri is flying the PCB will take some stress from thrust and weight meaning that accelerometer will be reading acceleration that is not really there.

[wilco1967]

OK.... will try with 482

[digitalentity]

I recall having an uncontrolled climb issue in AltHold with my QAV-R. Will try to reproduce the issue and catch it on logs.

[wilco1967]

here is a log of a very short flight with 482 changes.... set inav_w_z_baro_p = 0.750 set inav_w_z_gps_p = 0.200 set inav_w_z_gps_v = 0.200

Still going up/down, but much much less.... I'll try with some different PID settings (I seems a bid high). throttle pulsations still there, but not as bad.

iNav 1.2.0 CLI dump 2016.08.20.txt LOG00207.TXT

flewn on a 3S (hence the rather high hover throttle)...

I'll try some more (forgot the bring the phone, so could change anything outside)....

[wilco1967]

here's another log with the best PID settings I could find.... Still going up/down like 10 meters....

LOG00209.TXT

using these settings set nav_alt_p = 100 set nav_alt_i = 0 set nav_alt_d = 0 set nav_vel_p = 100 set nav_vel_i = 10 set nav_vel_d = 80

it behaves like too high Vel I, but I cannot stop it by changing I... (went from Vel I = 0.001 to 0.255 and back.... that doesn't solve it).

Is it perhaps a resonance effect ? It doesn't show any variation in ACC-Z if I spool up the motors while holding it.... any vibrations from motors / propellors I would expect to be in the X/Y direction, rather then Z.

Is there any filtering setting I should experiment with ?

[digitalentity]

@wilco1967 those logs only confirm my theory - as soon as throttle goes above a certain point (~1640) accelerometer goed crazy. Might indeed be a resonance effect of some sort. You can put even higher weight for barometer (inav_w_z_baro_p parameter).

Can you also record some unfiltered accelerometer readigns (set acc_soft_lpf_hz=0) - no need to engage ALTHOLD, just make sure you put it to 70+% throttle for a few times. Might give us a clue what real vibrations look like.

[wilco1967]

Alright, here is one with set acc_soft_lpf_hz=0 Clearly, the ACC-X and Y noise has increased a lot, that is clearly vibration noise around 100 Hz

Can't really tell if it made any difference on ACC-Z. flight behaviour was no different using 0 or default 15....

Also tried 1hz filter (and 3 and 30), but didn't make a log file.... becomes really slugish at 1Hz, but STILL there are these short throttle bursts (though not as pronounced)... at 3Hz slightly more responsive, but still slugish.... at 30 no different from default 15. LOG00212.TXT

Next I will try to give the baro more weight.....

[wilco1967]

Ohh, just one more thing.... don't know if it is relevant.... These are oneshot ESC's , littlebee 20A, BLHeli, WITHOUT active braking.... That makes them a little quicker to accelerate, and slower to decelarate... don't think it is important, but who knows....

[bk79]

Same has appened to me with borked bearings after 20m height crash...after 55% throttle high vib starts and quad looked like a crazy horse had to throw away two motors out of 4 bearings costed almost like a new motor..xxd 2212 1000kv

Il 20/ago/2016 16:06, "wilco1967" notifications@github.com ha scritto:

Ohh, just one more thing.... don't know if it is relevant.... These are oneshot ESC's , littlebee 20A, BLHeli, WITHOUT active braking.... [image: image] https://cloud.githubusercontent.com/assets/4282983/17831687/0d6266a4-66f0-11e6-9864-58fb65d60665.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-241202012, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWium2DRY5thC69JQ23qJ5fvPSdgHnks5qhwnugaJpZM4Jj2Su .

[wilco1967]

and here is one with set inav_w_z_baro_p = 5

I know, that is way too high, but to see the effect....;-)

It is very agressive now, but STILL those throttle bursts.... they are not continuous as you would see from an overtuned (ocsilating) controller... but come and go.....

And when just hovering (around 1600), ACC-Z is smooth....

I can't 'see' anything on any of the sensors when I run the motors throughout the entire throttle range, while holding the battery tray. The battery tray is decoupled from the actual board (RCExplorer tricopter V3 style), so holding it 'shouldn't' affect vibrations (theoretically ;-)....

Don't know what I can do against these damned vibrations........ they are there.... I can feel them clearly, but are difficult to remove, and I tried many times...

The ACC-Z variations are like 2 Hz.... that is NOT directly motor vibrations (those are closer to 100hz)..... but I wish I could exclude it possibly being resonance.....

The 2 Hz are about the sound you can hear the motors make when making these short bursts... So I still believe it is caused by the motors causing real acceleration, rather then false acceleration readings causing the motor to respond.... I don't see those variations when I'm not in alt-hold.

LOG00213.TXT

[bk79]

Are you using opto esc or bec one?

Il 20/ago/2016 16:42, "wilco1967" notifications@github.com ha scritto:

and here is one with set inav_w_z_baro_p = 5

I know, that is way too high, but to see the effect....;-)

It is very agressive now, but STILL those throttle bursts.... they are not continuous as you would see from an overtuned (ocsilating) controller... but come and go.....

And when just hovering (around 1600), ACC-Z is smooth....

I can't 'see' anything on any of the sensors when I run the motors throughout the entire throttle range, while holding the battery tray. The battery tray is decoupled from the actual board (RCExplorer tricopter V3 style), so holding it 'shouldn't' affect vibrations (theoretically ;-)....

Don't know what I can do against these damned vibrations........ they are there.... I can feel them clearly, but are difficult to remove, and I tried many times...

The ACC-Z variations are like 2 Hz.... that is NOT directly motor vibrations (those are closer to 100hz)..... but I wish I could exclude it possibly being resonance.....

The 2 Hz are about the sound you can hear the motors make when making these short bursts... So I still believe it is caused by the motors causing real acceleration, rather then false acceleration readings causing the motor to respond.... I don't see those variations when I'm not in alt-hold.

LOG00213.TXT https://github.com/iNavFlight/inav/files/428356/LOG00213.TXT

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-241203821, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWitjM3KaESRgmiEcTIxqzqreS1jbLks5qhxJIgaJpZM4Jj2Su .

[wilco1967]

Opto.... 5V power supply is from the F3FC board.

Although these motors are almost 3 years old, the bearings are just fine.... Even though they have been through many crashes ;-). The main problem is the prop adapter is slightly bent (barely visible).... tried straightening it but couldn't get it perfect.... props are balanced. have tried putting some tape at various locations around the motor bell and prop to compensate, but cannot get it any better. the bent seems to be above the propellor hub, so the props are pretty much centered.

These mini quads with their small propellers, have a much higher vibration frequency.... that seems a lot easier to deal with....

Are my vibrations really so bad compared to others ?.... find that difficult to believe.....

[bk79]

If the vibration felt is not noise coming from somewhere in the electronics try using the acc readings on the configurator as your way to measure vibration and Balance...tie your quad tight and with only one prop installed at time run the motor at slowly increasing speed...from 0 to 100% throttle log everything of course and try to plot with the result a waterfall diagram to understand if you have some resonaces in your speed range...if you find any you're fucked or change the motor or change the propeller type...if not you can play with the test throw which means put a small tape on one side of the motor and see if vibration increase or decrease. If they increase put the tape on the opposite sideand spin again

Il 20/ago/2016 16:59, "wilco1967" notifications@github.com ha scritto:

Opto.... 5V power supply is from the F3FC board.

Although these motors are almost 3 years old, the bearings are just fine.... Even though they have been through many crashes ;-). The main problem is the prop adapter is slightly bent (barely visible).... tried straightening it but couldn't get it perfect.... props are balanced. have tried putting some tape at various locations around the motor bell and prop to compensate, but cannot get it any better. the bent seems to be above the propellor hub, so the props are pretty much centered.

These mini quads with their small propellers, have a much higher vibration frequency.... that seems a lot easier to deal with....

Are my vibrations really so bad compared to others ?.... find that difficult to believe.....

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/461#issuecomment-241204718, or mute the thread https://github.com/notifications/unsubscribe-auth/ALSWitjafCB7JbMpLTaKqJmDcnKzpfGVks5qhxY_gaJpZM4Jj2Su .

[wilco1967]

That is what I've been doing...... On the bench it seems to have no effect.....

But I tried something else just now.... fly it in position hold, but NOT in alt-hold.... Slowly increase the throttle and let it climb faster and faster...... and indeed, I see the ACC-Z go crazy slightly above 1650 (It hovers at 1600 on a 3S)....

here is the log..... LOG00214.TXT

Now replacing motors is kind of an expensive option.... perhaps (just perhaps) new motors will solve it, but after one crash, we're probably back were we started, and my wife won't let me replace motors every time.... ;-)

I have some broken arms (well, not me, but the copter ;-). perhaps shorter arms will shift the resonance frequency somehow...

I guess, this is a downside of the otherwise perfect F3FC board.... impossible to isolate the FC from the frame.... the FC IS the frame....