I have been flying with the latest master 1.6.0, using LPE on my quad. I have been trying to utilize lidar-lite v3 and optical flow sensors as well as GPS to achieve stable hover on position control and auto.hold modes. On the first two flights, I have tried to use lidar-lite v3 and optical flow together and here are the results:
http://logs.uaventure.com/view/buCJ8RZ57B3Kg7ZcXeuiy8 as you can see in this log, when I switch to position control mode, although quad’s positon setpoint on z axis barely changes it gained altitude in a brief moment where I had to take back control by switching back to stabilized mode. I can confirm that the quad actually gained altitude and it’s not a faulty sensor reading or anything. We can confirm that copter gained altitude by looking at many graphs such as actuators and many more. (mode change sequence is as follows: stab-posctl-stab)
http://logs.uaventure.com/view/JyNaZdpgQWoa8C7TbX4o3V I have also tried the same thing as log 1. I have tried to switch to position control 6 times in this log, and in almost every trial I had to immediately switch back to stabilized mode because the copter again shoots up in the air immediately when I switch to position control (mode change sequence is as follows: stab-posctl-stab-posctl-stab-posctl-stab-posctl-stab-posctl-stab-posctl-stab)
http://logs.uaventure.com/view/o8fTZufPqLz2tnhWsC4hzP On this flight, I have disabled the lidar lite v3 parameter, as well as disconnecting the optical flow sensor, thinking that my altitude problems might be caused by sonar or lidar that the LPE have been fusing into my altitude reading. But no luck, copter kept doing the same thing. This time, I’ve decided to use auto.hold mode in order to see maybe it would make a difference. This time, there was no immediate shoot up but the altitude was slowly diverging again in the same direction, upwards. (mode change sequence is as follows: stab-hold-stab-hold-stab)
http://logs.uaventure.com/view/aNqoNg8rrnhVX4dtR7xH2JThis time the sequence is as follows stab-hold-posctl-stab and we can see that although the position setpoint on z axis stays the same, it starts the diverge again in the negative-z direction towards the sky, and then also the setpoint changes which I suppose is as a result of this z error over time.
http://logs.uaventure.com/view/ssmkwAQ9thgytJLHzqbSeThis time the sequence is as follows stab-posctl-stab and it is clearly observed that although the position setpoint on z is constant, the altitude readings diverge from this number over time, causing me to switch back to stabilized mode to recover the quad.
I hour later after I’ve recharged the batteries, I could manage to fly again. This time, I’ve flown almost a 20-minute flight. Then I’ve deduced that this might be related to z velocity PID’s so I tried to reproduce the PID controller tuning example described in Flight Plot example. While I was doing this, the copter started to not respond to my stick commands (while I was on stabilized) and actually went to opposite direction while I was pulling the stick towards the position that I was standing on. Later on as a last resort, I tapped the RTL switch and the copter switched to RTL mode, although only to further open distance and start flying away and up. After It has reached to an altitude of ~300 meters, I have lost sight and data link of it, unable to recover from the crash. I only have the .mavlink file from the QGC session for this flight and nothing more.
Please help! Could anyone help me to troubleshoot the z-axis problem described in the logs and which lead to a flyaway for me, so that I can be cautious and careful about what might have caused the problem, so that it is not reproduced again.
z altitude hold problem I faced too many times and tried out some pid tunings but all tries were ended up successfully by chabging hardware (pixhawk), it is usually a baro drift, i would check the foam of barometer, or try same configuration with only changing pixhak, also it may be because of accZ meaning a vibration. u may use vibration dampener, also check accZ values during flight and no arm situations. in disarmed, it should measure gravity, in flight, it should not exceed 15 m/s^2. if so, u have a vibration.
I had similar problems since update to v1.5.3. It too was trying tune pids but later realized it was an EKF2 problem. Here is one of the logs that EKF2 went bonanza mid-flight.
I faced the same exact issue several times, and caused me a crash of a several thousand of dollars build !
I changed many Pixhawks, and changed firmware from 1.5.1 to 15.5, trying both LPE and EKF2. All produce the same problem.
An issue on github is opened,
I think it’s mainly a firmware problem, as it used to work fine with me with much older firmware, 1.4.4 I guess. However those old firmware versions do not support Lidar/Tera Ranger sensors, which I needed to use. I hope it gets fixed soon!
@deksprime I used stable version 1.5.5 with LPE, and got the same issue. I guess, you have not got unlucky yet
Today, I had similar problem. I was not able to bring the copter down in Altitude hold mode, even by pulling the throttle stick all the way down. I had to switch to Manual mode in order to bring it down.
I’ve lost two quadcopters this way, but I guess it was due to really bad oscillations on my configuration. But in all of my trials, I had GPS. I think my problem was due to noise -which I have later noticed- was caused by the companion computer (Raspberry Pi 3). Especially if you are using an I2C splitter (if it is a clone then the noise levels get even worse). So beware of the vibrations caused by poor damping of the fcu, as well as EM noise caused by on-board electronics. So I guess it’s not a software issue but a poor hardware configuration issue (at least in my case)
Recently, I flew couple of flights with no problems until the last two flights showed similar problems. In those tests, only baro and gps were used, and no Lidar was mounted. I could not bring the copter down in ALTCTL mode (or position) even though I was pulling the throttle all the way down.
Here is a log, http://logs.uaventure.com/view/HNFY7UpSuabPusXNsj2vzM#top
It’s just weird, that at the same time of the tests, it exhibits different behavior, while the weather conditions are the same (low wind)!
