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

Commander : Effectively track failure reporting and handle hotplug sensors #3171

Merged
merged 1 commit into from
Nov 14, 2015

Conversation

mhkabir
Copy link
Member

@mhkabir mhkabir commented Nov 10, 2015

Now commander will report all issues when a new link is connected. So no messages are lost.
:) Also, with my changes, it will now wait in ARMING_STATE_INIT till all primary sensors come online.

This will need some careful review, but I'm confident this works 100% as tested. Please let me know what else is needed.

New output when link first connects (hotplug sensor not up yet though) :

[20:14:12.645 - COMP:1] Info: new data link connected #0
[20:14:12.861 - COMP:1] Critical: warning: primary compass not operational
[20:14:12.964 - COMP:1] Critical: Not ready to fly: Flying with USB connected prohibited
[20:14:13.068 - COMP:1] Critical: Not ready to fly: Sensors need inspection

@mhkabir mhkabir changed the title Commander : track failure reporting Commander : Effectively track failure reporting and handle hotplug sensors Nov 10, 2015
@mhkabir
Copy link
Member Author

mhkabir commented Nov 10, 2015

Note to self : Figure out a way to flag external/hotplug sensors during calibration, and not play annoying error tune right at boot before it has come up.
Suggestions, Lorenz?

@LorenzMeier
Copy link
Member

I would propose to not warn for the first two seconds. After that it's unlikely a sensor will still show up without user intervention. So the first two seconds after boot it should just flag the system as by ready, but not warn via MAVLink or buzzer.

@mhkabir
Copy link
Member Author

mhkabir commented Nov 10, 2015

Implemented. Works perfectly. We don't warn the user for upto 4 seconds after booting (this value was the minimum required one, tested with UAVCAN mag)

@LorenzMeier
Copy link
Member

Awesome work! Just going through it now.

@mhkabir mhkabir force-pushed the commander_prearm branch 2 times, most recently from 60d01ee to 3c5bbdc Compare November 11, 2015 03:46
@mhkabir
Copy link
Member Author

mhkabir commented Nov 11, 2015

OK, I just added some user experience tweaks to warn the user later if sensors fail, etc. This feels very polished now.

Timeout is set to 5 seconds, which works fine with USB, but on battery, with the faster boot, and UAVCAN sensors ridiculously taking around 8-9 seconds (after commander starts) to come up, the system starts warning before the sensors come up.

@LorenzMeier
Copy link
Member

Hard to tell why it's different on battery without sitting in front of the system. Have you pinged @pavel-kirienko to see why it takes so long to enumerate?

@mhkabir
Copy link
Member Author

mhkabir commented Nov 11, 2015

Ok, so I fixed the remaining small user-experience issues, other than the long enumeration times. The system works exactly as expected now, and warns perfectly in every condition. I checked with all sorts of combinations - bad calibrations, mag unplugged/plugged, uavcan enabled/disabled etc. and it works great!

Timeout is set to 8 seconds till Pavel can provide us with faster enumeration times. System won't warn till 8 seconds are over -- but it will still refuse to go to STANDBY silently. But we really need to make sensor enumeration faster. Even with 8 seconds, warnings trigger sometimes. This will vary from system-to-system as well, depending on startup times.

I also added a small differentiation between pre-arm and pre-flight. USB power is only checked if we are doing a pre-arm check, not for pre-flight (as in bench tests or otherwise) This can be expanded later to encompass more system checks.

@mhkabir mhkabir force-pushed the commander_prearm branch 4 times, most recently from 61a1b9a to 204fdbb Compare November 11, 2015 10:16
@mhkabir
Copy link
Member Author

mhkabir commented Nov 12, 2015

@LorenzMeier Could you please give a high-level review of this meanwhile ? Does everything look OK, or does anything need more re-factoring/optimization?

@LorenzMeier
Copy link
Member

This looks really good. I will cross-test and get this in tomorrow.

LorenzMeier added a commit that referenced this pull request Nov 14, 2015
Commander : Effectively track failure reporting and handle hotplug sensors
@LorenzMeier LorenzMeier merged commit 32bbbb0 into PX4:master Nov 14, 2015
@mhkabir mhkabir deleted the commander_prearm branch November 14, 2015 15:25
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