d6c1ce323d
The old code was using f.ACC_CALIBRATED to mean 'flash the warning led' and 'prevent arming' There was another flag called f.OK_TO_ARM which really meant 'prevent arming after failsafe unless using a switch to arm' - this meant the comment in the code was incorrect since it did not mention the switch. There was code which every ~71 minutes would set f.ACC_CALIBRATED to FALSE and would toggle the LED, even when flying. There was code that was run during every cycle that did not need to be run when armed. There was code that was run during every cycle which did not need to be run when waiting for calibration to finish. The warning light was toggled regardless of actual accelerometer calibration state. This commit fixes all that and prevents the user from arming after a failsafe landing until the system is reset, regardless of wether a switch is used to arm or not. This commit also flashes the warning led during barometer calibration and will not let you arm until it has completed. Add a 5 second delay on startup to failsafe to prevent failsafe from activating in the case of TX/RX gear with long bind procedures before they send out valid data. Failsafe now only prevents re-arming if a landing was forced. In the case when you power on your RX without your TX on the beeper sounds and failsafe warning ligts are activated. When the FC then detects a signal the lights go off and you can then arm. |
||
|---|---|---|
| docs | ||
| lib | ||
| obj | ||
| src | ||
| support | ||
| targets/ChebuzzF3 | ||
| test | ||
| .gitignore | ||
| baseflight.uvproj | ||
| JLinkSettings.ini | ||
| Makefile | ||
| README.md | ||
| startup_stm32f30x_md_gcc.s | ||
| stm32_flash_f103.ld | ||
| stm32_flash_f303.ld | ||
Cleanflight
Clean-code version of baseflight flight-controller - flight controllers are used to fly multi-rotor craft and fixed wing craft.
This fork differs from baseflight in that it attempts to use modern software development practices which result in:
- greater reliability through code robustness.
- easier maintainance through code cleanliness.
- easier to develop new features.
- easier to re-use code though code de-coupling and modularisation.
The MultiWii software, from which baseflight originated, violates many good software development best-practices. Hopefully this fork will go some way to address them. If you see any bad code in this fork please immediately raise an issue so it can be fixed, or better yet submit a pull request.
Documentation
There is some documentation here: https://github.com/hydra/cleanflight/tree/master/docs If what you need is not covered then refer to the baseflight documentation. If you still can't find what you need then stop by #multiwii on the Freenode IRC network - irc://irc.freenode.net/#multiwii
Contributing
Before making any contributions, take a note of the https://github.com/multiwii/baseflight/wiki/CodingStyle
For this fork it is also advised to read about clean code, here are some useful links: