Px4-autopilot: LPE runaway Z velocity
During rest, I'm finding that local_position_estimator, whether immediately or after a small amount of time, starts drifting negative in a linear manner. It's fusing only vis_pos and vis_yaw. The vision pose estimate Z remains at the origin while this is happening.
- vision_pose_estimate.z = red
- local_position_ned.z = blue
- local_position_ned.vz = light green
- altitude.altitude_local = white
This is just a guess, but it seems like this could be caused by bad values in the noise density value? Where do those values come from? My IMU data looks alright, with no jumps at rest. Let me know if any other logs/values are required. There are no flight logs because no flight occurs during this test.
Details
- Snapdragon Flight (software v3.1.3.1)
- PX4 v1.6.4
Seanmatthews
All 26 comments
Sometimes good measurements last several minutes before the problem begins:
Seanmatthews
on 2 Aug 2017
Does it make sense that estimated Z velocity hovers around -0.5?
Seanmatthews
on 2 Aug 2017
@Seanmatthews can you please share your LPE parameter list config? Are you fusing baro?
TSC21
on 3 Aug 2017
Check your z accel calibration, also I typically have baro fusion on as well.
jgoppert
on 3 Aug 2017
LPE_FUSION is 12 (vis_pos and vis_yaw only). My z_acc is a steady -9.8ish.
Seanmatthews
on 3 Aug 2017
@Seanmatthews please share the full list of the LPE parameters so to check how they are configured right now.
TSC21
on 4 Aug 2017
LPE_FUSION 12
LPE_VIS_DELAY 0
LPE_VIS_XY 0.001
LPE_VIS_Z 0.001
Seanmatthews
on 4 Aug 2017
@Seanmatthews did you try to recalibrate your accel?
TSC21
on 8 Aug 2017
I suggest you using INAV estimator instead of LPE. Kalman Filter do have problems like this.
kechaofan
on 8 Aug 2017
I suggest you using INAV estimator instead of LPE. Kalman Filter do have problems like this.
It has nothing to do with the fact that this is a Kalman Filter. Besides, INAV is becoming deprecated, so not the best of suggestions.
TSC21
on 8 Aug 2017
@TSC21 I did a recalibration that somewhat ameliorated the issue, though vz still decreased, albeit slowly. After re-flashing the board, the issue seems to have gone away for now. Re-flashing was done with the board hanging sideways, if that matters at all to some initial calibration.
Seanmatthews
on 8 Aug 2017
board hanging sideways
What do you mean with "hanging sideways"?
TSC21
on 8 Aug 2017
@Seanmatthews you have LPE_VIS_XY outside of the recommended range, that will cause numerical issues with the filter. I would recommend leaving LPE_VIS_XY at 0.1, then you can try LPE_VIS_XY at 0.01, LPE_VIS_XY = 0.001, definitely won't work. Same thing for LPE_VIS_Z. At those levels it will basically always fault as well. If your measurement is ever off from the predicted more than a couple of millimeters it will throw it out, so pay attention to the vision fault messages.
jgoppert
on 8 Aug 2017
I also remember that there were some issues (in the past; not sure if we fixed it) with accel bias estimation with baro fusion turned off.
mhkabir
on 8 Aug 2017
Hi @Seanmatthews ,
I have the same problem as yours !! Have you resolved the problem?
Figure1: local_position_z(NED) is increasing gradually , however, local_position_x and local_position_y are static.
Figure2: velocity in z is running away.
I also recalibration px4 but the problem still exist. Can you explain your method "hanging sideways" explicitly ? Is it related to initial calibration ?
Thanks a lot!!
EdXian
on 10 Aug 2017
@EdXian It's nothing I did in a scientific way. I re-flashed the Snapdragon Flight board while it hung sideways off of my desk by the USB cable. The Z velocity still drifts a small bit, but not by that amount anymore. All my calibration attempts resulted in worse calibrations (incorrect resting X and Y accelerations) than the starting calibration, FYI.
Seanmatthews
on 15 Aug 2017
@Seanmatthews It seems that the parameter LPE_VIC_P should not be set nearly zero. I'm not sure . I change it to default value and the problem was resolved. How did you set LPE_VIC_P ?
EdXian
on 15 Aug 2017
@r1b4z01d suggested that this could have something to do with "wind" drafting over the on-board barometer during calibration. I did have my AC on in a small room while flashing and/or calibrating.
Seanmatthews
on 15 Aug 2017
No, there is no way for the baro to affect any calibration.
mhkabir
on 15 Aug 2017
If that's the case, then perhaps it affected the barometer while sitting on my desk or floor in front of the AC?
Seanmatthews
on 15 Aug 2017
Maybe related to https://github.com/PX4/Firmware/issues/7083
ecmnet
on 17 Aug 2017
@ecmnet I suppose it's possible. There are certain issues with out-of-the-box PX4 that I've noticed and haven't had time to properly look into. For now, I re-calibrated a few times, and then always check the barometer and z values before flight. However, this is still very much an open issue.
Seanmatthews
on 24 Aug 2017
@mhkabir
I also remember that there were some issues (in the past; not sure if we fixed it) with accel bias estimation with baro fusion turned off.
I am quite sure this issue is still present. At least we can't seem to get reliable z-performance without enabling the barometer. However by just enabling the barometer and setting the LPE_BAR_Z parameter high seems to do the work.
@EdXian
It seems that the parameter LPE_VIC_P should not be set nearly zero. I'm not sure . I change it to default value and the problem was resolved. How did you set LPE_VIC_P ?
Correct, then numerical problems starts to appear. We have experienced the exact same behaviour while trying to reduce this to approximately 0.0006 but then we started to see a lot of "reinit P" errors, indicating that one of the variance entries in the covariance matrix has become 0. See https://github.com/PX4/Firmware/issues/7884
mindThomas
on 6 Sep 2017
@mindThomas this is a pinned issue that requires resolution. Unfortunately, none of us had the required time to look into it and solve it.
TSC21
on 6 Sep 2017
Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)
PX4BuildBot
on 21 Feb 2018
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a temporary error. The following address(es) deferred:
[email protected]
Domain evercl.com has exceeded the max emails per hour (207/200 (103%)) allowed. Message will be reattempted later
------- This is a copy of the message, including all the headers. ------
Received: from o5.sgmail.github.com ([192.254.113.10]:43372)
by apollo.graphium.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128)
(Exim 4.89_1)
(envelope-from
id 1eoU6K-0007bd-Ov
for [email protected]; Wed, 21 Feb 2018 08:06:50 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com;
h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe;
s=s20150108; bh=6DjCoWK5Iym89Zgw09caHPpFgR4=; b=nXuOj6ajfqlPFIz8
uzHDU/TxYuNRGw4vPSWcnfRgvpuhfhc4WqdggMd3Sjo50dOsVcDSZ3fTKUS/vwE9
lQFyEr6fQto0wtppPd150oCsv1UakOcxM+Dho2QopyY2oGberSDSeUtmOJ5+5GbD
0ZPOvvYTK6BvI5cE8IB2ZH+qNaY=
Received: by filter0846p1mdw1.sendgrid.net with SMTP id filter0846p1mdw1-25133-5A8D6E2F-1D
2018-02-21 13:03:43.42612097 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17])
by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id Rdl0yxkvTX-tfU__WMq0Gw
for rr@evercl.com; Wed, 21 Feb 2018 13:03:43.384 +0000 (UTC)
Date: Wed, 21 Feb 2018 13:03:43 +0000 (UTC)
From: PX4 Build Bot notifications@github.com
Reply-To: PX4/Firmware reply@reply.github.com
To: PX4/Firmware Firmware@noreply.github.com
Cc: Subscribed subscribed@noreply.github.com
Message-ID:
In-Reply-To:
References:
Subject: Re: [PX4/Firmware] LPE runaway Z velocity (#7723)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_5a8d6e2ff1c2_68142ac5a51e6ec4726e3";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: PX4BuildBot
X-GitHub-Recipient: evercltech
X-GitHub-Reason: subscribed
List-ID: PX4/Firmware
List-Archive: https://github.com/PX4/Firmware
List-Post: reply@reply.github.com
List-Unsubscribe:
https://github.com/notifications/unsubscribe/ACSImLL-g7p5einWI8mVrlrVGBsdaQB5ks5tXBQvgaJpZM4OrMn_
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: [email protected]
X-SG-EID: f9JBnm3v7f66Apd0aaWYVQ3B9+/KMPyXlt1e6LbTR8VoqSeX+Hjw8csMke/m+L4snyCcsmrG9RRnH2
sncT35ToEPuKnCDY/MdPmYyZd3deN5pDzW00V1A7hxGZfcoPHFGpPreAlw3d0LwHruQCp6xBd5Ob9w
xLcOCuK6eAakcPZAOFRkE8o5dyNUVhYtYetTRlprz6iigCoi0e2Kc2sAhLZesHaimrqOraSDM5erSY
g=
----==_mimepart_5a8d6e2ff1c2_68142ac5a51e6ec4726e3
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Closed #7723.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/PX4/Firmware/issues/7723#event-1484604725
----==_mimepart_5a8d6e2ff1c2_68142ac5a51e6ec4726e3
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Closed #7723.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
----==_mimepart_5a8d6e2ff1c2_68142ac5a51e6ec4726e3--
evercltech
on 21 Feb 2018
Related issues
prothen
路
5Comments
Stifael
路
3Comments
FaboNo
路
5Comments
kainism
路
4Comments
huangwen0907
路
3Comments
Most helpful comment
@Seanmatthews you have LPE_VIS_XY outside of the recommended range, that will cause numerical issues with the filter. I would recommend leaving LPE_VIS_XY at 0.1, then you can try LPE_VIS_XY at 0.01, LPE_VIS_XY = 0.001, definitely won't work. Same thing for LPE_VIS_Z. At those levels it will basically always fault as well. If your measurement is ever off from the predicted more than a couple of millimeters it will throw it out, so pay attention to the vision fault messages.