Hi guys, I have not followed the last release, so I got very upset when I updated my old, steady 3.2.1 Octa-Quad multirotor with the new 3.3.2. Of course I do realize that my system is kind of a mess, because I am using that multirotor for research and testing, so I know there are some vibrations and even some magnetic disturbances. Besides, the 3.2.1 had been flowing just fine. 

I installed the firmware, did all the calibrations (accelerometers, magnetometers, motors, esc..) and went flying. 


I attached the telemetry, but here there are some figures:

Throttle Out:



Accelerometer Bias

Here is the only bad result from an autotest:

Test: IMU Mismatch = FAIL - Check vibration or accelerometer calibration. (Mismatch: 2.61, WARN: 0.75, FAIL: 1.50)

I tried to play a little bit with the EKF parameters, but got worst, so I would like to share my experience for you guys can help me to find the best direction to move on and get rid of this (only) issue.


Views: 2097


Reply to This

Replies to This Discussion

Ia working with dronekit and streaming data at 20 Hz through udp. I have been always noticed some altitude oscillations before arming, but those looks very strong. I tried playing with the bark noise and accelerometers noise and the amplitude looks coherent with my changes. I am not into the code, so I ask to some developer why is it happening aand is it normal? Besides, after the vehicle had been armed for a while, I received a message on majority, kind "system calibrated" and the oscillations stopped even when disarmed

I had a quick check with Paul Riseborough (author of the EKF) and he says that he's seen this as well.  We use slightly different tuning parameters when armed or disarmed and it's likely that the default disarmed-parameters, which we want to quickly figure out the accelerometer and gyro offsets, are set a bit too aggressively which leads to some overshoot.

Apparently "EKF2" which comes in Copter-3.4 doesn't have this problem.

Richard, which has less vibration, stiff or flexible frame?

Hi guys, here I am back with an update. I balanced the props carefully (actually I missed to balance them vertically and even if APC they were pretty off balanced) and here is the new VIBE graph:

It really looks better, even in flight I see a huge improvements. The altitude though is still oscillating of about 1 meter (slowly, maybe now it is only a matter of tuning)

Now a big issue I have been noticing. Whenever I set the system in GUIDED mode, the vertical control goes kind of crazy: the Throttle Out oscillates a lot and the vehicle bounces like crazy. I am using a standard message to setup the vehicle's velocity, but while the horizontal flight is nice and smooth, the vertical is not. Here is some figures:



Just for comparison, check the Throttle Out in AltHold or LOITER mode


Does someone know how to deal with it?

Here I tested the GUIDED mode. In the attached log you will see a flight where I keep switching GUIDED-LOITER. In GUIDED mode I have a Companion PC reading the Transmitter and providing a velocity reference (that was kept to zero, except for a minute where I tried to climb)






As mentioned on Gitter, I've looked at your logs and it's certainly clear the throttle output is very noisy.  You've uncovered a bit of a mess up in the Copter-3.3.2 release.  It looks like the fix to increased the Guided mode's velocity controller's update rate wasn't actually included in the release (despite the release notes saying it was!).  I'll add this fix to Copter-3.3.3-rc2 which will go out within a week.  Until then you may want to test with latest.

Thanks for the report and sorry for the troubles!

Other way around, old versions only used the mpu6000. See Rob's message posted on rcgroups..

:Reply by Rob_Lefebvre on December 31, 2014 at 7:02am
Here is a brief history:

1. The APM class boards used the MPU6000 gyro/accel chip.

2. The Pixhawk was originally designed to use the LSM303D chip, as it was supposed to be better.

3. Initial prototype testing of Pixhawk boards revealed problems with the LSM chip. To avoid further delays of Pixhawk production, it was decided to add the MPU chip back onto the board, so now there would be 2.

4. At some point shortly after the MPU was added, the LSM problem was solved, but it was decided to leave both chips on the board anyway, as it allows us to take advantage of redundant sensors.

5. Up until 3.2, the MPU chip was the only one being used. The LSM was basically ignored. If it failed, the code did not care.

6. Starting with 3.2, we wanted to start taking advantage of the sensor redundancy, so we began using the data from the LSM. Generally this is fine, except for cases where the LSM has a problem. Or the MPU has a problem. We did not forsee this failure rate until the code was released. The problem is, either chip can fail, and the code doesn't know which is good and which is bad. It just knows they're different. In this early stage, using two sensors does not really offer redundancy and increased reliability. It actually doubles our chance of having a problem

Randy, that was really helpful. Today I downloaded the master revision and the altitude control was very good, even in Guided mode. The overall flight performance look even better. Tomorrow I'll post some data If I'll get the chance.


Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service