@rmackay9 Yes, there is no rangefinder in the log above. But in the pic above couldn’t you see that the same moment Baro.alt = 10 and GCS.alt = 0? Also from the baro alt curve you can obviously see that baro alt never goes down to zero until copter landed, but the GCS alt have a zero moment before landing.
It’s fine for the two to be different though as explained above re the difference between alt-above-ekf-origin and alt-above-home. I think I might duck out of this discussion now and leave you to struggle a bit more with it at least until you find an issue that affects flight control.
Thanks for using ArduPilot and best of luck.
Furthermore the HUD shows you’re starting a climb. And the HUD is night updated by the microsecond. Whereas the dataflash log is updated very very rapidly. And you still have different points selected on the graph vs the table vs the HUD. So I still don’t see anything wrong here.
Could you please explain my case when both BARO and SONAR altitudes agree, while estimated altitude at some point suddenly (probably, after EKF switch) drifts for several meters:
@arifg Im so confused about the CTUN.BAlt, CTUN.Alt, CTUN.DAlt, CTUN.DSAlt, CTUN.SAlt, CTUN.TAlt? Where can I find the detail explaination?
I’m not a developer, though I have some experience in control automation and programming, so this is as far as I understand:
CTUN.BAlt - Barometric altitude;
CTUN.SAlt - Sonar (Rangefinder) altitude;
CTUN.Alt - Calculated (estimated) altitude, the altitude which controller assumes as current after processing data from the sensors;
CTUN.DAlt - Desired altitude - the altitude which controller “wants” to be, usually, when everything is right,follows CTUN.Alt with a small time lag.
Again, this is my understanding, not a formal description, somebody from developers would probably correct me…
arifg
Thank you so much!
any conclusion? I got the same problem. It causes the copter the crash
Can you elaborate on “it causes the copter to crash”? I don’t think this is something that causes crashes.
It does. In Auto mode it causes to copter to mistake in altitude evaluation and it crashes into a tree or even into the ground when altitude became negative. I experienced this several times but saved my copter by switching to manual at last moment. Can’t rely on auto mode outside of reception range for this reason.
My problem happens in loiter mode. There are two scenarios: fly up uncontrollably or fly down uncontrollably which would result in a crash. Please see the log file: 1 5-24-2017 3-24-02 PM.bin (160.4 KB)
I suspect this is a different problem than the one in this thread. I may repost it in another thread.
@nealjing yes, it would be wise to start a new thread.
And a log of an actual flight plus a description of exactly the process you went through and the result you saw would help.
nealjing,
That log is mostly empty so you may not have grabbed the correct one.
It’s most likely to be vibration levels.
http://ardupilot.org/copter/docs/common-measuring-vibration.html#common-measuring-vibration
http://ardupilot.org/copter/docs/common-vibration-damping.html
Could you,please explain what happened at about 10:30 in this case:
Log is here: https://1drv.ms/u/s!AieROjktQIZ3jkhI6yJyeS6hD6Qj
About vibrations: I just figured out that LightWare Lidar on a serial input, 19200 baud may cause low-frequency (2-3 Hz) vertical vibrations of self-oscillation nature due to a latency in receiving of samples from Lidar. In this case it creates a loopback with phase shift around 180 deg. at about 2-3 Hz range, creating conditions for up-down auto-oscillations in height (z-axis). These vibrations hard to detect because they are not present while on the ground, so all my ground tests were clear but appeared only when airborne, causing random EKF switches and increase in battery load. In my case it was not possible to get rid of them using SONAR_GAIN value - vibrations existed always as long as Lidar was honored by the autopilot. Also I tried to change Altitude Hold P-value but with no joy. I was able to reduce them significantly though by using internal Lidar median filter. And switching to I2C interface allowed me to finally get rid of these oscillations. But the log above supposed to be “clean”. At least I couldn’t find any correlations between vibrations and altitude shift.
1 Like
Really… ok, that’s very interesting. We’ve never tested the latency of the serial interface… I will add that to my list to look at.
Thanks for the update.
You know, I just had a thought that maybe there is potentially additional contributing factor: I use DJI E310 “propulsion system” with its “active braking” technique: http://wiki.dji.com/en/index.php/E310#ACTIVE_BRAKING. Which potentially could make the auto-oscillation effect more prominent by reducing vehicle response time to altitude change.
Arif,
It’s possible but many ESCs have active breaking and it’s generally a good thing to have. It means the motors/ESCs try harder to slow down the propellers which results in better control.
1 Like
Yeah, I know that, just mentioned this as a possible contributor to the problem I’ve described, for you to have the full picture.
We are using the Lightware Lidar connected via serial.
Should we be looking for this problem in 3.5rc8 or has it been resolved?