Hello all
i have some question about accel vibrations and rate vibrations that i cant find answers on the net
What I have understood so far rate vibration is from prop-wash thats make noise on gyro and it will make problem in motor mixer that causing oscillation in RATE and RCOUT values.
And accel vibration in fact is shaking, that causing oscillation in PIDs
is above understanding is true ?
thanks alot.
I haven’t really heard of many people separating the vibration into “accel vibrations” and “rate vibrations”. I think at least for ArduPilot the issue is the frame’s vibrations affecting the accelerometers. When the vibrations are high enough this saturates the accelerometers and causes the EKF to lose its climb rate estimate which leads to the vehicle climbing rapidly. It can also affect the horizontal axis but the vertical axis has problems first because gravity steals 1G of range from the vertical accelerometers.
Gyros are not affected by vibrations nearly as much as accelerometers.
Interesting subject!
I think if we are talking about acceleration (affecting on X Y Z axis) then we need to consider the angular acceleration (derivative of RATE). Correct me if this is wrong or non sense.
However, when @hosein_gh raised this question, I think you mentioned about the source of those noise? I guess there are 2 types of noise (neglecting the rest):
Does it make sense?
@rmackay9 I was think that there is one type of vibration till i saw this answer by @Leonardthall
You have a very serisous mechanical issue you need to address here. There is nothing we can do in the flight controller to deal with this. Something is loose. It is not accel vibrations but instead it is rate vibrations that are causing the problems.
Orginal post : Autotune; why does larger copters not twitch, unless I move a stick? - #19 by Leonardthall
OK then! I guess when Leonard mentions “accel vibration” vs “rate vibration” he’s talking about where he sees the oscillation or noise. So the difference is less about the source or cause of the vibration and more about what sensor is affected.
I would guess in general that largest source of accel vibration comes from the propellers passing over the arms.
… and maybe in the case Leonard was investigating the “rate vibration” came from a resonance in the frame or perhaps something like a gimbal moving back and forth as the vehicle moved.
Anyway… I will leave it for others to discuss further!
Ok, where do I start here…
Vibrations come from a range of sources:
Now each of these sources of vibration energy happen at different parts of the aircraft and at different times. Each move through the frame and are eventually felt by the flight controller through the vibration mounting of the controller.
The question is “how is each energy source felt by the flight controller?”
This is a very complex question and is heavily dependent on the structure of the aircraft. But the 6 axis we are talking about here (xyz, accel and gyro) all detect each source of vibration. Depending on the structures this vibration can be more pronounced in one sensor than another. Poorly designed vibration isolation systems can amplify signals or couple accelerations (accel) to rotations (gyro) signals. Similar things happen due to the frame structures.
The next important question is “how does this energy source move through the controllers?”
This noise impacts 3 main systems:
The most well known is the EKF position estimate as this has a dramatic impact on the aircraft. Basically it can cause the aircraft to fly away vertically (before Randy and I added some safety measures that detect and prevent this). People notice when their aircraft climb out of control 
Less well known is rate controller noise. This has been very difficult to see directly before we added fast (full rate) rate logging. This is gyro noise that passes through each pid loop and is present on the output signals to the motor mixer. I generally consider anything more than 10% magnitude noise too much. This noise can be reduced by using the harmonic notch filter, low pass filters, or reducing the PID parameters.
Rate noise can enter through two paths, the EKF through the attitude controller or directly through the gyro and rate controllers. The angle P and T filter can be used to manage the EKF path. The Gyro filter, Notch and Harmonic Notch, E and D term filters and PID values can be used to manage the Gyro path.
The Z position controller should be well filtered and less susceptible to vibration.
There are a number of steps we should take to manage these vibrations:
I hope that goes some way to introducing the problem and some of the ways we address these problems in the greater system of the aircraft and autopilot.
with reference to this software and hardware setup and putting these values to default.
EK2_ALT_SOURCE = 0
EK2_ALT_M_NSE,3
EK2_RNG_USE_SPD,2
EK2_RNG_USE_HGT,-1
EK2_RNG_M_NSE,0.5
EK2_RNG_I_GATE,500
RNGFND_GAIN,0.8
I like to know why is the FCU complaining of Error Position vertical, then slowly PreArm: EK2 pitch/roll inconsistent by xx degrees error, before arm. After a while, the ground speed will start to fluctuate and climb without moving the UA, after enable back both the flow sensor and rangefinder. when flow sensor and rangefinder are not enabled, this error did not appear. This has caused us not able to arm the UA.
We had tried changing the FCU, swap the Flow sensor to another UA to check its health, change wiring, re-calibrate the compass + Acceroemeter by disabling both the flow sensor and Rangefinder, etc. Still, this error exists before disarm.
This phenomenon seems does not appear on another UA with the same type of sensors used.
We have been investigating this issue for few days already.
It looks like the Optical Flow is going crazy after some time, at least that’s the only thing I can find that is an “input” that correlates with the symptoms (outputs)
Are you sure these are correct as per the doco?
FLOW_FXSCALER,12
FLOW_FYSCALER,-50
FLOW_ORIENT_YAW,0
FLOW_POS_X,0
FLOW_POS_Y,0.08799999952316284
FLOW_POS_Z,0.09000000357627869
https://ardupilot.org/copter/docs/common-optical-flow-sensor-setup.html
Yes, we did the flow sensor calibrations described here.
Yes, as per how to mount following here. The question is the UA is not moving at all on a table, not flying, not arming.
FLOW_ORIENT_YAW,0
FLOW_POS_X,0
FLOW_POS_Y,0.08799999952316284
FLOW_POS_Z,0.09000000357627869
Previously, we try to connect to CAN P2, but the Mission Planner -> opt_m_y, opt_m_y and opt_qua remain 0, it seems like connected but did not interface into the system, of course CAN_P2_DRIVER is set to 1.
Is there a proper way to disable the Hereflow onboard rangefinder and use an external rangefinder instead? We can enable both but the mission planner only recognizes HereFlow onboard rangefinder and not the external rangefinder.
HereFlow connected to CAN P1
LightWare SF20 / LW20 conencted to serial port 2 (Telem 2)
– SERIAL2_PROTOCOL = 9 (Lidar)
– RNGFND2_TYPE = 8 (LightWareSerial), we cannot set it to RNGFND1
We did some investigations and inconclusive.
Is there a relationship between the following parameters on EKF?
Previously with this set of values we get these error easily on disarm state.
INS_POSn_Z = -0.035
RNGFND2_GNDCLEAR = 9
RNGFND2 reads 9cm display on Mission planer
the error seems gone when we changed it to:
INS_POSn_Z = -0.03
RNGFND2_GNDCLEAR = 13 or 14
RNGFND2 reads 9cm display on Mission planer
we seem to have solved the FCU complaining of Error Position vertical before arm, drop height during pitch forward and backward, the flight goes into oscillations issue using the following parameters. We did a re-Autotune again also.
EK2_ALT_M_NSE,3
EK2_ALT_SOURCE,0
EK2_GPS_CHECK,0
EK2_GPS_TYPE,3
EK2_RNG_I_GATE,500
EK2_RNG_M_NSE,0.4
EK2_RNG_USE_HGT,63
EK2_RNG_USE_SPD,6
MOT_THST_HOVER,0.128443
INS_POSn_Z = -0.03
PSC_VELZ_P,6.6
RNGFND_GAIN,1
RNGFND2_GNDCLEAR = 13 or 14
RNGFND2_POS_Z,0.06
interestingly, we are not sure why we need to increase PSC_VELZ_P.
Generally, it should not be required to adjust PSC_VELZ_P.
We are also puzzled, MOT_THST_HOVER : 0.25 or below the expected hover thrust percentage (low is safe), then PSC_ACCZ_P to MOT_THST_HOVER, but PSC_ACCZ_P range is 0.200 - 1.500, in our case it is less than 0.2.
