New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random thrust when no thrust input given and optical flow enabled (but not sending data) [Bug] #23034
Comments
I saw the same thing today. It looks like the thrust setpoint starts dropping even though I have the throttle at center. Local Z position starts diverging, then everything goes nuts. https://review.px4.io/plot_app?log=feaa27ad-73c3-4f2e-a5da-950ee5c1920b |
@mrpollo is there a way to get better visibility on this issue to the community and add it to the list of known blockers for the next release? |
The best way to raise the visibility of an issue is to bring it up for discussion on one of the weekly calls. I have also added this issue to the PX4 Misc project board. |
This is a strange one. Like the fused height estimate is slowly diverging. And I couldn't get it to go into pos mode. Then alt mode would just drop |
This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: |
Hey @bresch can you please take a quick look here? |
It looks like a bug with the altitude estimate diverging when baro is set as the main EKG height source. |
We consistently ran into this today. If you don't try to compensate and increase thrust on the RC, it doesn't result in a 100% thrust. If you try and compensate on the RC it will cause the huge thrust spike. One resulted in a flyaway. https://review.px4.io/plot_app?log=4d0b3cf9-003d-4370-9e7f-b6e5eec17543 It looks like a spike in the baro causes a spike in dist_bottom. This drone only has one baro, why are there two estimator_baro_bias topics with topic 0 only briefly published at the beginning. |
I have even seen this issue with baro enabled in EKF2 but not as the primary height reference. Upon disabling barometer I do not see the issue, however this is not ideal for higher alt flights (outside of rangefinder max range, or range aid conditions not met due to velocity) with spotty GPS |
GPS + baro + RNG Video of the bug from this flight GPS +RNG. Baro control disabled. GPS + Baro. RNG control disabled. Unable to replicate. |
Probably something in this PR? It's really the only thing that's changed and is consistent with the timeline of the bug report @bresch A few weird things I see, maybe you have some insight on what's happening
|
@dakejahl I believe the issue might have been introduced even before February timeframe since I think I remember seeing it 1.14, however would be good to verify. |
Backported my Pi6X to 1.14 I can't replicate release/1.15 branch I am unable to replicate as well |
I haven’t replicated the issue with pure gps + range aid ( no barometer + no optical flow enabled): https://review.px4.io/plot_app?log=370a4be3-5c26-4678-a4e7-40d1c9dd3fa6 This setup has no baro. ark flow onboard but I only use the rangefinder for this particular log. It looks like rangefinder in combo with another hgt ref can be problematic (especially baro, to a lesser degree VIO and GPS) also gps as a height reference seems to make a big difference (maybe less noticeable divergence) |
So the EKF selector is switching between the two estimator local positions causing these big jumps in vehicle_local_position. https://review.px4.io/plot_app?log=8260af89-85f7-454d-b491-ddc022b44719 |
Maybe we're mixing two issues here, but after checking the first log posted here, I don't see anything strange, the VIO data is diverging an pulling the EKF with it. |
@AlexKlimaj Do you have the same issue when flying with a single EKF instance? |
Yes, this is probably a bad example for rangefinder ctrl but highlights that the barometer is useless when VIO “falls”. These height references really need to be reconciled and there needs to be regression testing of height control and optical flow every time EKF code changes are made. |
Hm I did increase EKF2_RNG_DELAY to 105ms based on what I measured. Maybe that explains why the two EKF instances Z's are diverging. |
Reset the baro and rangefinder delay params back to default and its much better. No EKF instance switches. This is on release/1.15 https://review.px4.io/plot_app?log=0939ee41-6143-4401-ba77-5da8b82f0f9b https://review.px4.io/plot_app?log=e5e935be-be4b-49eb-96b2-a98649c1b4f7 |
@dirksavage88 It looks like EKF RNG CTRL is turned off in your log. Try turning it on and resetting the delay and gate params to defaults. |
Describe the bug
On recent main (early April), when optical flow is enabled with EKF2_OF_CTRL but no optical flow or distance sensor is given, while in Position mode the vehicle will experience a surge in thrust that will ignore set-point despite exceeding the thrust set-point given.
To Reproduce
Expected behavior
Despite optical flow sensor/range sensor data not being fed into EKF2, the random thrust occurrence should not happen and thrust setpoints should not be ignored. I have also observed this behavior when range sensor and optical flow is being fused but the rangefinder data fails a condition in the estimator checks (bypassed by setting range fusion to enabled instead of conditional)
Screenshot / Media
Flight Log
https://logs.px4.io/plot_app?log=ca0d60d8-6dc6-4215-86f4-32fa2ad18f71
Software Version
Main 1.15.0 apha
Flight controller
VOXL2
Vehicle type
Multicopter
How are the different components wired up (including port information)
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: