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

fix: sys.canfly variable should start from 'true' until we detect that the USB cable is connected #673

Merged
merged 1 commit into from
Mar 4, 2021

Conversation

ntamas
Copy link
Contributor

@ntamas ntamas commented Jan 22, 2021

The Crazyflie has a neat log variable named sys.canfly that can be used to determine whether the USB cable is connected. Unfortunately, it starts from false and it does not get updated until the state of the power management subsystem changes at least once. The PM state starts from "battery", so in order to make sys.canfly consistent with the detected PM state, it should start from true and not false (as it is now).

This PR tries to be polite and not set sys.canfly to true until the system is started. Once it is started, it sets sys.canfly to true and enters the PM loop immediately; if the USB charger happens to be connected at boot, the first iteration will update sys.canfly to false so this is not a problem.

@whoenig
Copy link
Contributor

whoenig commented Jan 22, 2021

This seems like a great catch, but this also shows that there is another underlying issue: the actions on state-change are not executed if the CF powers up with the battery attached. I am not sure if that is intended or not. If not, another fix would be to add invalid to the PMStates enum and start out in the invalid state for pmStateOld.

@ntamas
Copy link
Contributor Author

ntamas commented Jan 22, 2021

I couldn't decide it either, that's why I went for the surgical solution with the most minimal change I could think of.

Actually, most of the logic related to the PM state switches affects at least three parts of the system (the LED sequences, the sound submodule and the "can fly" state variable), but it seems to be completely independent of the hardware that the Crazyflie is running on, so it should not be in an STM32F4-specific power management module; a better long-time solution for the PM module would be to provide events that other modules can subscribe to and act accordingly when the PM state changes. But this is definitely a larger chunk of work.

@ataffanel
Copy link
Member

I agree that there is much to do for the PM, but this is a nice fix so lets merge it. Thanks!

I have created a ticket to discuss how we want to improve the PM in the future: #718

@ataffanel ataffanel merged commit 54d7cca into bitcraze:master Mar 4, 2021
@ntamas ntamas deleted the fix/canfly-log-var-at-startup branch March 4, 2021 14:42
@jonasdn jonasdn added this to the next-release milestone Mar 17, 2021
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.

4 participants