LPSP.VZ jump during POSCTL

[JohnSnowball]

I made a long flight, all is right except for the altitude hold, the copter seems "floating" in height,(almost no wind), and I checked the log, and found that the LPSP.VZ is not contine from time to time. Here is the "jumping" moment: I checked that LPOS.Z and LPOS.VZ are both correct and also RC input is continue. I'm not sure if it's the reason that cause my copter "floating", but I suppose this should be fixed... Here is the link of my log http://logs.uaventure.com/view/pyW2SSFTrx2z72Wvq8z4oU however, I have to zoom several times to see that jump clearly, so you may not be able to see that online.

I don't know how to upload a log file here....If you need more log to fix this bug, just tell me how to send the log. Thx!

[mzahana]

I would like to report a similar situation. I have faced this several times using both LPE and EKF2, and using Lidar lightware as range sensor. That is in versions 1.5.1 to 1.5.5, using different Pixhawk boards.

Recently, I was flying F550 frame with master branch v1.6.0, but without Lidar, only GPS and baro for altitude estimation. I was using EKF2, and was flying fine for couple of flights in Manual/ALTCTL/POSCTL modes. In the last two flights, after 4 successful flights, however, the copter would not go down in ALTCTL mode even though I was pulling the throttle all the way down. I landed in Manual, disarmed, then armed again and tried ALTCTL and POSCTL, and I get the same problem in altitude. Please help in fixing/identifying this issue. A log is available here, http://logs.uaventure.com/view/HNFY7UpSuabPusXNsj2vzM#_PLOT

[Stifael]

@mzahana the second sounds similar to that https://github.com/PX4/Firmware/issues/6604 The first one seems to be mcpos,control problem.. I will look into it

[MaEtUgR]

The accelerometer z-direction does not clip, just to rule this one out...

[JohnSnowball]

@MaEtUgR LPSP.VZ doesn't depend on accel.z, and lpos.z estimated based on accel.z is continue,

[LorenzMeier]

@priseborough Can you please chime in and inspect the log?

[priseborough]

The second log was using the ecl estimator at commit 7e2597e and exhibits a problem with accelerometer bias estimation that is causing offsets in vertical velocity and position. Unfortunately this problem develops before arming so is not captured in the log. However a vulnerability to timing jitter and high amplitude inputs that could cause incorrect learning of accel bias estimates was fixed in the ecl version we changed to recently, so I would recommend that you update to PX4 master on or after commit ed9a9b7. If the problem persists you can do the following:

1) Use the new logger SYS_LOGGER=1 2) Use a high quality sd card that doesn't produce dropouts in the log (I have good results using a Sandisk extreme 32GB). Increasing the RAM used by the buffer will reduce the dropout length. This is defaulted to 16kB here but can be increased depending on your system configuration https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS#L857 3) Turn on dedicated replay logging EKF2_REC_RPL=1 4) Turn on logging from boot to disarm SDLOG_MODE=1 5) Post a link to the log in https://github.com/PX4/Firmware/issues/6604

[MaEtUgR]

@JohnSnowball We had cases where accel.z problems resulted in wrong vertical velocity estimates hence wrong altitude estimates and the controller tried to compensate using the setpoint LPSP.VZ. But I checked and at least the accelerometer did not clip here in your case.

[JohnSnowball]

@MaEtUgR thanks for explain! in fact I'm a bit confused by your discussion, I can't tell which case will solve my bug......

[MaEtUgR]

@JohnSnowball I think if you provide a replay log (more detailed for estimation debugging) like described above (https://github.com/PX4/Firmware/issues/7048#issuecomment-296490122) @priseborough will surely have a look at what goes wrong.

@priseborough Does this have any relation to https://github.com/PX4/ecl/pull/265 ?

[priseborough]

We are dealing with two separate problem reports here.

The problem reported by @JohnSnowball looks like a controller set-point issue.

The problem reported by @mzahana is due to estimation error and discussion should be moved to https://github.com/PX4/Firmware/issues/6604. PX4/ecl#265 is capable of masking the effect of vertical velocity estimation errors but will require the new mode to be selected appropriately on the PX4/Firmware side of the interface.

[JohnSnowball]

@MaEtUgR I would like very much to upload a log(I got several with same bug), but I can't paste any here, even I compressed them to ZIP. Do you know any other ways to upload px4log here?

[RomanBapst]

@JohnSnowball use logmuncher, http://logs.uaventure.com/

[JohnSnowball]

@tumbili yes, already did that, as I pasted a link at the first http://logs.uaventure.com/view/pyW2SSFTrx2z72Wvq8z4oU but for my case, you have to zoom to see the LPSP.VZ discontinuity. I don't know if we can do that with logmucher, I guess a full px4log should be better.

[TSC21]

@JohnSnowball what's the current state for you?

[LorenzMeier]

Position controller has been revised since, closing as stale.

[Stifael]

@JohnSnowball I will close it because we haven't encountered a similar issue. The firmware has changed a lot since then and although I am not able to prove that it is fixed, it is very likely that you will not encounter the same issue again. It would be great if you can do another flight test, and if there is anything that seems wrong, then please don't hesitate to reopen this issue or create a new issue.

[JohnSnowball]

@TSC21 well, afterwards I use other versions, up to now , I didn't reproduce this bug.

[JohnSnowball]

@Stifael Ok, If I met this bug again in the future, I will report that. For the moment, I can't reproduce the same thing.