Mirror/betaflight
1
0
Fork 0
mirror of https://github.com/betaflight/betaflight.git synced 2025-07-14 20:10:18 +03:00
Code Issues Wiki Activity

Merge remote-tracking branch 'upstream/master'

Browse source
This commit is contained in:
Pim van Pelt 2015-01-12 22:06:56 +01:00
commit b261f1a46e
57 changed files with 2382 additions and 199 deletions
Download patch file Download diff file Expand all files Collapse all files

5
docs/Autotune.md
View file

@ -5,9 +5,10 @@ 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.
Autotuning is best on a full battery in good flying conditions, i.e. no or minimal wind. Autotune does not support
pid_controller 2 (pid_controller 0 is the Cleanflight default).
Configure a two position switch on your transmitter to activate the AUTOTUNE and (HORIZON or ANGLE) modes using the auxilary configuration.
Configure a two position switch on your transmitter to activate the AUTOTUNE and (HORIZON or ANGLE) modes using the auxiliary configuration.
You may find a momentary switch more suitable than a toggle switch.

5
docs/Battery.md
View file

@ -47,6 +47,8 @@ Configure min/max cell voltages using the following CLI setting:
`vbat_max_cell_voltage` - maximum voltage per cell, used for auto-detecting battery voltage in 0.1V units, i.e. 43 = 4.3V
`set vbat_warning_cell_voltage` - warning voltage per cell, this triggers battery out alarms, in 0.1V units, i.e. 34 = 3.4V
`vbat_min_cell_voltage` - minimum voltage per cell, this triggers battery out alarms, in 0.1V units, i.e. 33 = 3.3V
e.g.
@ -54,6 +56,7 @@ e.g.
```
set vbat_scale = 110
set vbat_max_cell_voltage = 43
set vbat_warning_cell_voltage = 34
set vbat_min_cell_voltage = 33
```
@ -75,7 +78,7 @@ Configure capacity using the `battery_capacity` setting, which takes a value in
The current meter may need to be configured so that the value read at the ADC input matches actual current draw. Just like you need a voltmeter to correctly calibrate your voltage reading you also need an ammeter to calibrate your current sensor.
Use the following settings to adjust calibrtion.
Use the following settings to adjust calibration.
`current_meter_scale`
`current_meter_offset`

185
docs/Blackbox.md Normal file
View file

@ -0,0 +1,185 @@
# Blackbox flight data recorder
![Rendered flight log frame](Screenshots/blackbox-screenshot-1.jpg)
## Introduction
This feature transmits your flight data information on every control loop iteration over a serial port to an external
logging device to be recorded.
After your flight, you can process the resulting logs on your computer to either turn them into CSV (comma-separated
values) or render your flight log as a video using the tools `blackbox_decode` and `blackbox_render`. Those tools can be
found in this repository:
https://github.com/cleanflight/blackbox-tools
You can also view your flight logs using your web browser with the interactive log viewer:
https://github.com/cleanflight/blackbox-log-viewer
## Logged data
The blackbox records flight data on every iteration of the flight control loop. It records the current time in
microseconds, P, I and D corrections for each axis, your RC command stick positions (after applying expo curves),
gyroscope data, accelerometer data (after your configured low-pass filtering), barometer readings, 3-axis magnetometer
readings, raw VBAT measurements, and the command being sent to each motor speed controller. This is all stored without
any approximation or loss of precision, so even quite subtle problems should be detectable from the fight data log.
Currently, the blackbox attempts to log GPS data whenever new GPS data is available, but this has not been tested yet.
The CSV decoder and video renderer do not yet show any of the GPS data (though this will be added). If you have a working
GPS, please send in your logs so I can get the decoding implemented.
The data rate for my quadcopter using a looptime of 2400 is about 10.25kB/s. This allows about 18 days of flight logs
to fit on a 16GB MicroSD card, which ought to be enough for anybody :).
## Supported configurations
The maximum data rate for the flight log is fairly restricted, so anything that increases the load can cause the flight
log to drop frames and contain errors.
The Blackbox was developed and tested on a quadcopter. It has also been tested on a tricopter. It should work on
hexacopters or octocopters, but as they transmit more information to the flight log (due to having more motors), the
number of dropped frames may increase. The `blackbox_render` tool only supports tri and quadcopters (please send me
flight logs from other craft, and I can add support for them!)
Cleanflight's `looptime` setting will decide how many times per second an update is saved to the flight log. The
software was developed on a craft with a looptime of 2400. Any looptime smaller than this will put more strain on the
data rate. The default looptime on Cleanflight is 3500. If you're using a looptime of 2000 or smaller, you will probably
need to reduce the sampling rate in the Blackbox settings, see the later section on configuring the Blackbox feature for
details.
## Hardware
The blackbox software is designed to be used with an [OpenLog serial data logger][] and a microSDHC card. You need a
little prep to get the OpenLog ready for use, so here are the details:
### Firmware
The OpenLog ships with standard OpenLog 3 firmware installed. However, in order to reduce the number of dropped frames,
it should be reflashed with the [OpenLog Light firmware][] or the special [OpenLog Blackbox firmware][] . The Blackbox
variant of the firmware ensures that the OpenLog is running at the correct baud-rate and does away for the need for a
`CONFIG.TXT` file to set up the OpenLog.
You can find the Blackbox version of the OpenLog firmware [here](https://github.com/cleanflight/blackbox-firmware),
along with instructions for installing it onto your OpenLog.
[OpenLog serial data logger]: https://www.sparkfun.com/products/9530
[OpenLog Light firmware]: https://github.com/sparkfun/OpenLog/tree/master/firmware/OpenLog_v3_Light
[OpenLog Blackbox firmware]: https://github.com/cleanflight/blackbox-firmware
### microSDHC
Your choice of microSDHC card is very important to the performance of the system. The OpenLog relies on being able to
make many small writes to the card with minimal delay, which not every card is good at. A faster SD-card speed rating is
not a guarantee of better performance.
#### microSDHC cards known to have poor performance
- Generic 4GB Class 4 microSDHC card - the rate of missing frames is about 1%, and is concentrated around the most
interesting parts of the log!
#### microSDHC cards known to have good performance
- Transcend 16GB Class 10 UHS-I microSDHC (typical error rate < 0.1%)
- Sandisk Extreme 16GB Class 10 UHS-I microSDHC (typical error rate < 0.1%)
You should format any card you use with the [SD Association's special formatting tool][] , as it will give the OpenLog
the best chance of writing at high speed. You must format it with either FAT, or with FAT32 (recommended).
[SD Association's special formatting tool]: https://www.sdcard.org/downloads/formatter_4/
### OpenLog configuration
This section applies only if you are using the OpenLog or OpenLog Light original firmware on the OpenLog. If you flashed
it with the special OpenLog Blackbox firmware, you don't need to configure it further.
Power up the OpenLog with a microSD card inside, wait 10 seconds or so, then power it down and plug the microSD card
into your computer. You should find a "CONFIG.TXT" file on the card. Edit it in a text editor to set the first number
(baud) to 115200. Set esc# to 0, mode to 0, and echo to 0. Save the file and put the card back into your OpenLog, it
should use those settings from now on.
If your OpenLog didn't write a CONFIG.TXT file, create a CONFIG.TXT file with these contents and store it in the root
of the MicroSD card:
```
115200,26,0,0,1,0,1
baud,escape,esc#,mode,verb,echo,ignoreRX
```
## Enabling this feature (CLI)
Enable the Blackbox feature by typing in `feature BLACKBOX` and pressing enter. You also need to assign the Blackbox to
one of [your serial ports][] . A 115200 baud port is required (such as serial_port_1 on the Naze32, the two-pin Tx/Rx
header in the center of the board).
For example, use `set serial_port_1_scenario=11` to switch the main serial port to MSP, CLI, Blackbox and GPS Passthrough.
Enter `save`. Your configuration should be saved and the flight controller will reboot. You're ready to go!
[your serial ports]: https://github.com/cleanflight/cleanflight/blob/master/docs/Serial.md
[Cleanflight Configurator]: https://chrome.google.com/webstore/detail/cleanflight-configurator/enacoimjcgeinfnnnpajinjgmkahmfgb?hl=en
## Configuring this feature
The Blackbox currently provides two settings (`blackbox_rate_num` and `blackbox_rate_denom`) that allow you to control
the rate at which data is logged. These two together form a fraction (`blackbox_rate_num / blackbox_rate_denom`) which
decides what portion of the flight controller's control loop iterations should be logged. The default is 1/1 which logs
every iteration.
If you are using a short looptime like 2000 or faster, or you're using a slower MicroSD card, you will need to reduce
this rate to reduce the number of corrupted logged frames. A rate of 1/2 is likely to work for most craft.
You can change these settings by entering the CLI tab in the Cleanflight Configurator and using the `set` command, like so:
```
set blackbox_rate_num = 1
set blackbox_rate_denom = 2
```
### Serial port
Connect the "TX" pin of the serial port you've chosen to the OpenLog's "RXI" pin. Don't connect the serial port's RX
pin to the OpenLog.
### Protection
The OpenLog can be wrapped in black electrical tape or heat-shrink in order to insulate it from conductive frames (like
carbon fiber), but this makes its status LEDs impossible to see. I recommend wrapping it with some clear heatshrink
tubing instead.
![OpenLog installed](Wiring/blackbox-installation-1.jpg "OpenLog installed with double-sided tape, SDCard slot pointing outward")
## Usage
The Blackbox starts recording data as soon as you arm your craft, and stops when you disarm. Each time the OpenLog is
power-cycled, it begins a fresh new log file. If you arm and disarm several times without cycling the power (recording
several flights), those logs will be combined together into one file. The command line tools will ask you to pick which
one of these flights you want to display/decode.
If your craft has a buzzer attached, a short beep will be played when you arm. You can later use this beep to
synchronize your recorded flight video with the rendered flight data log (the beep is shown as a blue line in the flight
data log, which you can sync against the beep in your recorded audio track).
The OpenLog requires a couple of seconds of delay after connecting the battery before it's ready to record, so don't
arm your craft immediately after connecting the battery (you'll probably be waiting for the flight controller to become
ready during that time anyway!)
You should also wait a few seconds after disarming the quad to allow the OpenLog to finish saving its data.
Don't insert or remove the SD card while the OpenLog is powered up.
## Converting logs to CSV or PNG
After your flights, you'll have a series of files labeled "LOG00001.TXT" etc. on the microSD card. You'll need to
decode these with the `blackbox_decode` tool to create a CSV (comma-separated values) file for analysis, or render them
into a series of PNG frames with `blackbox_render` tool, which you could then convert into a video using another
software package.
You'll find those tools along with instructions for using them in this repository:
https://github.com/cleanflight/blackbox-tools
You can also view your .TXT flight log files interactively using your web browser with the Cleanflight Blackbox Explorer
tool:
https://github.com/cleanflight/blackbox-log-viewer
This allows you to scroll around a graphed version of your log and examine your log in detail.

34
docs/Board - CJMCU.md
View file

@ -9,8 +9,8 @@ This board does not have an onboard USB-Serial converter, so an external adapter
| Revision | Notes |
| -------- | ----- |
| 1 | no boot jumper at the edge of the board. |
| 2 | identified by no boot jumper pads at the edge of the board. |
| 1 | No boot jumper pads by LED1. Uses blue and red LEDs |
| 2 | Boot jumper pads presoldered with pins and a jumper by LED1. Uses green and red LEDs. |
Version 2 boards are supported from firmware v1.4.0 onwards, do NOT flash earlier versions to version 2 boards.
@ -24,9 +24,11 @@ Version 2 boards are supported from firmware v1.4.0 onwards, do NOT flash earlie
| PA1 | RC Channel 2 |
| PA2 | RC Channel 3 / USART2 TX |
| PA3 | RC Channel 4 / USART2 RX |
| VCC | Power +3.3v |
| VCC | Power (See note) |
| GND | Ground |
NOTE: The VCC RX Pin is not regulated and will supply what ever voltage is provided to the board, this will mean it'll provide 5v if a 5v serial connection is used. Be careful if you are using a voltage sensitive RX. A regulated 3.3v supply can be found on the top pin of column 1, just below the RX GND pin.
## Serial Connections
USART1 (along with power) is on the following pins.
@ -108,10 +110,32 @@ To flash the board:
* Click "Flash Firmware"
* You should see "Programming: SUCCESSFUL" in the log box
* Click "Connect" -> This should open the "Initial Setup" tab and you should see sensor data from the quad shown
* Unplug the quad and solder across the 2 "BOOT0" pins - This prevents the board from going into bootloader mode on next
boot, if anything goes wrong, simply unsolder these pins and the bootloader will start, allowing you to reflash. You cannot
* Unplug the quad and short the 2 "BOOT0" pins. Revision 1 boards require this to be soldered, revision 2 boards can connect the included jumper to the two pre-soldered pins - This prevents the board from going into bootloader mode on next
boot, if anything goes wrong, simply disconnect these two pins and the bootloader will start, allowing you to reflash. You cannot
overwrite the bootloader.
# Charging
The CJMCU has on it a TP4056 Lithium battery charging IC that can charge a 1S battery at 1A using a provided 5v supply attached to the 5v serial pin.
To charge an attached battery:
* Set the power switch to OFF
* Set the charge switch to CHG
* Plug in a 1S battery to the battery pins
* Plug in a 5v supply to the 5v serial pins
The charger will finish when either the battery reaches 4.2v, or the battery's voltage is greater than the charger's input voltage.
The two nearby LEDs will show the status of charging:
| Status | Green LED | Red LED |
|--------------------|-----------|-----------|
| Charging | On | Off |
| Finished | Off | On |
| 5v not connected | Off | Off |
| Batt not connected | Flashing | On |
# Helpful Hints
* If you are only using a 4 channel RX, in the auxiliary configuration tab, you can add a "Horizon" mode range around 1500

95
docs/Board - ChebuzzF3.md Normal file
View file

@ -0,0 +1,95 @@
# Board - ChebuzzF3
The ChebuzzF3 is a daugter board which connects to the bottom of an STM32F3Discovery board and provides pin headers and ports for various FC connections.
All connections were traced using a multimeter and then verified against the TauLabs source code using the revision linked.
https://github.com/TauLabs/TauLabs/blob/816760dec2a20db7fb9ec1a505add240e696c31f/flight/targets/flyingf3/board-info/board_hw_defs.c
## Connections
Board orientation.
These notes assume that when the board is placed with the header pins facing up, the bottom right of the board is next to the 8 sets of INPUT pin headers.
Inner means between the two rows of header sockets, outer means between the left/right board edges and the header sockets.
### SPI2 / External SPI
sclk GPIOB 13
miso GPIOB 14
mosi GPIOB 15
There are 4 pins, labelled CS1-4 next to a label that reads Ext SPI. The 3rd pin is connected to the flash chip on
the bottom right inner of the board. The other pins on the flash chip are wired up to PB3/4/5
### SPI3 / SPI
sclk GPIOB 3
miso GPIOB 4
mosi GPIOB 5
ssel 1 GPIOB 10 / Ext SPI CS1
ssel 2 GPIOB 11 / Ext SPI CS2
ssel 3 GPIOB 12 / Ext SPI CS3 - wired up to Slave Select of M25P16 15MBitFlash chip
ssel 4 GPIOB 13 / Ext SPI CS4 - not usable since it is used for SPI2 sclk
### RC Input
INPUT
PA8 / CH1 - TIM1_CH1
PB8 / CH2 - TIM16_CH1
PB9 / CH3 - TIM17_CH1
PC6 / CH4 - TIM8_CH1
PC7 / CH5 - TIM8_CH2
PC8 / CH6 - TIM8_CH3
PF9 / CH7 - TIM15_CH1
PF10 / CH8 - TIM15_CH2
### PWM Outputs
OUTPUT
PD12 / CH1 - TIM4_CH1
PD13 / CH2 - TIM4_CH2
PD14 / CH3 - TIM4_CH3
PD15 / CH4 - TIM4_CH4
PA1 / CH5 - TIM2_CH2
PA2 / CH6 - TIM2_CH3
PA3 / CH7 - TIM2_CH4
PB0 / CH8 - TIM3_CH3
PB1 / CH9 - TIM3_CH4
PA4 / CH10 - TIM3_CH2
### Other ports
There is space for a MS5611 pressure sensor at the top left inner of the board.
There is an I2C socket on the left outer of the board which connects to a PCA9306 I2C level shifter directly opposite (inner).
The PCA9306 is not populated on some boards and thus the I2C socket is unusable.
There is a CAN socket on the top right outer of the board which connects to a MAX3015 CAN Tranceiver.
The MAX3015 is not populated on some boards and thus the CAN socket is unusable.
There are some solder pads labelled Ext 1-4 at the top right inner of the board.
GPIOE 6 / PE6 / Ext 1
GPIOD 3 / PD3 / Ext 2
GPIOD 4 / PD4 / Ext 3
GPIOB 3 / PB3 / Ext 4
There are some solder pads labelled ADC0-3 & Diff Press at the top left inner of the board
They are connected to the ADC socket at the top left outer of the board
PC3 / Diff Press - ADC12_IN9 (Differential Pressure)
PC2 / ADC2 - ADC12_IN8
PC1 / ADC1 - ADC12_IN7
PC0 / ADC0 - ADC12_IN6
There is space for a MPXV5004/MPVZ5004 differential pressure sensor, if populated it's analog pin connects to PC3.
There are sockets for 5 UARTs labelled USART1-5.
There is a socket labelled RX_IN.
GPIOD 2 / PD2 / RX_IN

168
docs/Board - Olimexino.md Normal file
View file

@ -0,0 +1,168 @@
# Board - Olimexino
The Olimexino is a cheap and widely available development board
This board is not recommended for cleanflight development because many of the pins needed are not broken out to header pins. A better choice for development is the Port103R, EUSTM32F103RB (F1) or the STM32F3Discovery (F3).
## Connections
### RC Input
INPUT
PA0 CH1 - D2 - PWM1 / PPM
PA1 CH2 - D3 - PWM2 / PWM RSSI
PA2 CH3 - D1 - PWM3 / UART2 TX
PA3 CH4 - D0 - PWM4 / UART2 RX
PA6 CH5 - D12 - PWM5 / SOFTSERIAL1 RX
PA7 CH6 - D11 - PWM6 / SOFTSERIAL1 TX
PB0 CH7 - D27 - PWM7 / SOFTSERIAL2 RX
PB1 CH8 - D28 - PWM8 / SOFTSERIAL2 TX
### PWM Output
OUTPUT
PA8 CH1 - PWM9 - D6
PA11 CH2 - PWM10 - USBDM
PB6 CH3 - PWM11 - D5
PB7 CH4 - PWM12 - D9
PB8 CH5 - PWM13 - D14
PB9 CH6 - PWM14 - D24
## Olimexino Shield V1
Headers for a CP2102 for UART1
Top left
6 way header pinouts (left to right)
1 - N/C
2 - N/C
3 - N/C
4 - D7 - UART1 TX / CP2102 RX
5 - D8 - UART1 RX / CP2102 TX
6 - GND
Headers for PPM, RSSI, SoftSerial1 inputs and Motor outputs
Top centre
Top Row = GROUND
Middle Row = 5V
Bottom Row = Signals
Signal pinouts (left to right)
1 - D2 - PWM1 - PPM
2 - D3 - PWM2 - RSSI
3 - D11 - PWM6 - INPUT CH6 / SS1 TX
4 - D12 - PWM5 - INPUT CH5 / SS1 RX
5 - D5 - PWM11 - OUTPUT CH3
6 - D9 - PWM12 - OUTPUT CH4
7 - D14 - PWM13 - OUTPUT CH5
8 - D24 - PWM14 - OUTPUT CH6
SoftSerial 1 - Headers for FTDI
Top Right
6 way header pinouts (left to right)
1 - N/C
2 - D11 - SS1 or UART2 TX / FTDI RX
3 - D12 - SS1 or UART2 RX / FTDI TX
4 - N/C
5 - N/C
6 - GND
Top Right
3 way power selector header
1 - VIN
2 - 5V from FTDI
3 - N/C - Jumper Storage
Middle Left
3 way power selector header
1 - VIN
2 - 5V from CP2102
3 - N/C - Jumper Storage
Use either power selector to supply VIN from the serial port adapter sockets, ensure that both power selectors are not enabled at the same time.
One or both of the power selector jumpers MUST be in the jumper storage position.
Sonar
Inner Middle Bottom Right
4 Header pins (top to bottom)
1 - VIN
2 - Trigger
3 - Echo
4 - GND
Serial IO & Serial Loopback
Bottom right
The header pins allows combinations of serial loopback and Serial IO. Any amount of connections or jumpers can be used at the same time.
Jumper positions
>< = Horizontal jumper
v = Vertical jumper
^
><- FTDI RX connected to SS1 TX
><- FTDI TX connected to SS1 RX
->< FTDI RX connected to UART2 TX
->< FTDI TX connected to UART2 RX
-v- FTDI LOOPBACK
-^-
v-- SS1 LOOPBACK
^--
--v UART2 LOOPBACK
--^
6 way header pinouts (top left to bottom right)
123
456
1 - SS 1 TX
2 - FTDI RX
3 - UART2 TX
4 - SS1 RX
5 - FTDI TX
6 - UART2 RX
Bottom Right
HoTT Telemetry port
When the HoTT enable jumper is on pins 2 and 3 then HoTT data can be received/transmitted on either
serial port depending on the placement of the Derial IO selection jumpers.
When not in use the HoTT enable jumper can be stored on pins 3 and 4
The HoTT telemetry is connected to the center pins (2 & 5) of the Serial IO header.
4 way header (left to right)
1 - HoTT Telemetry In/Out
2 - HoTT Enable Jumper
3 - HoTT Enable Jumper
4 - N/C - Jumper Storage

54
docs/Board - Sparky.md
View file

@ -27,7 +27,59 @@ Tested with revision 1 board.
# Flashing
## Via Device Firmware Upload (DFU, USB)
## Via Device Firmware Upload (DFU, USB) - Windows
These instructions are for flashing the Sparky board under Windows using DfuSE.
Credits go to Thomas Shue (Full video of the below steps can be found here: https://www.youtube.com/watch?v=I4yHiRVRY94)
Required Software:
DfuSE Version 3.0.2 (latest version 3.0.4 causes errors): http://code.google.com/p/multipilot32/downloads/detail?name=DfuSe.rar
STM VCP Driver 1.4.0: http://www.st.com/web/en/catalog/tools/PF257938
A binary file is required for DFU, not a .hex file. If one is not included in the release then build one as follows.
```
Unpack DfuSE and the STM VCP Drivers into a folder on your Hardrive
Download the latest Sparky release (cleanflight_SPARKY.hex) from:
https://github.com/cleanflight/cleanflight/releases and store it on your Hardrive
In your DfuSE folder go to BIN and start DfuFileMgr.exe
Select: "I want to GENERATE a DFUfile from S19,HEX or BIN files" press OK
Press: "S19 or Hex.."
Go to the folder where you saved the cleanflight_SPARKY.hex file, select it and press open
(you might need to change the filetype in the DfuSE explorer window to "hex Files (*.hex)" to be able to see the file)
Press: "Generate" and select the .dfu output file and location
If all worked well you should see " Success for 'Image for lternate Setting 00 (ST..)'!"
```
Put the device into DFU mode by powering on the sparky with the bootloader pins temporarily bridged. The only light that should come on is the blue PWR led.
Check the windows device manager to make sure the board is recognized correctly.
It should show up as "STM Device in DFU mode" under Universal Serial Bus Controllers
If it shows up as "STMicroelectronics Virtual COM" under Ports (COM & LPT) instead then the board is not in DFU mode. Disconnect the board, short the bootloader pins again while connecting the board.
If the board shows up as "STM 32 Bootloader" device in the device manager, the drivers need to be updated manually.
Select the device in the device manager, press "update drivers", select "manual update drivers" and choose the location where you extracted the STM VCP Drivers, select "let me choose which driver to install". You shoud now be able to select either the STM32 Bootloader driver or the STM in DFU mode driver. Select the later and install.
Then flash the binary as below.
```
In your DfuSE folder go to BIN and start DfuSeDemo.exe
Select the Sparky Board (STM in DFU Mode) from the Available DFU and compatible HID Devices drop down list
Press "Choose.." at the bootom of the window and select the .dfu file created in the previous step
"File correctly loaded" should appear in the status bar
Press "Upgrade" and confirm with "Yes"
The status bar will show the upload progress and confirm that the upload is complete at the end
```
Disconnect and reconnect the board from USB and continue to configure it via the Cleanflight configurator as per normal
## Via Device Firmware Upload (DFU, USB) - Mac OS X
These instructions are for dfu-util, tested using dfu-util 0.7 for OSX from the OpenTX project.

4
docs/Controls.md
View file

@ -30,3 +30,7 @@ HIGH - the channel value for the mapped channel input is around 2000
| Trim Acc Backwards | HIGH | CENTER | LOW | CENTER |
| Save setting | LOW | LOW | LOW | HIGH |
##### Download a graphic [pdf cheat-sheet](https://multiwii.googlecode.com/svn/branches/Hamburger/MultiWii-StickConfiguration-23_v0-5772156649.pdf) with TX stick commands.
The Latest version of this pdf can always be found [Here](https://code.google.com/p/multiwii/source/browse/#svn%2Fbranches%2FHamburger)

39
docs/Failsafe.md
View file

@ -6,51 +6,72 @@ There are two types of failsafe:
2. flight controller based failsafe
Receiver based failsafe is where you, from your transmitter and receiver, configure channels to output desired signals if your receiver detects signal loss.
The idea is that you set throttle and other controls so the aircraft descends in a controlled manner.
The idea is that you set throttle and other controls so the aircraft descends in a controlled manner. See your receiver's documentation for this method.
Flight controller based failsafe is where the flight controller attempts to detect signal loss from your receiver.
It is possible to use both types at the same time and may be desirable. Flight controller failsafe can even help if your receiver signal wires come loose, get damaged or your receiver malfunctions in a way the receiver itself cannot detect.
It is possible to use both types at the same time which may be desirable. Flight controller failsafe can even help if your receiver signal wires come loose, get damaged or your receiver malfunctions in a way the receiver itself cannot detect.
## Flight controller failsafe system
The failsafe system is not activated until 5 seconds after the flight controller boots up. This is to prevent failsafe from activating in the case of TX/RX gear with long bind procedures before they send out valid data.
After the failsafe has been forced a landing, the flight controller cannot be armed and has to be reset.
After the failsafe has forced a landing, the flight controller cannot be armed and has to be reset.
The failsafe system attempts to detect when your receiver loses signal. It then attempts to prevent your aircraft from flying away uncontrollably.
The failsafe is activated when:
Either:
a) no valid channel data from the RX via Serial RX.
a) no valid channel data from the RX is received via Serial RX.
b) the first 4 Parallel PWM/PPM channels do not have valid signals.
And:
c) the failsafe guard time specified by `failsafe_delay` has elapsed.
## Configuration
There are a few settings for it, as below.
When configuring the flight controller failsafe, use the following steps:
1. Configure your receiver to do one of the following:
a) Upon signal loss, send no signal/pulses over the channels
b) Send an invalid signal over the channels (for example, send values lower than 'failsafe_min_usec')
See your receiver's documentation for direction on how to accomplish one of these.
2. Set 'failsafe_off_delay' to an appropriate value based on how high you fly
3. Set 'failsafe_throttle' to a value that allows the aircraft to descend at approximately one meter per second.
These are the basic steps for flight controller failsafe configuration, see Failsafe Settings below for additional settings that may be changed.
##Failsafe Settings
Failsafe delays are configured in 0.1 second steps.
1 step = 0.1sec
1 second = 10 steps
### `failsafe_delay`
Guard time for failsafe activation after signal lost.
Guard time for failsafe activation after signal lost. This is the amount of time the flight controller waits to see if it begins receiving a valid signal again before activating failsafe.
### `failsafe_off_delay`
Delay after failsafe activates before motors finally turn off. If you fly high you may need more time.
Delay after failsafe activates before motors finally turn off. This is the amount of time 'failsafe_throttle' is active. If you fly at higher altitudes you may need more time to descend safely.
### `failsafe_throttle`
Throttle level used for landing. Specify a value that causes the aircraft to descend at about 1M/sec.
Use standard RX usec values. See Rx documentation.
Use standard RX usec values. See RX documentation.
### `failsafe_min_usec`
@ -64,7 +85,7 @@ The longest PWM/PPM pulse considered valid.
Only valid when using Parallel PWM or PPM receivers.
This setting helps catch when your RX stops sending any data when the RX looses signal.
This setting helps detect when your RX stops sending any data when the RX looses signal.
With a Graupner GR-24 configured for PWM output with failsafe on channels 1-4 set to OFF in the receiver settings
then this setting, at its default value, will allow failsafe to be activated.

12
docs/LedStrip.md
View file

@ -51,12 +51,12 @@ uses. e.g. ESC1/BEC1 -> FC, ESC2/BEC2 -> LED strip. It's also possible to pow
from another BEC. Just ensure that the GROUND is the same for all BEC outputs and LEDs.
| Target | Pin | LED Strip | Signal |
| --------------------- | --- | --------- | -------|
| Naze/Olimexino | RC5 | Data In | PA6 |
| CC3D | ??? | Data In | PB4 |
| ChebuzzF3/F3Discovery | PB8 | Data In | PB8 |
| Target | Pin | LED Strip | Signal |
| --------------------- | ---- | --------- | -------|
| Naze/Olimexino | RC5 | Data In | PA6 |
| CC3D | RCO5 | Data In | PB4 |
| ChebuzzF3/F3Discovery | PB8 | Data In | PB8 |
| Sparky | PWM5 | Data In | PA6 |
Since RC5 is also used for SoftSerial on the Naze/Olimexino it means that you cannot use SoftSerial and led strips at the same time.
Additionally, since RC5 is also used for Parallel PWM RC input on both the Naze, Chebuzz and STM32F3Discovery targets, led strips

58
docs/Mixer.md Normal file
View file

@ -0,0 +1,58 @@
# Mixer
Cleanflight supports a number of mixing configurations as well as custom mixing. Mixer configurations determine how the servos and motors work together to control the aircraft.
## Configuration
To use a built-in mixing configuration, you can use the Chrome configuration GUI. It includes images of the various mixer types to assist in making the proper connections. See the Configuration section of the documentation for more information on the GUI.
You can also use the Command Line Interface (CLI) to set the mixer type:
1. Use `mixer list` to see a list of supported mixes
2. Select a mixer. For example, to select TRI, use `mixer TRI`
3. You must use `save` to preserve your changes
## Supported Mixer Types
| Name | Description | Motors | Servos |
| ------------- | ------------------------- | -------------- | ---------------- |
| TRI | Tricopter | M1-M3 | S1 |
| QUADP | Quadcopter-Plus | M1-M4 | None |
| QUADX | Quadcopter-X | M1-M4 | None |
| BI | Bicopter (left/right) | M1-M2 | S1, S2 |
| GIMBAL | Gimbal control | N/A | S1, S2 |
| Y6 | Y6-copter | M1-M6 | None |
| HEX6 | Hexacopter-Plus | M1-M6 | None |
| FLYING_WING | Fixed wing; elevons | M1 | S1, S2 |
| Y4 | Y4-copter | M1-M4 | None |
| HEX6X | Hexacopter-X | M1-M6 | None |
| OCTOX8 | Octocopter-X (over/under) | M1-M8 | None |
| OCTOFLATP | Octocopter-FlatPlus | M1-M8 | None |
| OCTOFLATX | Octocopter-FlatX | M1-M8 | None |
| AIRPLANE | Fixed wing; Ax2, R, E | M1 | S1, S2, S3, S4 |
| HELI_120_CCPM | | | |
| HELI_90_DEG | | | |
| VTAIL4 | Quadcopter with V-Tail | M1-M4 | N/A |
| HEX6H | Hexacopter-H | M1-M6 | None |
| PPM_TO_SERVO | | | |
| DUALCOPTER | Dualcopter | M1-M2 | S1, S2 |
| SINGLECOPTER | Conventional helicopter | M1 | S1 |
| ATAIL4 | Quadcopter with A-Tail | M1-M4 | N/A |
| CUSTOM | User-defined | | |
## Servo filtering
A low-pass filter can be enabled for the servos. It may be useful for avoiding structural modes in the airframe, for example. Currently it can only be configured via the CLI:
1. Use `set servo_lowpass_freq_idx = nn` to select the cutoff frequency. Valid values range from 0 to 99.
2. Use `set servo_lowpass_enable = 1` to enable filtering.
The actual cutoff frequency is determined by the value of the `looptime` variable and the selected index.
The formula is:
`Frequency = 1000000 * (servo_lowpass_freq_idx + 1)*0.0025 / looptime )`
For example, if `servo_lowpass_freq_idx` is set to 40, and looptime is set to the default of 3500 us (0.0035 s), the cutoff frequency will be 29.3 Hz.

48
docs/Modes.md
View file

@ -3,30 +3,30 @@
Cleanflight has various modes that can be toggled on or off. Modes can be enabled/disabled by stick positions,
auxillary receiver channels and other events such as failsafe detection.
| ID | Short Name | Function |
| --- | ---------- | -------------------------------------------------------------------- |
| 0 | ARM | Enables motors and flight stabilisation |
| 1 | ANGLE | Legacy auto-level flight mode |
| 2 | HORIZON | Auto-level flight mode |
| 3 | BARO | Altitude hold mode (Requires barometer sensor) |
| 4 | MAG | Heading lock |
| 5 | HEADFREE | Head Free - When enabled yaw has no effect on pitch/roll inputs |
| 6 | HEADADJ | Heading Adjust - Sets a new yaw origin for HEADFREE mode |
| 7 | CAMSTAB | Camera Stabilisation |
| 8 | CAMTRIG | |
| 9 | GPSHOME | Autonomous flight to HOME position |
| 10 | GPSHOLD | Maintain the same longitude/lattitude |
| 11 | PASSTHRU | |
| 12 | BEEPERON | Enable beeping - useful for locating a crashed aircraft |
| 13 | LEDMAX | |
| 14 | LEDLOW | |
| 15 | LLIGHTS | |
| 16 | CALIB | |
| 17 | GOV | |
| 18 | OSD | Enable/Disable On-Screen-Display (OSD) |
| 19 | TELEMETRY | Enable telemetry via switch |
| 20 | AUTOTUNE | Autotune Pitch/Roll PIDs |
| 21 | SONAR | Altitude hold mode (sonar sensor only) |
| MSP ID | Short Name | Function |
| ------- | ---------- | -------------------------------------------------------------------- |
| 0 | ARM | Enables motors and flight stabilisation |
| 1 | ANGLE | Legacy auto-level flight mode |
| 2 | HORIZON | Auto-level flight mode |
| 3 | BARO | Altitude hold mode (Requires barometer sensor) |
| 5 | MAG | Heading lock |
| 6 | HEADFREE | Head Free - When enabled yaw has no effect on pitch/roll inputs |
| 7 | HEADADJ | Heading Adjust - Sets a new yaw origin for HEADFREE mode |
| 8 | CAMSTAB | Camera Stabilisation |
| 9 | CAMTRIG | |
| 10 | GPSHOME | Autonomous flight to HOME position |
| 11 | GPSHOLD | Maintain the same longitude/lattitude |
| 12 | PASSTHRU | |
| 13 | BEEPERON | Enable beeping - useful for locating a crashed aircraft |
| 14 | LEDMAX | |
| 15 | LEDLOW | |
| 16 | LLIGHTS | |
| 17 | CALIB | |
| 18 | GOV | |
| 19 | OSD | Enable/Disable On-Screen-Display (OSD) |
| 20 | TELEMETRY | Enable telemetry via switch |
| 21 | AUTOTUNE | Autotune Pitch/Roll PIDs |
| 22 | SONAR | Altitude hold mode (sonar sensor only) |
## Mode details

117
docs/Rx.md
View file

@ -1,44 +1,67 @@
# Receivers (RX)
## Parallel PWM
A receiver is used to receive radio control signals from your transmitter and convert them into signals that the flight controller can understand.
There are 3 basic types of receivers:
Parallel PWM Receivers
PPM Receivers
Serial Receivers
## Parallel PWM Receivers
8 channel support, 1 channel per input pin. On some platforms using parallel input will disable the use of serial ports
and SoftSerial making it hard to use telemetry or GPS features.
## PPM (PPM SUM or CPPM)
## PPM Receivers
PPM is sometimes known as PPM SUM or CPPM.
12 channels via a single input pin, not as accurate or jitter free as methods that use serial communications, but readily available.
## MultiWii serial protocol (MSP)
These receivers are reported working:
Allows you to use MSP commands as the RC input. Only 8 channel support to maintain compatibility with MSP.
FrSky D4R-II
http://www.frsky-rc.com/product/pro.php?pro_id=24
## Spektrum
Graupner GR24
http://www.graupner.de/en/products/33512/product.aspx
R615X Spektrum/JR DSM2/DSMX Compatible 6Ch 2.4GHz Receiver w/CPPM
http://orangerx.com/2014/05/20/r615x-spektrumjr-dsm2dsmx-compatible-6ch-2-4ghz-receiver-wcppm-2/
FrSky D8R-XP 8ch telemetry receiver, or CPPM and RSSI enabled receiver
http://www.frsky-rc.com/product/pro.php?pro_id=21
## Serial Receivers
### Spektrum
8 channels via serial currently supported.
## S.BUS
These receivers are reported working:
16 channels via serial currently supported.
Lemon Rx DSMX Compatible PPM 8-Channel Receiver + Lemon DSMX Compatible Satellite with Failsafe
http://www.lemon-rx.com/shop/index.php?route=product/product&product_id=118
## XBUS
The firmware currently supports the MODE B version of the XBus protocol.
Make sure to set your TX to use "MODE B" for XBUS in the TX menus!
See here for info on JR's XBUS protocol: http://www.jrpropo.com/english/propo/XBus/
### S.BUS
Tested hardware: JR XG14 + RG731BX with NAZE32 (rev4)
With the current CLI configuration:
```
set serialrx_provider=5
set serial_port_2_scenario=3
feature RX_SERIAL
```
This will set the controller to use serial RX, with XBUS_MODE_B as provider and finally the scenario to be used for serial port 2.
Please note that your config may vary depending on the Board used.
16 channels via serial currently supported. See the Serial chapter in the documentation for a configuration example.
### OpenTX configuration
* In most cases you will need an inverter between the receiver output and the flight controller hardware.
* Softserial ports cannot be used with SBUS because it runs at too high of a bitrate (1Mbps). Refer to the chapter specific to your board to determine which port(s) may be used.
* You will need to configure the channel mapping in the GUI (Receiver tab) or CLI (`map` command).
These receivers are reported working:
FrSky X4RSB 3/16ch Telemetry Receiver
http://www.frsky-rc.com/product/pro.php?pro_id=135
FrSky X8R 8/16ch Telemetry Receiver
http://www.frsky-rc.com/product/pro.php?pro_id=105
#### OpenTX S.BUS configuration
If using OpenTX set the transmitter module to D16 mode and select CH1-16 on the transmitter before binding to allow reception
of 16 channels.
@ -47,18 +70,56 @@ OpenTX 2.09, which is shipped on some Taranis X9D Plus transmitters, has a bug -
The bug prevents use of all 16 channels. Upgrade to the latest OpenTX version to allow correct reception of all 16 channels,
without the fix you are limited to 8 channels regardless of the CH1-16/D16 settings.
## SUMD
### XBUS
The firmware currently supports the MODE B version of the XBus protocol.
Make sure to set your TX to use "MODE B" for XBUS in the TX menus!
See here for info on JR's XBUS protocol: http://www.jrpropo.com/english/propo/XBus/
These receivers are reported working:
XG14 14ch DMSS System w/RG731BX XBus Receiver
http://www.jramericas.com/233794/JRP00631/
### SUMD
16 channels via serial currently supported.
## SUMH
These receivers are reported working:
GR-24 receiver HoTT
http://www.graupner.de/en/products/33512/product.aspx
Graupner receiver GR-12SH+ HoTT
http://www.graupner.de/en/products/870ade17-ace8-427f-943b-657040579906/33565/product.aspx
### SUMH
8 channels via serial currently supported.
### Configuration
SUMH is a legacy Graupner protocol. Graupner have issued a firmware updates for many recivers that lets them use SUMD instead.
See the Configuration document some some RX configuration examples.
## MultiWii serial protocol (MSP)
Allows you to use MSP commands as the RC input. Only 8 channel support to maintain compatibility with MSP.
## Configuration
There are 3 features that control receiver mode:
```
RX_PPM
RX_SERIAL
RX_PARALLEL_PWM
RX_MSP
```
Only one receiver feature can be enabled at a time.
### Serial RX
See the Serial chapter for some some RX configuration examples.
For Serial RX enable `RX_SERIAL` and set the `serialrx_provider` CLI setting as follows.
@ -72,7 +133,7 @@ For Serial RX enable `RX_SERIAL` and set the `serialrx_provider` CLI setting as
| XBUS_MODE_B | 5 |
#### PPM/PWM input filtering.
### PPM/PWM input filtering.
Hardware input filtering can be enabled if you are experiencing interference on the signal sent via your PWM/PPM RX.

BIN
docs/Screenshots/blackbox-screenshot-1.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 242 KiB

2
docs/Serial.md
View file

@ -46,6 +46,8 @@ To make configuration easier, common usage scenarios are listed below.
7 GPS-PASSTHROUGH ONLY
8 MSP ONLY
9 SMARTPORT TELEMETRY ONLY
10 BLACKBOX ONLY
11 MSP, CLI, BLACKBOX, GPS-PASSTHROUGH
```
### Constraints

BIN
docs/Wiring/blackbox-installation-1.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 194 KiB