Skip to content

Commit

Permalink
Normalize all the line endings
Browse files Browse the repository at this point in the history
  • Loading branch information
@hydra
hydra committed Sep 15, 2014
1 parent 4237370 commit d60183d
Show file tree
Hide file tree
Showing 396 changed files with 158,300 additions and 158,300 deletions.
34 changes: 17 additions & 17 deletions Notes.md
View file
Original file line number Diff line number Diff line change
@@ -1,17 +1,17 @@
#Notes

## Expected acc/mag/gyro behavior

Observations of a flight-tested flip32 board in the configurator's 'raw sensor data' tab.

lift front of board (i.e. pitch back)
gyro y increases (green)
acc x increases (blue)
acc z decreases (red)
mag x decreases (blue)

lift left of boar (i.e. roll right)
gyro x increases (blue)
acc y increases (green)
mag y decreases (green)
mag z increases (red)
#Notes

## Expected acc/mag/gyro behavior

Observations of a flight-tested flip32 board in the configurator's 'raw sensor data' tab.

lift front of board (i.e. pitch back)
gyro y increases (green)
acc x increases (blue)
acc z decreases (red)
mag x decreases (blue)

lift left of boar (i.e. roll right)
gyro x increases (blue)
acc y increases (green)
mag y decreases (green)
mag z increases (red)
104 changes: 52 additions & 52 deletions docs/Autotune.md
View file
Original file line number Diff line number Diff line change
@@ -1,53 +1,53 @@
# Autotune

Autotune helps to automatically tune your multirotor.

## Configuration.

Autotune only works in HORIZON or ANGLE mode, before using auto-tune it's best you setup so there is as little drift as possible.
Autotuning is best on a full battery in good flying conditions, i.e. no or minimal wind.

Configure a two position switch on your transmitter to activate the AUTOTUNE and HORIZON or ANGLE modes using the auxilary configuration.
You may find a momentary switch more suitable than a toggle switch.


## Using autotuning

Turn off the autotune switch. If the autotune switch is on while not armed the warning LED will flash and you cannot arm.

Launch the multirotor.

Turn on/hold the autotune switch on your transmitter.

Observe roll left/right. A beep code will sound on the beeper.

Turn off/release the switch while still flying to stop this phase of tuning.

PID settings will have been updated for ROLL/YAW.

Turn on/hold the switch again.

Observe pitch forwards/backwards. A beep code will sound on the beeper.

Turn off/release the switch while still flying to stop this phase of tuning.

PID settings will have been updated for PITCH/YAW.

PIDS are updated, fly and see if it's better.

If it's worse, flip the switch again to restore previous pids that were present prior to arming.

Land.

Verify results via an app while power still applied if desired.

Cutting the power will loose the unsaved pids.

If you're happy with the pids then while disarmed flip the autotune switch again to save all settings then flip it back so you can arm again.

A beeper will sound indicating the settings are saved.


# References

# Autotune

Autotune helps to automatically tune your multirotor.

## Configuration.

Autotune only works in HORIZON or ANGLE mode, before using auto-tune it's best you setup so there is as little drift as possible.
Autotuning is best on a full battery in good flying conditions, i.e. no or minimal wind.

Configure a two position switch on your transmitter to activate the AUTOTUNE and HORIZON or ANGLE modes using the auxilary configuration.
You may find a momentary switch more suitable than a toggle switch.


## Using autotuning

Turn off the autotune switch. If the autotune switch is on while not armed the warning LED will flash and you cannot arm.

Launch the multirotor.

Turn on/hold the autotune switch on your transmitter.

Observe roll left/right. A beep code will sound on the beeper.

Turn off/release the switch while still flying to stop this phase of tuning.

PID settings will have been updated for ROLL/YAW.

Turn on/hold the switch again.

Observe pitch forwards/backwards. A beep code will sound on the beeper.

Turn off/release the switch while still flying to stop this phase of tuning.

PID settings will have been updated for PITCH/YAW.

PIDS are updated, fly and see if it's better.

If it's worse, flip the switch again to restore previous pids that were present prior to arming.

Land.

Verify results via an app while power still applied if desired.

Cutting the power will loose the unsaved pids.

If you're happy with the pids then while disarmed flip the autotune switch again to save all settings then flip it back so you can arm again.

A beeper will sound indicating the settings are saved.


# References

* Brad Quick for the initial Autotune algorithm in BradWii.
36 changes: 18 additions & 18 deletions docs/Board - CC3D.md
View file
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
# Board - CC3D

The OpenPilot Copter Control 3D aka CC3D is a board more tuned to Acrobatic flying or GPS based
auto-piloting. It only has one sensor, the MPU6000 SPI based Accelerometer/Gyro.
It also features a 16mbit SPI based EEPROM chip. It has 6 ports labelled as inputs (one pin each)
and 6 ports labelled as motor/servo outputs (3 pins each).

If issues are found with this board please report via the github issue tracker.

# Serial Ports

| Value | Identifier | Board Markings | Notes |
| ----- | ------------ | -------------- | -----------------------------------------|
| 1 | USART1 | MAIN PORT | Has a hardware inverter for SBUS |
| 2 | USART3 | FLEX PORT | |

Software serial is not supported yet due to timer and pin configuration mappings.

# Board - CC3D

The OpenPilot Copter Control 3D aka CC3D is a board more tuned to Acrobatic flying or GPS based
auto-piloting. It only has one sensor, the MPU6000 SPI based Accelerometer/Gyro.
It also features a 16mbit SPI based EEPROM chip. It has 6 ports labelled as inputs (one pin each)
and 6 ports labelled as motor/servo outputs (3 pins each).

If issues are found with this board please report via the github issue tracker.

# Serial Ports

| Value | Identifier | Board Markings | Notes |
| ----- | ------------ | -------------- | -----------------------------------------|
| 1 | USART1 | MAIN PORT | Has a hardware inverter for SBUS |
| 2 | USART3 | FLEX PORT | |

Software serial is not supported yet due to timer and pin configuration mappings.

30 changes: 15 additions & 15 deletions docs/Board - Naze32.md
View file
Original file line number Diff line number Diff line change
@@ -1,15 +1,15 @@
# Board - Naze32

The Naze32 target supports all Naze hardware revisions. Revison 4 and Revision 5 are used and
frequently flown by the primary maintainer. Previous Naze hardware revisions may have issues,
if found please report via the github issue tracker.

# Serial Ports

| Value | Identifier | Board Markings | Notes |
| ----- | ------------ | -------------- | -----------------------------------------|
| 1 | USART1 | RX/TX / TELEM | Also connected to USB port via CP2102 IC |
| 2 | USART2 | RC3/4 | |
| 3 | SoftSerial 1 | RC5/6 | |
| 4 | SoftSerial 2 | RC7/8 | |

# Board - Naze32

The Naze32 target supports all Naze hardware revisions. Revison 4 and Revision 5 are used and
frequently flown by the primary maintainer. Previous Naze hardware revisions may have issues,
if found please report via the github issue tracker.

# Serial Ports

| Value | Identifier | Board Markings | Notes |
| ----- | ------------ | -------------- | -----------------------------------------|
| 1 | USART1 | RX/TX / TELEM | Also connected to USB port via CP2102 IC |
| 2 | USART2 | RC3/4 | |
| 3 | SoftSerial 1 | RC5/6 | |
| 4 | SoftSerial 2 | RC7/8 | |

44 changes: 22 additions & 22 deletions docs/Buzzer.md
View file
Original file line number Diff line number Diff line change
@@ -1,22 +1,22 @@
# Buzzer

Cleanflight supports a buzzer which is used for the following purposes, and more:

Low Battery alarm (when battery monitoring enabled)
Notification of calibration complete status.
AUX operated beeping - useful for locating your aircraft after a crash.
Failsafe status.

Buzzer is enabled by default on platforms that have buzzer connections.

## Types of buzzer supported

The buzzers are enabled/disabled by simply enabling or disabling a GPIO output pin on the board.
This means the buzzer must be able to generate it's own tone simply by having power applied to it.

Buzzers that need an analogue or PWM signal do not work and will make clicking noises or no sound at all.

Example of a known-working buzzer.

http://www.rapidonline.com/Audio-Visual/Hcm1205x-Miniature-Buzzer-5v-35-0055

# Buzzer

Cleanflight supports a buzzer which is used for the following purposes, and more:

Low Battery alarm (when battery monitoring enabled)
Notification of calibration complete status.
AUX operated beeping - useful for locating your aircraft after a crash.
Failsafe status.

Buzzer is enabled by default on platforms that have buzzer connections.

## Types of buzzer supported

The buzzers are enabled/disabled by simply enabling or disabling a GPIO output pin on the board.
This means the buzzer must be able to generate it's own tone simply by having power applied to it.

Buzzers that need an analogue or PWM signal do not work and will make clicking noises or no sound at all.

Example of a known-working buzzer.

http://www.rapidonline.com/Audio-Visual/Hcm1205x-Miniature-Buzzer-5v-35-0055

138 changes: 69 additions & 69 deletions docs/Development.md
View file
Original file line number Diff line number Diff line change
@@ -1,69 +1,69 @@
#Development

This document is primarily for developers only.

##Unit testing

Ideally, there should be tests for any new code. However, since this is a legacy codebase which was not designed to be tested this might be a bit difficult.

If you want to make changes and want to make sure it's tested then focus on the minimal set of changes required to add a test.

Tests currently live in the `test` folder and they use the google test framework.
The tests are compiled and run natively on your development machine and not on the target platform.
This allows you to develop tests and code and actually execute it to make sure it works without needing a development board or simulator.

This project could really do with some functional tests which test the behaviour of the application.

All pull requests to add/improve the testability of the code or testing methods are highly sought!

##General principals

1. Name everything well.
2. Strike a balance between simplicity and not-repeating code.
3. Methods that return a boolean should be named as a question, and should not change state. e.g. 'isOkToArm()'
4. Methods that start with the word 'find' can return a null, methods that start with 'get' should not.
5. Methods should have verb or verb-phrase names, like `deletePage` or `save`. Variables should not, they generally should be nouns. Tell the system to 'do' something 'with' something. e.g. deleteAllPages(pageList).
6. Keep methods short - it makes it easier to test.
7. Don't be afraid of moving code to a new file - it helps to reduce test dependencies.
8. Avoid noise-words in variable names, like 'data' or 'info'. Think about what you're naming and name it well. Don't be afraid to rename anything.
9. Avoid comments taht describe what the code is doing, the code should describe itself. Comments are useful however for big-picture purposes and to document content of variables.
10. If you need to document a variable do it at the declarion, don't copy the comment to the `extern` usage since it will lead to comment rot.
11. Seek advice from other developers - know you can always learn more.
12. Be professional - attempts at humor or slating existing code in the codebase itself is not helpful when you have to change/fix it.
13. Know that there's always more than one way to do something and that code is never final - but it does have to work.

###Running the tests.

The tests and test build system is very simple and based of the googletest example files, it will be improved in due course.

```
cd test
make
```

This will build a set of executable files, one for each `*_unittest.cc` file.

You can run them on the command line to execute the tests and to see the test report.

You can also step-debug the tests in eclipse and you can use the GoogleTest test runner to make building and re-running the tests simple.

The tests are currently always compiled with debugging information enabled, there may be additional warnings, if you see any warnings please attempt to fix them and submit pull requests with the fixes.


##TODO

* Test OpenLRSNG's RSSI PWM on AUX5-8.
* Add support for UART3/4 on STM32F3.
* Cleanup validateAndFixConfig and pwm_mapping.c to use some kind of feature/timer/io pin mapping to remove #ifdef
* Split RX config into RC config and RX config.
* Enabling/disabling features should not take effect until reboot since. Main loop executes and uses new flags as they are set in the cli but
appropriate init methods will not have been called which results in undefined behaviour and could damage connected devices - this is a legacy
problem from baseflight.
* Solve all the naze rev4/5 HSE_VALUE == 8000000/1200000 checking, the checks should only apply to the naze32 target. See system_stm32f10x.c/SetSysClock().

##Known Issues

* Softserial RX on STM32F3 does not work. TX is fine.
* Dynamic throttle PID does not work with new pid controller.
* Autotune does not work yet with with new pid controller.

#Development

This document is primarily for developers only.

##Unit testing

Ideally, there should be tests for any new code. However, since this is a legacy codebase which was not designed to be tested this might be a bit difficult.

If you want to make changes and want to make sure it's tested then focus on the minimal set of changes required to add a test.

Tests currently live in the `test` folder and they use the google test framework.
The tests are compiled and run natively on your development machine and not on the target platform.
This allows you to develop tests and code and actually execute it to make sure it works without needing a development board or simulator.

This project could really do with some functional tests which test the behaviour of the application.

All pull requests to add/improve the testability of the code or testing methods are highly sought!

##General principals

1. Name everything well.
2. Strike a balance between simplicity and not-repeating code.
3. Methods that return a boolean should be named as a question, and should not change state. e.g. 'isOkToArm()'
4. Methods that start with the word 'find' can return a null, methods that start with 'get' should not.
5. Methods should have verb or verb-phrase names, like `deletePage` or `save`. Variables should not, they generally should be nouns. Tell the system to 'do' something 'with' something. e.g. deleteAllPages(pageList).
6. Keep methods short - it makes it easier to test.
7. Don't be afraid of moving code to a new file - it helps to reduce test dependencies.
8. Avoid noise-words in variable names, like 'data' or 'info'. Think about what you're naming and name it well. Don't be afraid to rename anything.
9. Avoid comments taht describe what the code is doing, the code should describe itself. Comments are useful however for big-picture purposes and to document content of variables.
10. If you need to document a variable do it at the declarion, don't copy the comment to the `extern` usage since it will lead to comment rot.
11. Seek advice from other developers - know you can always learn more.
12. Be professional - attempts at humor or slating existing code in the codebase itself is not helpful when you have to change/fix it.
13. Know that there's always more than one way to do something and that code is never final - but it does have to work.

###Running the tests.

The tests and test build system is very simple and based of the googletest example files, it will be improved in due course.

```
cd test
make
```

This will build a set of executable files, one for each `*_unittest.cc` file.

You can run them on the command line to execute the tests and to see the test report.

You can also step-debug the tests in eclipse and you can use the GoogleTest test runner to make building and re-running the tests simple.

The tests are currently always compiled with debugging information enabled, there may be additional warnings, if you see any warnings please attempt to fix them and submit pull requests with the fixes.


##TODO

* Test OpenLRSNG's RSSI PWM on AUX5-8.
* Add support for UART3/4 on STM32F3.
* Cleanup validateAndFixConfig and pwm_mapping.c to use some kind of feature/timer/io pin mapping to remove #ifdef
* Split RX config into RC config and RX config.
* Enabling/disabling features should not take effect until reboot since. Main loop executes and uses new flags as they are set in the cli but
appropriate init methods will not have been called which results in undefined behaviour and could damage connected devices - this is a legacy
problem from baseflight.
* Solve all the naze rev4/5 HSE_VALUE == 8000000/1200000 checking, the checks should only apply to the naze32 target. See system_stm32f10x.c/SetSysClock().

##Known Issues

* Softserial RX on STM32F3 does not work. TX is fine.
* Dynamic throttle PID does not work with new pid controller.
* Autotune does not work yet with with new pid controller.

Loading

0 comments on commit d60183d

Please sign in to comment.