Skip to content
Snippets Groups Projects
Commit 8201747d authored by knmcguire's avatar knmcguire
Browse files

[docs] copied data from wiki pages to docs

parent 53b05600
Branches
Tags
No related merge requests found
Show whitespace changes
Inline Side-by-side
Showing
with 936 additions and 0 deletions
docs/cfclient_zmq.md 0 → 100644
+ 141
− 0
View file @ 8201747d
The [Crazyflie Python client](/doc/crazyflie/client/pycfclient/index)
runs a number of back-ends where you can set/get information from other
applications via [ZMQ](http://zeromq.org/).
Here\'s a list of the ports/functions available:
| Port | Type | Functionality|
| ------| ------| --------------|
| 1213 | REQ | Set parameters|
| 1214 | PUSH | LED-ring memory|
| 1212 | PULL | Input device|
Parameters
==========
The parameter back-end gives access to setting parameters in the
Crazyflie. The back-end is enabled by default.
Protocol
--------
Available fields:
| Field | Format | Comments |
| -------|-- --------| ---------------------------------------------------|
| version| int | Should be set to 1 |
| cmd | string | Command to send (currently only set is supported) |
| name | string | The name of the parameter |
| value | string | The value of the parameter |
Example of setting the *buzzer.freq*
parameter to 4000.
{
"version": 1,
"cmd": "set",
"name" : "buzzer.freq",
"value": "4000"
}
\</WRAP\> \</WRAP\>
LED-ring
========
The LED-ring back-end gives access to the LED-ring memory driver where
the user can write the RGB values for all 12 LEDs on the ring. The
back-end is enabled by default.
Protocol
--------
Available fields:
| Field | Format | Comments|
| ---------| --------------------------|----- ---------|---------------------------------
| version | int | Should be set to 1|
| rgbleds | array of 3 item arrays of int | R/G/B value for each LED (starting at 1)|
\</WRAP\> \<WRAP half column\> Example of setting all LEDs off:
{
"version": 1,
"rgbleds": [
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0],
[0, 0, 0]
]
}
\</WRAP\> \</WRAP\>
Input device
============
If you don\'t want to use the API and you don\'t want to bother about
scanning/connecting/logging/etc or there\'s no API for the environment
you use, there\'s an easy way to control the Crazyflie. Just like you
would control the Crazyflie with a gamepad or joystick connected to a
computer, you can use ZMQ to inject control set-points directly into the
client. You still use the client for connecting/logging/graphing/setting
parameters, it\'s just the control part that\'s broken out.
By default this is disabled in the configuration file and needs to be
enabled. The configuration file parameter is named *enable\_zmq\_input*
(see
[this](/doc/crazyflie/dev/host/client/index#user_configuration_file) to
edit the configuration). To enable controlling by the back-end select
the *ZMQ\@127.0.0.1:1212* input device in the *Input device* menu.
Protocol
--------
Available fields:
| Field | Format| Comments|
| --------------| --------| ----------|
| version | int | Should be set to 1|
| client\_name | string |Name of the client (currently unused)|
| ctrl | dict |A dictionary with keys and values that match the internal names of controls in the client (see list below)|
Available keys for the *ctrl* dictionary:
| Field | Range | Unit | Comments|
|---------|----------|----------------|---------------|
| roll | N/A | degrees |
| pitch | N/A | degrees |
| yaw | N/A | degrees/second |
| thrust | 0-100 | Percent |
| estop | T/F | boolean | Used to stop the Crazyflie and disable the control
| alt1 | T/F | boolean | Alt1 is internally mapped to functionality like switching LED-ring effect
| alt2 | T/F | boolean | Alt2 is internally mapped to functionality like switching LED-ring headlights on/off
Example:
{
"version": 1,
"client_name": "ZMQ client",
"ctrl": {
"roll": 0.0,
"pitch": 0.0,
"yaw": 0.0,
"thrust": 0.0
}
}
**NOTE1**: Altitude hold is currently not working.
**NOTE2**: The values are used at 100Hz in the client, no matter at what
rate they are sent via ZMQ
docs/cfheadless.md 0 → 100644
+ 42
− 0
View file @ 8201747d
# Crazyflie headless client
The *cfheadless* client doesn\'t have a UI, it\'s run directly from the
command line and is suited for headless hosts like the Raspberry Pi.
## cfheadless
The script is located in the *bin* directory in the
*crazyflie-clients-python* repository and client. Here\'s how to use the
script:
```
$ bin/cfheadless -h
usage: cfheadless [-h] [-u URI] [-i INPUT] [-d] [-c CONTROLLER]
[--controllers] [-x]
optional arguments:
-h, --help show this help message and exit
-u URI, --uri URI URI to use for connection to the Crazyradio dongle,
defaults to radio://0/10/250K
-i INPUT, --input INPUT
Input mapping to use for the controller,defaults to
PS3_Mode_1
-d, --debug Enable debug output
-c CONTROLLER, --controller CONTROLLER
Use controller with specified id, id defaults to 0
--controllers Only display available controllers and exit
-x, --x-mode Enable client-side X-mode
```
The client is exited either by taking out the Crazyradio USB dongle or
pressing Ctrl+C
## Examples
Connect to a Crazyflie at channel 100 and speed 250Kbit using input
mapping *PS3\_Mode\_1*
```
crazyflie-clients-python$ bin/cfheadless -u radio://0/100/250K -PS1_Mode_1
```
docs/cfloader.md 0 → 100644
+ 128
− 0
View file @ 8201747d
Bootloader the Crazyflie 1.0/2.0
================================
The Crazyflie can be bootloaded from the commandline using the
*cfloader* script.
**Note:** To enter the bootloader for the Crazyflie 1.0 just restart the
platform. To enter the bootloader for the Crazyflie 2.0 power off the
platform and start it again by pressing the power button for at least
1.5 seconds, but not more than 5.
Programming Crazyflie from firmware projects
============================================
When developping with the Crazyflie firmware projects, either
[crazyflie-firmware](https://github.com/bitcraze/crazyflie-firmware) or
[crazyflie2-nrf-firmware](https://github.com/bitcraze/crazyflie2-nrf-firmware)
you can flash your current build with:
make cload
If you want the Crazyflie to restart automatically in bootloader mode
you can enable the warmboot mode. To do so, edit the file
\'tool/make/config.mk\' and add the address of your Crazyflie:
CLOAD_CMDS = -w radio://0/80/250K/E7E7E7E7E7
After this, \'make cload\' will restart the Crazyflie in bootlader mode,
flash it and restart it with the new firmware.
\<WRAP center round info\> In warmboot mode the bootloader is launched
using a random address. This means that multiple Crazyflie can be
programmed at the same time without collision. \</WRAP\> \<WRAP center
round important\> ***Warning*** If the flashing operation fails or if
the firmware has a bug, it may be impossible to warmboot. In that case
start the bootloader manually and disable warmboot temporarly by
programming with:
make cload CLOAD_CMDS=
\</WRAP\>
cfloader
========
The script is located in the *bin* directory in the
*crazyflie-clients-python* repository and client. Here\'s how to use the
script:
crazyflie-clients-python$ bin/cfclient
==============================
CrazyLoader Flash Utility
==============================
Usage: bin/cfloader [CRTP options] <action> [parameters]
The CRTP options are described above
Crazyload option:
info : Print the info of the bootloader and quit.
Will let the target in bootloader mode
reset : Reset the device in firmware mode
flash <file> [targets] : flash the <img> binary file from the first
possible page in flash and reset to firmware
mode.
Crazyflie 1.0 examples
----------------------
crazyflie-clients-python$ bin/cfloader flash cflie.bin stm32-fw
Restart the Crazyflie you want to bootload in the next 10 seconds ... done!
Connected to bootloader on Crazyflie Nano Quadcopter (1.0) (version=0x1)
Target info: stm32 (0xFF)
Flash pages: 128 | Page size: 1024 | Buffer pages: 10 | Start page: 10
118 KBytes of flash avaliable for firmware image.
Flashing 1 of 1 to stm32 (fw): 56043 bytes (55 pages) ..........10..........10..........10..........10..........10.....5
Reset in firmware mode ...
Crazyflie 2.0 examples
----------------------
Flashing new firmware for the nRF51 MCU:
crazyflie-clients-python$ bin/cfloader flash cf2_nrf.bin nrf51-fw
Restart the Crazyflie you want to bootload in the next 10 seconds ... done!
Connected to bootloader on Crazyflie 2.0 (version=0x10)
Target info: nrf51 (0xFE)
Flash pages: 232 | Page size: 1024 | Buffer pages: 1 | Start page: 88
144 KBytes of flash avaliable for firmware image.
Target info: stm32 (0xFF)
Flash pages: 1024 | Page size: 1024 | Buffer pages: 10 | Start page: 16
1008 KBytes of flash avaliable for firmware image.
Flashing 1 of 1 to nrf51 (fw): 25151 bytes (25 pages) .1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
Reset in firmware mode ...
Flashing new firmware for the STM32 MCU:
crazyflie-clients-python$ bin/cfloader flash cflie.bin stm32-fw
Restart the Crazyflie you want to bootload in the next 10 seconds ... done!
Connected to bootloader on Crazyflie 2.0 (version=0x10)
Target info: nrf51 (0xFE)
Flash pages: 232 | Page size: 1024 | Buffer pages: 1 | Start page: 88
144 KBytes of flash avaliable for firmware image.
Target info: stm32 (0xFF)
Flash pages: 1024 | Page size: 1024 | Buffer pages: 10 | Start page: 16
1008 KBytes of flash avaliable for firmware image.
Flashing 1 of 1 to stm32 (fw): 76435 bytes (75 pages) ..........10..........10..........10..........10..........10..........10..........10.....5
Reset in firmware mode ...
Flash a new firmware package (containing both nRF51 and STM32 firmware):
crazyflie-clients-python$ bin/cfloader flash cf2_dev_update.zip
Restart the Crazyflie you want to bootload in the next 10 seconds ... done!
Connected to bootloader on Crazyflie 2.0 (version=0x10)
Target info: nrf51 (0xFE)
Flash pages: 232 | Page size: 1024 | Buffer pages: 1 | Start page: 88
144 KBytes of flash avaliable for firmware image.
Target info: stm32 (0xFF)
Flash pages: 1024 | Page size: 1024 | Buffer pages: 10 | Start page: 16
1008 KBytes of flash avaliable for firmware image.
Flashing 1 of 2 to stm32 (fw): 76435 bytes (75 pages) ..........10..........10..........10..........10..........10..........10..........10.....5
Flashing 2 of 2 to nrf51 (fw): 25151 bytes (25 pages) .1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
Reset in firmware mode ...
docs/client.md 0 → 100644
+ 57
− 0
View file @ 8201747d
# Bootloader client implementation
## Bootloader file format
In order to make bootloading easier across platforms the different
firmwares are packaged together in a ZIP file that contains a manifest
describing which files are used for what. Here\'s an example of a
manifest, it should be called *manifest.json*:
{
"version": 1,
"files": {
"cflie.bin": {
"platform": "cf2",
"target": "stm32",
"type": "fw"
},
"nrf_cf2.bin": {
"platform": "cf2",
"target": "nrf51",
"type": "fw"
},
"nrf_cload.bin": {
"platform": "cf2",
"target": "nrf51",
"type": "bootloader"
},
"s110.bin": {
"platform": "cf2",
"target": "nrf51",
"type": "softdevice"
}
"cf2_lua.bin": {
"platform": "cf2",
"target": "stm32",
"type": "userapp",
"origin": 524288
}
}
}
Each entry in the file describes one file, with the following
attributes:
| Attribute | Values |Comments|
| --------------- | ------------------------------------- | ---------------------- |
| platform | cf1, cf2 |Select the target platform |
| target | stm32, nrf51 |Select the target MCU on the target platform|
| type | fw, bootloader, softdevice, userapp |Describe what\'s contained in the binary|
| origin | N/A |Set the address where the app should be flashed|
Currently only platform=cf2, target=stm32, target=nrf51 and type=fw is
supported.
docs/dev_info_client.md 0 → 100644
+ 568
− 0
View file @ 8201747d
Crazyflie Python client
=======================
This page contains generic information about various topics that might
be interesting while developing for the Crazyflie Python client. The
same kind of information is available here for the Crazyflie Python API.
Here\'s a quick overview:
- The GUI is made in QT4 (using QTDesigner 4 and loading the .ui files
at runtime)
- It uses the SDL2 to read input devices on Windows/Mac OSX and raw
jsdevs on Linux. It also supports custom input from
[LeapMotion](https://www.leapmotion.com/) and
[ZMQ](http://zeromq.org/).
Architecture
============
![](images/input-arch-mux.png){:.align-right
width="600"}
Input devices
-------------
The architecture for the input devices in the client strives to give as
much flexibility as possible and to make cross platform compatibility
smooth. It combines raw readings from input devices with input device
mappings to create control values for the Crazyflie and the application.
It\'s also possible to input control values directly.
Below is a walk though of every step of the process, from reading the
device to sending the control values to the Crazyflie.
### InputDevice
There are two ways to get input into the client: Input readers and input
interfaces. On startup the modules *lib/cfclient/utils/inputreaders* and
*lib/cfclient/utils/inputinterfaces* are initialized and these
directories are scanned for implementations that can be used. Each
python file in these directories represent a \"backend\" that handles
input. Each backend can have zero, one or multiple devices that it can
control. The *inputreaders* module is used to read normal
joysticks/gamepads while the *inputinterfaces* module is used to read
any custom interface that\'s not a joystick/gamepad.
Once the backends are found the client tries to initialize each backend.
If successful it is scanned for devices, otherwise it\'s quietly
discarded (only printing a message to the console). A structure is build
where the dependency is reversed (backend-\>device to device-\>backend)
and a list of devices (with connected backends) is passed on.
The client can now open any device in the list and read it. If the
device is from the *inputreaders* module a mapping has to be supplied as
described below.
#### Input readers
Currently there\'s two types of *inputreaders*: SDL2 and Linux. The
Linux backend is used on Linux and SDL2 on all other platforms. In order
to use the devices connected to the backend a mapping has to be supplied
to translate the raw axis/buttons indexes (0, 1, 2..) to usable values
(roll/pitch/yaw/thrust..).
#### Input interfaces
The input interfaces don\'t use any mapping, the devices itself directly
generate useful values (like roll/pitch/yaw/thrust). Currently there\'s
two implementations: LeapMotion and ZMQ. Values are read the same way as
from normal gamepads/joysticks, at 100Hz. For more information on how
the ZMQ interface works read [here](/doc/crazyflie/zmq/index).
### The MUX
#### Scaling and processing
### Input and beyond
Files
=====
To support the application there\'s a number of files around it, such as
configuration and caching. All these use JSON to store information. All
of the user configuration files are stored in the */conf* directory.
Most of the files have default versions in the */lib/configs* directory
that are either copied at the first start up or used in parallel as
read-only copies to complement what ever is stored in the user
configuration directory.
User configuration file
-----------------------
To save the configuration between runs of the application there\'s a
configuration file (*/conf/config.json*).The file is updated while the
application runs and settings change. Below is an example of the
configuration file.
``` {.json}
{
"client_side_xmode": false,
"link_uri": "radio://0/100/250K",
"input_device": "Sony PLAYSTATION(R)3 Controller",
"slew_limit": 45,
"max_rp": 30,
"ui_update_period": 100,
"trim_pitch": 0.0,
"device_config_mapping": {
"Leapmotion": "LeapMotion",
"Sony PLAYSTATION(R)3 Controller": "PS3_Mode_1_Split-Yaw_Linux",
"PLAYSTATION(R)3 Controller (34:C7:31:8E:CF:0E)": "PS3_Mode_1",
"Microsoft X-Box 360 pad": "xbox360_mode1_linux"
},
"slew_rate": 30,
"auto_reconnect": false,
"max_yaw": 200,
"flightmode": "Advanced",
"enable_debug_driver": false,
"open_tabs": "Flight Control,Parameters,Console",
"input_device_blacklist": "(VirtualBox|VMware)",
"trim_roll": 0.0,
"max_thrust": 80.0,
"min_thrust": 25.0
}
```
Field Format Comments
-------------------------- --------- ----------------------------------------------------------------------------------------------------------------------------------------------
client\_side\_xmode boolean Sets weather the client side X-mode is activated or not (more info here)
link\_uri string The last successfully connected Crazyflie URI. This is used when you click \"Quick connect\" in the application
auto\_reconnect boolean Set\'s if auto-reconnect is enabled or not
ui\_update\_period int The minimum time (in ms) between UI updates for logging values
enable\_debug\_driver boolean The Crazyflie API contains a driver for debugging the UI. This driver will act as a Crazyflie and can be used to simulate a number of issues
open\_tabs string A comma-separated list of the open tabs (using the tab.tabName attribute)
input\_device string The readable name of the last used input device
device\_config\_mapping dict A dictionary where the keys are readable input device names and the values are the last used mapping for the device
input\_device\_blacklist string A regexp that will sort out input devices while scanning. This is to avoid detecting virtual joysticks while using a VM
flight\_mode string The name of the last used flightmode (either Advanced or ?)
slew\_limit int The limit (in %) where the slew-tate limiting kicks in, only applicable in Advanced mode
slew\_rate int The slew rate in %/s that will limit the lowering of the thrust, only applicable in Advanced mode
trim\_pitch float The pitch trim (degrees)
trim\_roll float The roll trim (degrees)
max\_thrust float Max allowed thrust, only applicable in Advanced mode
min\_thrust float Min allowed thrust, only applicable in Advanced mode
max\_yaw float Max allowed yaw rate (degrees/s), only applicable in Advanced mode
max\_rp float Max allowed roll/pitch (degrees), only applicable in Advanced mode
Default configuration file
--------------------------
The source code contains a default configuration file
(*/lib/cfclient/configs/config.json*). The file contains two parts: The
default writable part and the default read-only part. When the
application is started for the first time (and */conf*/ doesn\'t exists)
the writable part of this configuration file is copied to the
*/conf/config.json* file to create the default values. The read-only
part is used for settings that cannot be changed, but shouldn\'t be
hardcoded in the code. When the application starts and both the user
config in */conf/config.json* and the read-only part of
*/lib/cfclient/configs/config.json* is merged so they can all be
accessed in the application.
``` {.json}
{
"writable" : {
"input_device": "",
"link_uri": "",
"flightmode": "Normal",
"open_tabs": "Flight Control",
"trim_pitch": 0.0,
"slew_limit": 45,
"slew_rate": 30,
"trim_roll": 0.0,
"max_thrust": 80,
"min_thrust": 25,
"max_yaw": 200,
"max_rp": 30,
"client_side_xmode": false,
"auto_reconnect": false,
"device_config_mapping": {},
"enable_debug_driver": false,
"input_device_blacklist": "(VirtualBox|VMware)",
"ui_update_period": 100
},
"read-only" : {
"normal_slew_limit": 45,
"normal_slew_rate": 30,
"normal_max_thrust": 80,
"normal_min_thrust": 25,
"normal_max_yaw": 200,
"normal_max_rp": 30,
"default_cf_channel": 10,
"default_cf_speed": 0,
"default_cf_trim": 0
}
}
```
TOC cache files
---------------
In order to speed up the connection procedure for the Crazyflie the TOCs
are cached ([more info on logging/parameter frameworks and
TOC](/doc/crazyflie/dev/arch/logparam)). The writable part of the TOC
cache is located in */conf/cache* where each cache is saved in a file
named after the CRC32 (in hex) of the TOC CRC32 (for example
*1CB41680.json*). There\'s also a read-only part of the TOC cache
that\'s located in */lib/cglib/cache* and contains the caches for
official builds. When the application connects to a Crazyflie the CRC32
of the log and param TOC is requested. When the client receives it will
check if a file with the correct name exists (in both the RW and the RO
TOC cache). If it does it will load the cached TOC, if not it will start
requesting the TOC from the Crazyflie and when it\'s done it will save
it in the cache.
The TOC cache files are organized in a hierarchical manner after the
*group.name* concept. In the examples below you first see the group
*acc* which contains the variables *y*,*x*,*z*,*zw* and *mag2*. Each of
these variables have a set of attributes that are described below.
| Field | Format | Comments|
| --------------| ------- | --------|
| ident | int | The TOC id of the variable|
| group | string | The group the variable belongs to|
| name | string | The name of the variable|
| prototype | string | The Python unpack string of the variable used when unpacking the binary data|
| [class]{.underline} | string | The name of the class that can hold this variable (either LogTocElement or ParamTocElement)|
| ctype | string | The variable type in the firmware|
| access | int | The access restrictions mask for the variable (only applicable for parameters). 0 = RW, 1 = RO
Below is an example of part of the log TOC cache:
``` {.json}
{
"acc": {
"y": {
"ident": 8,
"group": "acc",
"name": "y",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
},
"x": {
"ident": 7,
"group": "acc",
"name": "x",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
},
"z": {
"ident": 9,
"group": "acc",
"name": "z",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
},
"zw": {
"ident": 10,
"group": "acc",
"name": "zw",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
},
"mag2": {
"ident": 11,
"group": "acc",
"name": "mag2",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
}
},
"mag": {
"y": {
"ident": 39,
"group": "mag",
"name": "y",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
},
"x": {
"ident": 38,
"group": "mag",
"name": "x",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
},
"z": {
"ident": 40,
"group": "mag",
"name": "z",
"pytype": "<f",
"__class__": "LogTocElement",
"ctype": "float",
"access": 0
}
},
"stabilizer": {
....
}
}
```
Below is an example of part of the param TOC cache:
``` {.json}
{
"imu_sensors": {
"HMC5883L": {
"ident": 0,
"group": "imu_sensors",
"name": "HMC5883L",
"pytype": "<B",
"__class__": "ParamTocElement",
"ctype": "uint8_t",
"access": 1
},
"MS5611": {
"ident": 1,
"group": "imu_sensors",
"name": "MS5611",
"pytype": "<B",
"__class__": "ParamTocElement",
"ctype": "uint8_t",
"access": 1
}
},
"sensorfusion6": {
"ki": {
"ident": 30,
"group": "sensorfusion6",
"name": "ki",
"pytype": "<f",
"__class__": "ParamTocElement",
"ctype": "float",
"access": 0
},
"kp": {
"ident": 29,
"group": "sensorfusion6",
"name": "kp",
"pytype": "<f",
"__class__": "ParamTocElement",
"ctype": "float",
"access": 0
}
},
"flightmode": {
"althold": {
"ident": 10,
"group": "flightmode",
"name": "althold",
"pytype": "<B",
"__class__": "ParamTocElement",
"ctype": "uint8_t",
"access": 0
}
},
"firmware": {
"revision0": {
"ident": 57,
"group": "firmware",
"name": "revision0",
"pytype": "<L",
"__class__": "ParamTocElement",
"ctype": "uint32_t",
"access": 1
},
"revision1": {
"ident": 58,
"group": "firmware",
"name": "revision1",
"pytype": "<H",
"__class__": "ParamTocElement",
"ctype": "uint16_t",
"access": 1
},
"modified": {
"ident": 59,
"group": "firmware",
"name": "modified",
"pytype": "<B",
"__class__": "ParamTocElement",
"ctype": "uint8_t",
"access": 1
}
},
"cpu": {
....
}
}
```
Input device configuration
--------------------------
Input device configurations are used to map raw axis (integers) to
values such as roll/pitch/yaw/thrust (more info above). The
configurations are stored in */conf/input*, one file for each
configuration. The default configurations are stored in
*/lib/cfclient/configs*. The first time the configuration starts up (if
*/conf/input* doesn\'t exist) the default configurations are copied into
this directory and can then be used.
A raw axis can be mapped to one or more values, that way it\'s possible
to split up values on multiple axis. An example of this is using the
bumper buttons to control the yaw, where the left one controls CW
rotation and the right one controls CCW rotation.
| Field | Format | Comments|
| --------| ------| --------------|
| inputconfig | dict | Contains one input device|
| inputdevice | dict | Contains a configuration for an input device|
| updateperiod | int | Specifies how often the device is read (not used)|
| name | string | Readable name of the configuration|
| axis | list | A list of every axis that is mapped|
| scale | float | A scale that should be applied to the axis value (will be divided with the scale). Negative values can be used to invert the axis|
| offset | float | An offset that should be applied to the axis value|
| type | string | Either Input.AXIS or Input.BUTTON depending on if it\'s an axis or a button that *id* or *ids* refer to|
| id | int | The driver id of the axis (used for single axis mapping)|
| ids | list of ints | The driver ids of the axis (used for split axis configuration). The first one will be the negative part and the second one the positive part|
| key | string | This string is used inside the application to determine what value should be updated using this axis|
| name | string | Readable name of the axis (not used)|
``` {.json}
{
"inputconfig": {
"inputdevice": {
"updateperiod": 10,
"name": "PS3_Mode_1_Split-Yaw_Linux",
"axis": [
{
"scale": -1.0,
"type": "Input.AXIS",
"id": 3,
"key": "thrust",
"name": "thrust",
"offset": 1.0,
},
{
"scale": 1.0,
"type": "Input.AXIS",
"ids": [
12,
13
],
"key": "yaw",
"name": "yaw"
},
{
"scale": 1.0,
"type": "Input.AXIS",
"id": 0,
"key": "roll",
"name": "roll"
},
{
"scale": -1.0,
"type": "Input.AXIS",
"id": 1,
"key": "pitch",
"name": "pitch"
},
{
"scale": -1.0,
"type": "Input.BUTTON",
"id": 6,
"key": "pitchcal",
"name": "pitchNeg"
},
{
"scale": 1.0,
"type": "Input.BUTTON",
"id": 4,
"key": "pitchcal",
"name": "pitchPos"
},
{
"scale": 1.0,
"type": "Input.BUTTON",
"id": -1,
"key": "estop",
"name": "killswitch"
},
{
"scale": -1.0,
"type": "Input.BUTTON",
"id": 7,
"key": "rollcal",
"name": "rollNeg"
},
{
"scale": 1.0,
"type": "Input.BUTTON",
"id": 5,
"key": "rollcal",
"name": "rollPos"
},
{
"scale": 1.0,
"type": "Input.BUTTON",
"id": 14,
"key": "althold",
"name": "althold"
},
{
"scale": 1.0,
"type": "Input.BUTTON",
"id": 12,
"key": "exit",
"name": "exitapp"
}
]
}
}
}
```
Log configuration files
-----------------------
The user can configure custom logging configurations from the UI (more
information on logging/parameter
frameworks (/doc/crazyflie/dev/arch/logparam) ). These will be saved in
the */conf/log* directory, one file for each configuration. Default
logging configurations are stored in the */lib/cfclient/configs/log* and
are copied into the user configuration directory on the first status (if
*/conf/log* doesn\'t exist).
| Field | Format | Comments|
| ------------ | --------|
| logconfig | dict | Contains a logging configuration|
| logblock | dict | A logging configuration|
| name | string | A readable name of the configuration that will be shown in the UI|
| period | int | The period the logging data should be requested in. Minimum resolution| is 10th of ms
| variables | list | A list of dictionaries, one for each variable in the configuration |
| name | string | The full name of the variable in the group.name format |
| type | string | Could be either TOC or Memory, currently only TOC is implemented |
| stored\_as | string | The format (as C type) that the variable is stored as in the firmware |
| fetch\_as | string | The format (as C type) that the variable should be logged as |
Below is an example of a log configuration file:
``` {.json}
{
"logconfig": {
"logblock":
{"name": "Stabilizer", "period":20,
"variables": [
{"name":"stabilizer.roll", "type":"TOC", "stored_as":"float", "fetch_as":"float"},
{"name":"stabilizer.pitch", "type":"TOC", "stored_as":"float", "fetch_as":"float"},
{"name":"stabilizer.yaw", "type":"TOC", "stored_as":"float", "fetch_as":"float"}
]}
}
}
```
docs/images/cf_client_1.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cf_client_1.png

74.5 KiB

docs/images/cfclient_anchor_identification.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_anchor_identification.png

118 KiB

docs/images/cfclient_cf2_config.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_cf2_config.png

30.1 KiB

docs/images/cfclient_connect_dialog.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_connect_dialog.png

22.8 KiB

docs/images/cfclient_connected.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_connected.png

133 KiB

docs/images/cfclient_console_marked.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_console_marked.png

326 KiB

docs/images/cfclient_devconfig_axis.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_devconfig_axis.png

224 KiB

docs/images/cfclient_devconfig_dialog.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_devconfig_dialog.png

39.7 KiB

docs/images/cfclient_devconfig_feedback.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_devconfig_feedback.png

216 KiB

docs/images/cfclient_devconfig_select.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_devconfig_select.png

204 KiB

docs/images/cfclient_flightab.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_flightab.png

53 KiB

docs/images/cfclient_input_mux_configured.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_input_mux_configured.png

407 KiB

docs/images/cfclient_input_mux_select.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_input_mux_select.png

387 KiB

docs/images/cfclient_input_normal.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_input_normal.png

50.4 KiB

docs/images/cfclient_input_student.png 0 → 100644
+ 0
− 0
View file @ 8201747d
docs/images/cfclient_input_student.png

528 KiB

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment