Skip to content
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

increase NUM_NO_REPLY_UNTIL_UNRESPONSIVE to 6 #24250

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bdilman
Copy link
Contributor

@bdilman bdilman commented Jan 23, 2025

Solved Problem

To make sure latency or other issues between the FMU and the mission computer do not cause a mode registration problem, number of no replies to raise the mode unresponsive flag is increased to 6. This change is added after observing mission computer latency issues due to overheating and increasing this value relatively increased the chance of successful mode registrations.

Fixes #{Github issue ID}

Solution

  • Mode unresponsive flag counter NUM_NO_REPLY_UNTIL_UNRESPONSIVE is increased from 3 to 6.

Changelog Entry

For release notes:

Feature/Bugfix XYZ
New parameter: XYZ_Z
Documentation: Need to clarify page ... / done, read docs.px4.io/...

Alternatives

By enabling mode registration while armed, an unresponsive mode can be re-registered and any undesired mode unresponsive flag can be resolved. Please see, #24249

Test coverage

Context

Related links, screenshot before/after, video

@bdilman bdilman requested review from bkueng and sfuhrer January 23, 2025 18:01
@bkueng
Copy link
Member

bkueng commented Jan 24, 2025

If you experience timeouts during mode registration, you have to increase NUM_NO_REPLY_UNTIL_UNRESPONSIVE_INIT instead. Did you run into this with a version that includes 4883f21?
Can you provide the relevant app and PX4 output when it happens? Is your app by chance blocking the main thread for a while?
I'm not against increasing if necessary, but want to make sure there's sufficient data to support that.

@bdilman
Copy link
Contributor Author

bdilman commented Jan 24, 2025

If you experience timeouts during mode registration, you have to increase NUM_NO_REPLY_UNTIL_UNRESPONSIVE_INIT instead.
Thank you for the pointer, this is really good to know in case registration issue occur again. I will check archived flight logs to check the registration fail reason from back then (main effective solution was on the hardware side and therefore we can even close this PR draft.

Did you run into this with a version that includes 4883f21?
No, initial change was done while using an older version. I will go through previous logs and update here to be able provide relevant data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants