http://wiki.paparazziuav.org/w/api.php?action=feedcontributions&user=Ewoud&feedformat=atomPaparazziUAV - User contributions [en]2024-03-29T07:34:13ZUser contributionsMediaWiki 1.37.1http://wiki.paparazziuav.org/w/index.php?title=Developers&diff=23979Developers2017-11-29T12:14:23Z<p>Ewoud: </p>
<hr />
<div>Up to date information on who is working on Paparazzi can be found on [https://github.com/paparazzi/paparazzi/graphs/contributors GitHub]<br />
<br />
Below is a very short list of the main people involved in the project in the past as well as their roles.<br />
The paparazzi project does not have a rigid structure like some other projects, but this list should help if you are looking for someone to discuss your problems or ideas or want to contribute.<br />
The list is not in any particular order.<br />
<br />
{|border=1<br />
| <b>Nickname</b><br />
| <b>Realname</b><br />
| <b>Role</b><br />
|-<br />
| Poine<br />
| Antoine Drouin<br />
| Founder<br />
|-<br />
| [[Hecto|hecto]]<br />
| Pascal Brisset<br />
| Founder<br />
|-<br />
| [[User:flixr|flixr]]<br />
| Felix Ruess<br />
| Maintainer & Software developer<br />
|-<br />
| gautierhattenberger<br />
| Gautier Hattenberger<br />
| Software Developer<br />
|-<br />
| dewagter<br />
| Christophe De Wagter<br />
| Software Developer<br />
|-<br />
| [[User:PaulCox|paulcox]]<br />
| Paul Cox<br />
| Software Developer<br />
|-<br />
| [[User:Martinmm|martinmm]]<br />
| Martin Müller<br />
| Software Developer<br />
|-<br />
| lamestllama<br />
| Eric Parsonage<br />
| Software Developer <br />
|-<br />
| rbdavison<br />
| Bernard Davison<br />
| Software Developer, CI server & Portability maintainer<br />
|-<br />
| bartremes<br />
| Bart Remes<br />
| Software Developer<br />
|-<br />
| openuas<br />
| Erik vanderHorst<br />
| Software Developer<br />
|-<br />
| noether<br />
| Hector Garcia de Marina<br />
| Control engineer and Software developer<br />
|-<br />
| [[User:stephend|stephend]]<br />
| Stephen Dwyer<br />
| Documentation and Wiki coordinator<br />
|-<br />
| [[User:Esden | esden]]<br />
| Piotr Esden-Tempski<br />
| Software & Hardware developer, IRC Admin, Mailnglist Admin<br />
|}<br />
<br />
<br />
[[Category:Community]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Bebop&diff=23978Bebop2017-11-28T15:10:06Z<p>Ewoud: /* Extras */</p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:Parrot-bebop-drone-new-03.jpeg|right|500px|Parrot Bebop]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
<br />
= Introduction =<br />
<br />
By default the [http://www.parrot.com/usa/products/bebop-drone/ Bebop] from [http://www.parrot.com/ Parrot] is a Wifi controlled flying quadrotor, designed to be controlled with an Android or iOS device. <br />
<br />
'''No more restrictions''' as from now; with a few simple clicks you can '''run Paparazzi on the Bebop''' and have full autonomous flight and much more!<br />
<br />
= Getting started =<br />
<br />
== What you need==<br />
# A Bebop or Bebop 2 updated to at least firmware v3.3.0<br />
# A joystick, for example [http://www.hobbyking.com/hobbyking/store/__20951__Hobbyking_6CH_RC_Flight_Simulator_System_Mode_2_.html this one]<br />
# A laptop with Ubuntu installed<br />
<br />
Steps to follow: <br />
# Install Paparazzi via [http://wiki.paparazziuav.org/wiki/Installation the one liner to be found here]. Just Cut 'n Paste (CTRL+C from webbrowser then CTRL+SHIFT+V in your Linux terminal) and press ENTER<br />
# Start Paparazzi Center with the default configuration<br />
# Power up your Bebop<br />
# Press the '''on/off button four times''' short fast half a second clicks '''after''' the bebop is fully powerd up, notice the solid green light on Bebop and solid Red on Bebop 2<br />
# Make a Wifi connection with your PC and the Bebop <br />
# In the Paparazzi center choose "Bebop" Or "Bebop2" in the airframe dropdown menu<br />
# Press the "Upload" button in the Paparazzi Center, wait...<br />
# Select Flight UDP/Wifi in the session menu<br />
# Press execute<br />
<br />
Voila, you will get telemetry from your Bebop. Now it is up to you how and where to fly.<br />
<br />
==Instruction Video==<br />
TIP: Good [https://www.youtube.com/watch?v=eojAPZvT1Ck video series to watch]. Although it is made for the ARDrone 2, the steps are very similar for the Bebop drone. <br />
<br />
= Features =<br />
== Connectivity ==<br />
* Wi-Fi antennas: MIMO dual-band with 2 double-set of dipole antennas for 2.4 and 5 GHz<br />
* Sending power: Up to 26 dBm<br />
* Signal range: N/A<br />
<br />
== Structure ==<br />
* 4 Brushless Outrunner motors<br />
* Glass fiber reinforced (15%) ABS structure<br />
* High-resistance EPP outdoor hull: Clip and unclip easily to adapt to indoor and outdoor flight, protects the propellers against potential bumps, can be removed to reduce wind factor<br />
* Three-blade auto-block propellers in Polycarbonate with fast disassembly system<br />
* Anti-vibration bumpers<br />
<br />
=== Full Motor details ===<br />
<br />
Handy in case for a simulator motor model<br />
<br />
====Bebop====<br />
* Magnets: 12<br />
* Stators: 9<br />
* Layers of stator metal: 15<br />
<br />
* Copper windings: 34<br />
* Copper diameter: 0.29mm<br />
* Copper resistance: over 50 cm wire ~0.3 ohm<br />
<br />
Dimentions:<br />
* Flange height 7.67mm<br />
* Flange dia22.7mm<br />
* Axis length 19.4mm<br />
* Axis dia 1.9 mm<br />
* Statorheight 5.55mm<br />
* Stator diam 18.33mm<br />
<br />
Weight:<br />
* Flange weight 3.05g<br />
* Flange and magnets 5.15g (Magnet ~ 1.5mm thick on a Flange dia22.7mm)<br />
* Magnet only (and the glue) 2.1g<br />
<br />
====Bebop 2====<br />
* No dat (yet) It ould be nice if you could demolish on of your Bebop 2 motors or a spare one and add your data here.<br />
<br />
== Camera ==<br />
* Camera with "Fisheye" lens 180° 1/2,3": 6 optical elements and 14 Mega pixels sensor<br />
* Video stabilization: Digital on 3-axes<br />
* Video definition: 1920x1080p (30fps)<br />
* Photo definition: 3800x3188 pixels<br />
* Video encoding: H264<br />
* Photo file format: RAW, DNG<br />
* Internal memory: Flash 8 GB<br />
* Extended memory: Micro USB<br />
<br />
== Battery ==<br />
<br />
Bebop 1<br />
* Lithium Polymer 1200 mAh<br />
* Flight time: Around 12 minutes<br />
<br />
Bebop 2<br />
* Lithium Ion Polymer 2700 mAh<br />
* Flight time: Around 22 minutes<br />
* Max discharge rate 21.5A <br />
* Max charge rate 3.5A<br />
<br />
== Processor ==<br />
* Motherboard:<br />
** Parrot P7 dual-core CPU Cortex A9<br />
** Quad core GPU<br />
** 8Gb flash memory<br />
* All fixed on a magnesium shelf that acts as electromagnetic shielding and in the same run as a heat sink for heat dissipation and cooling of the all the onboard processors<br />
<br />
== Sensors ==<br />
* 3-axes magnetometer (AKM 8963)<br />
* 3-axes gyroscope (MPU 6050)<br />
* 3-axes accelerometer (MPU 6050)<br />
* Optical-flow sensor (Fig.8): Vertical stabilization camera (Every 16 milliseconds, an image of the ground is taken and compared to the previous one to determine the speed of the Bebop Drone)<br />
* Ultrasound sensor (Analyzes the flight altitude up to 8 meters)<br />
* Pressure sensor (MS 5607)<br />
<br />
== Geo-location ==<br />
* Bebop 1: GNSS (GPS + GLONASS + Galileo, [http://www.furuno.com/en/products/gnss-module/GN-87 Furuno GN-87F])<br />
* Bebop 2: GNSS (GPS + GLONASS + Galileo, Baidu, [https://www.u-blox.com/en/product/neo-m8-series])<br />
<br />
== Dimensions ==<br />
* 28x32x3.6cm without the hull<br />
* 33x38x3.6cm with the hull<br />
<br />
== Weight ==<br />
<br />
=== Bebop 1 ===<br />
* 380g without the hull<br />
* 400g with the hull<br />
<br />
=== Bebop 2 ===<br />
<br />
{| class="wikitable"<br />
! component<br />
! weight<br />
! quantity<br />
! <br />
! notes<br />
|-<br />
| motor<br />
| 16.5<br />
| 4<br />
| 66<br />
| with screws mounting motors<br />
|-<br />
| landing gear<br />
| 2.4<br />
| 4<br />
| 9.6<br />
| <br />
|-<br />
| frame<br />
| 49.5<br />
| 1<br />
| 49.5<br />
| with legs<br />
|-<br />
| rotor<br />
| 5.0<br />
| 4<br />
| 20<br />
| <br />
|-<br />
| battery<br />
| 196.0<br />
| 1<br />
| 196<br />
| <br />
|-<br />
| camera magnesium frame<br />
| 7.3<br />
| 1<br />
| 7.3<br />
| with all screws on it<br />
|-<br />
| camera<br />
| 14.7<br />
| 1<br />
| 14.7<br />
| <br />
|-<br />
| camera protector<br />
| 9.0<br />
| 1<br />
| 9<br />
| <br />
|-<br />
| GPS sensor module<br />
| 16.0<br />
| 1<br />
| 16<br />
| <br />
|-<br />
| foam cover<br />
| 7.2<br />
| 1<br />
| 7.2<br />
| <br />
|-<br />
| main board<br />
| 107.0<br />
| 1<br />
| 107<br />
| measured with all wires on it<br />
|-<br />
| Dampers<br />
| 2.1<br />
| 4<br />
| 8.4<br />
| dampers plus screws<br />
|-<br />
| <br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| Total<br />
| <br />
| <br />
| 510.7<br />
| (511,91 measured for another BB2)<br />
|}<br />
<br />
== OS/Software ==<br />
* Operating system: Linux (kernel 3.4.11 #3 SMP PREEMPT)<br />
* glibc: (Sourcery CodeBench Lite 2012.03-57) 2.15<br />
* libstdc++: GLIBCXX_3.4 - GLIBCXX_3.4.16<br />
<br />
= Pinout =<br />
== GPIO ==<br />
* 6 Fans Enable<br />
* 9 WiFi Reset<br />
* 73 P7MU IRQ<br />
* 81 GPS Power Enable<br />
* 85 Fan Enable<br />
* 89 VCAM FSYNC gyro<br />
* 90 HCAM FSYNC gyro<br />
* 91 DRDY MPU6050<br />
* 124 Magneto interrupt<br />
* 128 (video) Slew rate??<br />
* 129 VCAM enable<br />
* 130 (video) Slew rate??<br />
* 132 HCAM enable<br />
* 199 BLDC micro-controller reset (forces it into bootloader) ON/OFF<br />
* 200 US Pulse level<br />
* 201 On/Off button (default monitor to files running: /bin/onoffbutton)<br />
* 202 USB Host mode pin 3V3 (HOST_MODE_3V3)<br />
* 203 USB Host mode on<br />
* 204 USB0 OC<br />
<br />
== PWM ==<br />
* 6 Heating resistor for warming IMU sensors (125000ns period, 0ns duty)<br />
* 8 MPU6050 clock (31510ns period, 15258ns duty) Desired frequency is 32768kHz with 50% duty cycle (period=30517us). Period was set empirically to 31517 to get a 5ms data ready period. Desired frequency is slightly modified to synchronize camera and IMU<br />
* 9 Vertical camera clock (23ns period = 43MHz)<br />
* 11 Horizontal camera lock (77ns period = 13MHz)<br />
<br />
== I2C ==<br />
* I2C-0<br />
** FPGA<br />
** P7MU <br />
** EEPROM Unknown EEPROM for Front camera calibration (addr 0x55)<br />
** MT9f002 CMOS Digital Image Sensor (1/2.3 inch 14Mp, front camera) [http://www.onsemi.com/PowerSolutions/product.do?id=MT9F002 MT9f002] (addr 0x10)<br />
** MT9v117 CMOS Digital Image Sensor (1/6 inch VGA, bottom camera) [http://www.aptina.com/assets/downloadDocument.do?id=553 MT9v117] (addr 0x5d)<br />
* I2C-1<br />
** Cypress Motor Controller (Parrot BLDC) [[Bebop/BLDC]] (addr 0x08)<br />
** AKM8963 Magnetometer [http://www.akm.com/akm/en/file/datasheet/AK8963.pdf AK8963]<br />
** MS5607 Barometer [http://meas-spec.com/product/pressure/MS5607-02BA03.aspx MS5607]<br />
* I2C-2<br />
** MPU6050 Gyro + Accel [http://invensense.com/mems/gyro/documents/RM-MPU-6000A.pdf MPU6050] (rotation changed in version 2)<br />
<br />
== SPI ==<br />
* spidev1.0 Sonar (Only data pin connected for generating pulses)<br />
<br />
== UART ==<br />
* ttyPA1 GPS (Furuno GN-87F on v1 and Ublox Neo M8N on v2)<br />
<br />
== Other ==<br />
* /dev/hx280 Hantro (On2) Video encoder. Hantro chip video encoder used for the HCAM.<br />
* /sys/bus/iio/devices/iio:device0 (p7mu-adc_2) Sonar ADC<br />
<br />
= Actuators =<br />
The Bebop has 4 Brushless motors, which are controlled by the cypress chip on I2C-1. This Cypress chip contains custom made firmware(BLDC) by Parrot, which can be automatically updated using a bootloader in the ESC part of the mainboard.<br />
The firmware from Parrot contains a nice closed loop RPM control, which is automatically tuned inside the factory. <br />
Since version 2 Parrot changed the order and rotation direction of the motors.<br />
<br />
For more information about how to communicate with the BLDC look at [[Bebop/BLDC]]. Or take a look at the "bebop" actuator inside the <code>airborne/boards/bebop/</code> folder.<br />
<br />
= Onboard applications =<br />
<br />
The original programs on the Bebop<br />
<br />
* /usr/bin/dragon-prog Main program that controls the drone<br />
* /bin/watchdog.sh Checks if Dragon is still running and reboots dragon-prog if it somehow would not be running anymore <br />
<br />
* BLDC_Test_Bench Controls the Brushless Motor Controllers for testing and playing sounds etc.<br />
* bcmwl Everything with wifi<br />
* diagnostic Outputs sensor diagnostic<br />
* mk3_camera_eeprom Reads the front camera EEPROM<br />
* config_mt9v117 Configure the bottom camera<br />
<br />
= Cross compiler =<br />
For the Bebop you need to use a recent version GNU gcc-arm-linux-gnueabi (Ubuntu/Linaro 4.7.4-2ubuntu1) 4.7.4 provided with Ubuntu since 14.04 LTS.<br />
<br />
[http://electronics.stackexchange.com/questions/21594/is-code-sourcery-g-lite-still-a-viable-projectIn the past you could also crosscompile with Sourcery CodeBench Lite 2012.03-57 for ARM GNU/Linux from <s>Greedy</s> Mentor Graphics, previously called codesourcery. However the open'ness there is nowhere to be found anymore, so we'll say "No thanks" to Codesourcery ,now <s>Greedy</s> Mentor"]<br />
but if you [http://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2012.03-57-arm-none-linux-gnueabi.bin insist] , feel <s>free</s> restricted.<br />
<br />
= Tips & Tricks =<br />
<br />
== Video ==<br />
Make sure the [http://docs.paparazziuav.org/latest/module__video_rtp_stream.html video_rtp_stream.xml] module enabled in the airframe. <br />
Receive a video stream with e.g. avplay, vlc or a python app: <br />
$ avplay -loglevel quiet -max_delay 50 -fflags nobuffer rtp://192.168.42.1:5000<br />
$ vlc ~/paparazzi/var/sdp_tmp/192.168.42.1/stream.sdp<br />
$ ~/paparazzi/sw/tools/rtp_viewer/rtp_viewer.py<br />
<br />
== Factory Reset ==<br />
You can reset the Parrot Bebop Drone to factory settings. You '''will''' loose all your photos and movies recorded on your Bebop.<br />
To do this you need to press and hold the power button for 10 seconds. The LED will blink green and orange for a while, then green and the drone will shutdown.<br />
<br />
== Firmware ==<br />
Theoretically is is not important which firmware you use for Paparazzi to fly. But with the latest firware we get better Video imagery. So if you can.. use the latest firmware.<br />
<br />
The Paparazzi volunteers test flew the Bebop with Firmware v1.98.11 and v2.0.57, v3.0, v3.2, v3.3, v3.9, v4.0.6<br />
<br />
Note that under v4.0.x the Front cam doesn't work (yet..)nly whit a terrible cak to use the original encoder from the 3.9 firmware. so if you need video imagery and have a Bebop 2 do not update to v4.x just yet. Or better fix the camera not working issue...<br />
<br />
The v4.0.6 is the latest firmware version know as of 20170610 for Bebop 1. For bebop 2 Latest know is v4.0.6<br />
If even newer firmware is available please report any (if any) issues found related to the firmware on e.g. the mailinglist.<br />
<br />
== Damper ==<br />
The original Bebop2 damper are very soft and can cause oscillations around roll. You can print harder dampers from [http://www.thingiverse.com/thing:2135529 Thingiverse] yourself that will degrade the video quality but remove these oscillations. Use the _nodamp airframe files in that case.<br />
<br />
= Using the MicroUSB for serial data =<br />
<br />
The Bebop has this tiny USB connector just above the power button. This USB connector can also be used with help of a USB to Serial FTDI conversion board.<br />
To use the driver in current firmware OTG serving should be off. More information, photos, connection examples, sourcode and real life example of how to use this port.<br />
<br />
[[Category:Autopilots]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Developer_Guide&diff=23977Developer Guide2017-11-28T14:42:39Z<p>Ewoud: /* Coding Standards */</p>
<hr />
<div>==Introduction==<br />
<br />
By the time you land on this page, you probably want to enhance the Paparazzi project, that is really good for your karma and really appreciated by the Paparazzi community. We welcome contributions and improvements to the documentation.<br />
[[Image:FixIt.jpg|right|FixIt]]<br />
<br />
See also [[Doxygen]] for documentation close to the code.<br />
<br />
==[[Contributing|Contributing]]==<br />
You would like to contribute, but are not sure how, then [[Contributing|this is the page to visit]]<br />
<br />
==[[DevGuide/CodeEditors|Code Editing]]==<br />
How to setup your IDE for use with the source code<br />
<br />
==[[DevGuide/LearningToProgram|Learning to Program]]==<br />
Improve your Paparazzi code in OCAML,C,C++ and Python<br />
<br />
==[[DevGuide/AircraftBuildProcess|Aircraft build process and code generation]]==<br />
Description of the (rather complicated) build system and code generation regarding the airborne firmwares<br />
<br />
==[[DevGuide/DesignOverview|Design Overview]]==<br />
Attempt at a longer walk through the airborne code architecture<br />
<br />
==[[FirmwareArchitecture|Firmware Architecture]]==<br />
Attempt at brief overview of the firmware architecture with modules and subsystems<br />
<br />
==[[DevGuide/Communications|Communications]]==<br />
How telemetry and datalink is done<br />
<br />
==[[DevGuide/CommunicationsNew|Communications (Proposed New system)]]==<br />
How the telemetry and datalink works<br />
<br />
==[[DevGuide/Server_GCS_com|Server-GCS communications]]==<br />
How the Server and the Ground Control Station interact with each other<br />
<br />
==[[DevGuide/Values|Values]]==<br />
A short walk through the system and how values are handled<br />
<br />
==[[DevGuide/Settings|Settings]]==<br />
Settings is the generic mechanism that allows to set and get the value of any variable of the embedded code.<br />
<br />
==[[DevGuide/Mathlib|Paparazzi Math Library]]==<br />
The custom Paparazzi math library written in C and how to use it in external programs<br />
<br />
==[[Reference/bootloader]]==<br />
All of the questions and answers about the bootloader, but were afraid to ask<br />
<br />
===[[Lpc21iap|LPC USB firmware]]===<br />
All of the answers to the Paparazzi USB bootloader of question you never dared to ask<br />
<br />
====[[Lpc21BootloaderUpload|Upload Bootloader for LPC21xx]]====<br />
How to [[[[Lpc21BootloaderUpload|upload the Bootloader]] to a LPC2148 processor based Autopilot board like the TWOG<br />
<br />
===[[Luftboot|Upload the luftboot bootloader]]===<br />
How to upload the Bootloader to a STM32 processor based Autopilot board like the [[Elle0]] or [[Lisa/M]]<br />
<br />
===[[DFU|Upload with DFU (with native or custom dfu bootloader)]]===<br />
Using the native (embedded in ROM) or custom (e.g. [[Luftboot]] or [[KroozSD#Bootloader|KroozSD]]==) bootloader to upload Paparazzi code<br />
<br />
===[[STLink|Upload with STLink via SWD (without Bootloader)]]===<br />
General ST-LinkV2 page.<br />
<br />
==[[DevGuide/GDB_OpenOCD_Debug|GDB OpenOCD Debug]]==<br />
Using GDB or OpenOCD to directly flash and debug Hardware<br />
<br />
==[[DevGuide/USB-Serial|USB-Serial]]==<br />
Using a USB connection instead of UART for use with telemetry<br />
<br />
==[[ControlTheory]]==<br />
All [[ControlTheory|information you are looking for about the harsh reality of Control Theory]] needed to let your aircraft fly<br />
<br />
==[[Demystified/Altitude and Height|Altitude and Height]]==<br />
Altitude and Height demystified<br />
<br />
==[[Abi|AirBorne Interface ABI]]==<br />
Presentation of the airborne communication system<br />
<br />
==[[DevGuide/StateInterface]]==<br />
A stateinterface is a stateinterface is a stateinterface, [[DevGuide/StateInterface|poems aside read more about what the stateinterface entails here]]<br />
<br />
==[[RT_Paparazzi]]==<br />
[[RT_Paparazzi|Real Time Paparazzi]] how-to and guidelines<br />
<br />
==[[Builds|Continuous Integration builds]]==<br />
Info on the [[Builds|Continuous Integration builds]] (CI) server<br />
<br />
==Coding Standards==<br />
JPL (Jet Propulsion Laboratory) released their own coding standards (can be downloaded for free here: [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf JPL C Coding Standards and Guidelines]). They include MISRA-C rules and directives, but add their own rules on top of that. They also specify different levels of compliance (LOC) because not always it is necessary to comply with all of the rules. Anyway, they are making things that go to space, so we can definitely learn something about good coding practices from them.<br />
<br />
==[[DevGuide/Releasing]]==<br />
Info for maintainers on how to create a new release.<br />
<br />
[[Category:Developer_Documentation]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Lisa_Asctec_Bringup&diff=23975Lisa Asctec Bringup2017-11-28T14:31:46Z<p>Ewoud: </p>
<hr />
<div>This page describes the process of Assembling a Lisa on an Asctec frame with Asctec X-BL motor controllers and motors, from assembly to the first flight.<br />
<br />
- Poine/booz2_a6 : this is an hexarotor with mikrokopter motor controllers and running booz2 code in the stm32<br />
- Poine/booz2_a7 : this is an asctec quadrotor with astec motor controllers and running booz2 code in the stm32<br />
- Poine/booz2_a8 : this is a biplan with asctec motor controllers and using stm32 only as io processor - this one is in progress<br />
- esden/lisa_asctec : this is an asctec quadrotor with asctec motor controllers and running booz2 code in the stm32 using xtend based rc remote control.<br />
<br />
== Assembly ==<br />
<br />
[[Image:Lisa quad aluminium frame-disassembled.jpg|500px]]<br />
[[Image:Lisa quad aluminium frame-assembled.jpg|500px]]<br />
<br />
== Connectors ==<br />
<br />
* USART3 Spektrum RC sattelite<br />
* USART2 telemetry modem or PC<br />
<br />
== Compiling STM32 firmware ==<br />
<br />
make AIRCRAFT=LISA_ASCTEC clean_ac ap.compile<br />
<br />
== Flashing STM32 firmware ==<br />
<br />
make AIRCRAFT=LISA_ASCTEC ap.upload<br />
<br />
== Testing telemetry ==<br />
<br />
Start the paparazzi program launcher:<br />
./paparazzi<br />
<br />
Now you have to start a series of programs.<br />
<br />
=== datalink ===<br />
Connects the air network with the ground network. In our case it takes the serial data from USART2 and translates them to network packets.<br />
<br />
link -d /dev/ttyUSB1 -s 57600<br />
<br />
=== messages & realtime plotter ===<br />
This program is a "sniffer" it displays the packets going around on the ground network and displays them as numbers. You also may want to start the realtime plotter. You can drag values from the messages window into the realtime plotter to plot the data as a curve over time.<br />
<br />
=== settings & server ===<br />
Settings allows you to view configuration values on the vehicle. If you want to change any of them you will also need to start '''server''' that dispatches the data and transfers them to the vehicle. You need to tell the '''settings''' program what vehicle you are using:<br />
settings -ac LISA_ASCTEC<br />
<br />
=== GCS ===<br />
Last but not least you may want to start the '''GroundControlSoftware''' where you can view and control the autonomous flight data.<br />
<br />
== Spektrum Satellite Receiver ==<br />
You may need to make several changes to the 'sw/airborne/booz/radio_control/booz_radio_control_spektrum_dx7se.h' file. We created a new file called 'booz_radio_control_spektrum_dx7se_joby.h'. This file is included by adding the following line to the airframe file:<br />
<br />
ap.CFLAGS += -DRADIO_CONTROL_SPEKTRUM_MODEL_H=\"radio_control/booz_radio_control_spektrum_dx7se_joby.h\"<br />
<br />
If Lisa doesn't seem to be receiving from your Spektrum receiver, check<br />
#define RC_SPK_SYNC_2 0x12<br />
Our receiver's second sync bit was actually 0x01.<br />
<br />
Check the mapping and signs of the RC channels by viewing the paparazzi telemetry. You also want to include the kill switch channel if it is not already there. Our mapping and signs look like this:<br />
<br />
#define RADIO_CONTROL_ROLL 0<br />
#define RADIO_CONTROL_THROTTLE 5<br />
#define RADIO_CONTROL_PITCH 3<br />
#define RADIO_CONTROL_YAW 6<br />
#define RADIO_CONTROL_MODE 1<br />
#define RADIO_CONTROL_KILL_SWITCH 4<br />
<br />
#define RC_SPK_THROWS { MAX_PPRZ/MAX_SPK, \<br />
MAX_PPRZ/MAX_SPK, \<br />
-MAX_PPRZ/MAX_SPK, \<br />
-MAX_PPRZ/MAX_SPK, \<br />
MAX_PPRZ/MAX_SPK, \<br />
MAX_PPRZ/MAX_SPK, \<br />
MAX_PPRZ/MAX_SPK }<br />
<br />
== Motor Mapping ==<br />
Depending on which propellers are mounted where, you need to edit your airframe file (in the supervision section). Our mapping looked like this:<br />
<define name="ROLL_COEF" value="{ 0, 0, 256, -256 }"/><br />
<define name="PITCH_COEF" value="{ 256, -256, 0, 0 }"/><br />
<define name="YAW_COEF" value="{ -256, -256, 256, 256 }"/><br />
<define name="THRUST_COEF" value="{ 256, 256, 256, 256 }"/><br />
<br />
== Motor Controller Address ==<br />
at this moment you only can change the motor controller address when you implement asctec in you airframe file.<br />
<subsystem name="actuators" type="asctec"/><br />
Also when you have asctec_v2 motor controllers. <br />
so replace asctec_v2 by asctec when you want to program the motor controllers. <br />
!!! Do not forget to put asctec back to asctec_v2 when you want to fly!!!<br />
<br />
<br />
implement settings/settings_booz2_asctc.xml in the settings part of your airplane (done in paparazzi center). <br />
<br />
When you program the motor controllers for the first time you have to connect them one by one to the Lisa because they all have been programmed as front address .<br />
<br />
Power on your Lisa.<br />
<br />
In the GCS klick on the tab Settings-->asctec<br />
<br />
set cur_addr to the motor you want to reverse (first time FRONT)<br />
<br />
set new_addr to the motor you want it to be<br />
<br />
and than set cmd to SET_ADDR<br />
<br />
the set_addr commando will be sent 1 time to the motor controller.<br />
<br />
To test the motor, you have to replace the asctec back to asctec_v2 if you have asctec_v2 motor controllers.<br />
<br />
== Motor Spin Directions ==<br />
at this moment you only can change the spin direction when you implement asctec in you airframe file.<br />
<subsystem name="actuators" type="asctec"/><br />
Also when you have asctec_v2 motor controllers. <br />
so replace asctec_v2 by asctec when you want to program the motor controllers. <br />
!!! Do not forget to put asctec back to asctec_v2 when you want to fly!!!<br />
<br />
<br />
implement settings/settings_booz2_asctc.xml in the settings part of your airplane (done in paparazzi center). <br />
<br />
Connect all the motor controllers to the lisa (you first have to give them an unique address see Motor Controller Address)<br />
<br />
Power on your Lisa.<br />
<br />
In the GCS klick on the tab Settings-->asctec<br />
<br />
set cur_addr to the motor you want to reverse<br />
<br />
and than set cmd to reverse<br />
<br />
the reverse commando will be sent 1 time to the motor controller.<br />
<br />
To test the motor, you have to replace the asctec back to asctec_v2 if you have asctec_v2 motor controllers.<br />
<br />
== Check Motor Controllers ==<br />
The Asctec motor controller bypass capacitors are prone to damage. Replace them if they look dented, otherwise the motor controllers will not function.<br />
<br />
== Calibrate Accelerometers and Magnetometers ==<br />
See [[BoozSensorsCalibration]]. During the data aquisition stage, be sure to let the vehicle rest in each position. Don't hold it in your hand. This is because the calibration script checks the data for noise and drops data from noisy sections. If ALL your data is too noisy and gets dropped, the script will give you a "too many indices" error. This error may also occur when your logfile is empty.<br />
<br />
If your magnetometer data is too noisy (if you try to calibrate magnetometers when a computer or power supply is close by), the calibration script will take a very long time to run, and then it will give you incorrect results. Plot your data to see if it looks too noisy.<br />
<br />
The signs on the outputted sensor gains are dependent on the orientation of Booz IMU (the sensor board) relative to the main Lisa board. This correction will be automated in a future release.<br />
<br />
== Preflight Automatic Gyro Zeroing ==<br />
When you power up the vehicle for a flight, an LED on Lisa will blink quickly. Rest the vehicle on a flat surface until the LED goes solid. This indicates the vehicle is ready to fly and you can turn on the motors.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=SDLogger_SPI_Direct&diff=23974SDLogger SPI Direct2017-11-28T13:55:13Z<p>Ewoud: </p>
<hr />
<div>=Introduction=<br />
<br />
The direct SPI SD Logger is originally designed to be used with the Lisa/S, but should also be compatible with other supported autopilots. It connects directly to the SPI bus of the autopilot and communicates using the SDCards SPI interface. This method is slower than when using it in SD mode, but the speed is sufficient to log IMU data at 512 Hz.<br />
<br />
=Hardware=<br />
[[File:LisaSD.jpeg|thumbnail|Lisa/SD module]]<br />
<br />
== Installation ==<br />
<br />
The SD Card needs to be connected to the SPI bus of the autopilot. The pinout for an SD Card is shown in the figure.<br />
* VSS = Ground<br />
* VDD = 3.3V<br />
[[File:Microsd_pinout.png|left|microSD pinout ([http://elasticsheep.com/2010/01/reading-an-sd-card-with-an-atmega168/ source])]]<br />
<br />
<br clear="all" /> <br />
<br />
== KroozSD ==<br />
<br />
The KroozSD(BRE) board has a built in SD card slot connected over SPI bus to the controller. So all you need is to add the following:<br />
<load name="logger_sd_spi_direct.xml"><br />
<configure name="SDLOGGER_DIRECT_SPI" value="SPI1"/><br />
<configure name="SDLOGGER_DIRECT_SPI_SLAVE" value="SPI_SLAVE0"/><br />
<configure name="SDLOGGER_DIRECT_CONTROL_SWITCH" value="RADIO_CAM"/><br />
<configure name="LOGGER_LED" value="3"/><br />
</load><br />
to the modules section of your airframe file, choose the mx-16.xml as radio setup and insert the SD card into the board. In this case the logging should be started/stopped over the 8th channel of your radio control (set the proper switch on the 8th channel of your sender).<br />
<br />
== Lisa/SD ==<br />
<br />
A SuperbitRF-sized PCB connects the SD card to the Lisa/S. Additionally, this PCB has pads to connect a Deltang R31d RC receiver and a molex connector for general purpose.<br />
<br />
[[File:LisaSDback.jpeg|frame|x300px|left|Lisa/SD module with Deltang R31d]]<br />
<br />
=Software=<br />
<br />
=Retrieving the data=<br />
<br />
A logger is of no use if one can not easily retrieve the logged data. To make this a simple reality there is an app for that. <br />
<br />
# Connect the FTDI cable to the computer and autopilot.<br />
# Plug the battery or external power to the autopilot.<br />
# Start the logger download tool.<br />
<br />
The tool is found in this directory : sw/logalizer <br />
<br />
So a simple<br />
<br />
cd ~/paparazzi/sw/logalizer/ && ./sdlogger_download -a <AC_ID> -p /dev/ttyACM1 -b 115200<br />
<br />
where <AC_ID> is your aircraft ID, would start the process of reteiving the data from the SD card to your local machine, ready for you to use.<br />
<br />
[[Category:Modules]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=23958Working with INDI2017-11-28T10:43:03Z<p>Ewoud: </p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi_simple"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_CUTOFF" value="8.0"/><br />
<define name="ESTIMATION_FILT_CUTOFF" value="8.0"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
Make sure that in your configuration (in paparazzi center) the settings for different controllers, that are not used, are ''removed''. The variables in these settings are not declared, so they will cause errors.<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness (G1) is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Maximum Yaw Rate ==<br />
The yaw control is usually least effective on a quadrotor. Therefore, the yaw command can easily saturate. To avoid yaw overshoot because of this, you can specify a maximum yaw rate.<br />
<br />
== Filtering ==<br />
The angular acceleration is derived from the angular rate. In taking the derivative, noise is amplified. Therefore, the angular acceleration signal can be quite noisy, and filtering is practically always needed. For this purpose a second order filter is used. Such a filter adds a bit of delay to the signal. More filtering will give more delay. This delay will cause disturbances to be measured slightly later and hence be compensated later. If you are not logging the flight data and able to inspect what level of filtering is necessary, it is best not to change this.<br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. Note that the value of alpha depends on the frequency that this model runs! There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.<br />
<br />
== My drone is oscillating ==<br />
If your drone is oscillating or unstable, make sure you check the following (in this order):<br />
<br />
=== Changed inertia ===<br />
If you were flying before, but added something to the drone and now it is oscillating, you probably just need a different control effectiveness. You can try the online adaptation. Make sure that things are not loosely attached to the drone, as this will introduce extra dynamics. Rigid connections are preferred.<br />
<br />
=== The Actuator dynamics ===<br />
If you do not have actuator feedback, it is important to have an accurate actuator model. If you are unsure about your actuator model, it can be worthwhile to try to determine it.<br />
<br />
=== INDI loop vs PD controller ===<br />
<br />
Check if the oscillation comes from the INDI loop (control of angular acceleration) or from the PD controller that commands the reference angular acceleration. It can be that the angular acceleration reference is just too demanding.<br />
<br />
Do this by reducing both the P and D gains. If this does not resolve the issue, you can try holding the drone in your hand (if this can be done safe!) and reducing both P and D gains to zero. The drone will now try to keep zero angular acceleration. If the drone is still oscillating, probably the control effectiveness is wrong (see step 1). Else, try to find P and D values that give a fast response without oscillation.<br />
<br />
== 'Full' INDI ==<br />
<br />
The control described above is the slightly simplified version of INDI (indi_simple), because the controller can only give commands (roll, pitch, yaw, thrust), and does not have full control over each actuator.<br />
The 'control allocation' (which actuators to use for each controlled axis) is done with the static 'motor mixing matrix'.<br />
This is fine in most cases, but it can sometimes lead to problems.<br />
<br />
=== Limitations of indi_simple ===<br />
<br />
First and foremost, the effects of actuator saturation can be unpredictable.<br />
The controller outputs commands, but if some actuators saturate, these commands may not be achievable.<br />
Some commands have more priority than others, pitch and roll are usually more important than yaw for example.<br />
Because the actuators and the controller are decoupled in this setup, dealing with saturation is not possible.<br />
<br />
Second, if the control effectiveness of some of the actuators changes during flight, their new control effectiveness can be estimated with online parameter estimation.<br />
To use this new control effectiveness, there must be an online control allocation, as opposed to a static motor mixing.<br />
<br />
=== Using full INDI ===<br />
<br />
To give INDI access to the individual actuators, the command laws for the servos should use the array <code>actuators_pprz</code>, instead of the motor mixing.<br />
Example:<br />
<br />
<command_laws><br />
<set servo="TOP_LEFT" value="autopilot_get_motors_on() ? actuators_pprz[0] : -MAX_PPRZ"/><br />
<set servo="TOP_RIGHT" value="autopilot_get_motors_on() ? actuators_pprz[1] : -MAX_PPRZ"/><br />
<set servo="BOTTOM_RIGHT" value="autopilot_get_motors_on() ? actuators_pprz[2] : -MAX_PPRZ"/><br />
<set servo="BOTTOM_LEFT" value="autopilot_get_motors_on() ? actuators_pprz[3] : -MAX_PPRZ"/><br />
</command_laws><br />
<br />
Instead of indi_simple, add the stabilization module indi, with the option of RPM feedback (currently only for the bebop 1 and 2).<br />
<br />
<module name="stabilization" type="indi"><br />
<define name="INDI_RPM_FEEDBACK" value="TRUE"/><br />
</module><br />
<br />
In the STABILIZATION_ATTITUDE_INDI section, now the effect of each motor on each axis needs to be specified, like a matrix.<br />
The order is the same as the 'servo' order.<br />
Actuator dynamics can now be specified for each actuator separately.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_ROLL" value="{20 , -20, -20 , 20 }"/><br />
<define name="G1_PITCH" value="{14 , 14, -14 , -14 }"/><br />
<define name="G1_YAW" value="{-1, 1, -1, 1}"/><br />
<define name="G1_THRUST" value="{-.4, -.4, -.4, -.4}"/><br />
<!--Counter torque effect of spinning up a rotor--><br />
<define name="G2" value="{-61.2093, 65.3670, -65.7419, 65.4516}"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<define name="ESTIMATION_FILT_CUTOFF" value="4.0"/><br />
<define name="FILT_CUTOFF" value="5.0"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN" value="{0.1, 0.1, 0.1, 0.1}"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="TRUE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
<br />
<!--Priority for each axis (roll, pitch, yaw and thrust)--><br />
<define name="WLS_PRIORITIES" value="{1000, 1000, 1, 100}"/><br />
</section><br />
</source><br />
}}<br />
The adaptive parameter estimation will estimate each element of the G1 and G2 matrices, and can identify differences in actuator performance that are not obvious visual inspection of the airframe.<br />
<br />
=== WLS control allocation ===<br />
<br />
The control allocation with prioritization is incorporated in the form of an active set algorithm, using weighted least squares to determine priorities.<br />
The priorities can be edited with the <code>WLS_PRIORITIES</code> in the section above.<br />
If you do not define this, the default will prioritize pitch and roll, then thrust, and lastly yaw.<br />
This means that if actuators are saturating because of a yaw moment, the aircraft will gradually let go of the yaw control in order to maintain roll and pitch.<br />
<br />
By default, the WLS control allocation is used.<br />
If you want to use the pseudo-inverse to do the control allocation instead (does not take saturation into account!), then define:<br />
<br />
<define name="STABILIZATION_INDI_ALLOCATION_PSEUDO_INVERSE" value="TRUE"/></div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Subsystem/stabilization&diff=23929Subsystem/stabilization2017-11-28T08:54:04Z<p>Ewoud: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree><br />
== Stabilization subsystem ==<br />
The ''stabilization'' subsystem provides the attitude controller for rotorcrafts.<br />
<br />
Currently possible attitude ''stabilization'' subsystem types are<br />
* ''[[Subsystem/stabilization#Quaternion|int_quat]]''<br />
* ''[[Subsystem/stabilization#Quaternion|float_quat]]''<br />
* ''[[Subsystem/stabilization#Euler|int_euler]]''<br />
* ''[[Subsystem/stabilization#Euler|float_euler]]''<br />
* ''[[Subsystem/stabilization#INDI|indi]]''<br />
<br />
== Attitude Control Implementations ==<br />
There are several different attitude control algorithm implementations.<br />
<br />
They use the same ''STABILIZATION_ATTITUDE'' xml configuration section:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE" prefix="STABILIZATION_ATTITUDE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_PHI" value="45." unit="deg"/><br />
<define name="SP_MAX_THETA" value="45." unit="deg"/><br />
<define name="SP_MAX_R" value="90." unit="deg/s"/><br />
<define name="DEADBAND_A" value="0"/><br />
<define name="DEADBAND_E" value="0"/><br />
<define name="DEADBAND_R" value="250"/><br />
<br />
<!-- reference --><br />
<define name="REF_OMEGA_P" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_P" value="0.85"/><br />
<define name="REF_MAX_P" value="400." unit="deg/s"/><br />
<define name="REF_MAX_PDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_Q" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_Q" value="0.85"/><br />
<define name="REF_MAX_Q" value="400." unit="deg/s"/><br />
<define name="REF_MAX_QDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_R" value="500" unit="deg/s"/><br />
<define name="REF_ZETA_R" value="0.85"/><br />
<define name="REF_MAX_R" value="180." unit="deg/s"/><br />
<define name="REF_MAX_RDOT" value="RadOfDeg(1800.)"/><br />
<br />
<!-- feedback --><br />
<define name="PHI_PGAIN" value="1000"/><br />
<define name="PHI_DGAIN" value="400"/><br />
<define name="PHI_IGAIN" value="200"/><br />
<br />
<define name="THETA_PGAIN" value="1000"/><br />
<define name="THETA_DGAIN" value="400"/><br />
<define name="THETA_IGAIN" value="200"/><br />
<br />
<define name="PSI_PGAIN" value="500"/><br />
<define name="PSI_DGAIN" value="300"/><br />
<define name="PSI_IGAIN" value="10"/><br />
<br />
<!-- feedforward --><br />
<define name="PHI_DDGAIN" value="300"/><br />
<define name="THETA_DDGAIN" value="300"/><br />
<define name="PSI_DDGAIN" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
<br />
; ''SP_MAX_*'': maximum ''PHI''/''THETA'' (roll/pitch) angles and maximum angular velocity ''R'' around yaw axis<br />
; ''DEADBAND_*'': RC stick deadband around the center for ''A'',''E'',''R'' (roll,pitch,yaw)<br />
; ''REF_*'': parameters for the [[Control_Loops#Reference_generators_2|reference generator]]<br />
; ''REF_OMEGA_*'' : second order model natural frequency for respective axis<br />
; ''REF_ZETA_*'' : second order model damping factor for respective axis<br />
; ''REF_MAX_x'' : bound on ref model angular speed<br />
; ''REF_MAX_xDOT'' : bound on ref model angular acceleration<br />
; ''[PHI|THETA|PSI]_[PID]GAIN'': gains for the feedback control of the respective axis<br />
; ''[PHI|THETA|PSI]_DDGAIN'': feedforward gains for the respective axis<br />
<br />
=== Quaternion ===<br />
Attitude controllers using quaternions (no gimbal lock).<br />
There is a fixed point implementation (recommended) and a floating point implementation for reference and testing.<br />
<br />
* fixed point: <source lang="xml"><subsystem name="stabilization" type="int_quat"/></source><br />
* floating point: <source lang="xml"><subsystem name="stabilization" type="float_quat"/></source><br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_quat"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== Euler ===<br />
Attitude controller using Euler Angles. Due to the inherent singularities (e.g. 90deg pitch) of the euler angles representation you can't use this controller if you want to fly in regimes close or at these singularities (e.g. acrobatics or transitioning vehicles).<br />
See [[Control_Loops#Attitude_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_euler"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== INDI ===<br />
Attitude controller based on an Incremental Nonlinear Dynamic Inversion inner loop. It controls the angular acceleration in an incremental way. Detailed information can be found in the paper 'Adaptive Incremental Nonlinear Dynamic Inversion for Micro Aerial Vehicles' (http://arc.aiaa.org/doi/abs/10.2514/1.G001490).<br />
<br />
The idea is that any moment on the drone, results in an angular acceleration. With the onboard gyroscope, we measure the angular rate. This means that if we take the derivative of the angular rate, we have a measure of all moments on the drone through the angular acceleration. This includes the moment caused by the inputs. We know what the angular acceleration is with the inputs that we are giving, so to change the angular acceleration to a desired value, we just need to increment these inputs. How much we should increment the inputs to get a certain increment in angular acceleration is determined by the ''control effectiveness''.<br />
<br />
The benefit of using INDI over PID is that the disturbance rejection is a lot faster. This means that an external moment on the drone due to wind or something else is counteracted as fast as the drone can measure it and the actuators can move. Compare this to the integrator gain of a PID controller, that only slowly removes steady state offsets.<br />
<br />
More practical information can be found on [[working with INDI]]<br />
<br />
== Rate Control ==<br />
You can also control the rotation rates of the vehicle with the RC, instead of using full (self-leveling) attitude control.<br />
For the control method, it is possible to choose a PI controller, by specifying <code>type="rate"</code>, or INDI control, by specifying <code>type="rate_indi"</code>, like in the example below.<br />
See [[Control_Loops#Rate_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<module name="stabilization" type="rate"/><br />
</firmware><br />
<br />
<section name="STABILIZATION_RATE" prefix="STABILIZATION_RATE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_P" value="10000"/><br />
<define name="SP_MAX_Q" value="10000"/><br />
<define name="SP_MAX_R" value="10000"/><br />
<define name="DEADBAND_P" value="20"/><br />
<define name="DEADBAND_Q" value="20"/><br />
<define name="DEADBAND_R" value="200"/><br />
<define name="REF_TAU" value="4"/><br />
<br />
<!-- feedback --><br />
<define name="GAIN_P" value="400"/><br />
<define name="GAIN_Q" value="400"/><br />
<define name="GAIN_R" value="350"/><br />
<br />
<define name="IGAIN_P" value="75"/><br />
<define name="IGAIN_Q" value="75"/><br />
<define name="IGAIN_R" value="50"/><br />
<br />
<!-- feedforward --><br />
<define name="DDGAIN_P" value="300"/><br />
<define name="DDGAIN_Q" value="300"/><br />
<define name="DDGAIN_R" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
[[Category:User_Documentation]] [[Category:Subsystems]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Subsystem/stabilization&diff=23928Subsystem/stabilization2017-11-28T08:52:55Z<p>Ewoud: rate control also possible with indi</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree><br />
== Stabilization subsystem ==<br />
The ''stabilization'' subsystem provides the attitude controller for rotorcrafts.<br />
<br />
Currently possible attitude ''stabilization'' subsystem types are<br />
* ''[[Subsystem/stabilization#Quaternion|int_quat]]''<br />
* ''[[Subsystem/stabilization#Quaternion|float_quat]]''<br />
* ''[[Subsystem/stabilization#Euler|int_euler]]''<br />
* ''[[Subsystem/stabilization#Euler|float_euler]]''<br />
* ''[[Subsystem/stabilization#INDI|indi]]''<br />
<br />
== Attitude Control Implementations ==<br />
There are several different attitude control algorithm implementations.<br />
<br />
They use the same ''STABILIZATION_ATTITUDE'' xml configuration section:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE" prefix="STABILIZATION_ATTITUDE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_PHI" value="45." unit="deg"/><br />
<define name="SP_MAX_THETA" value="45." unit="deg"/><br />
<define name="SP_MAX_R" value="90." unit="deg/s"/><br />
<define name="DEADBAND_A" value="0"/><br />
<define name="DEADBAND_E" value="0"/><br />
<define name="DEADBAND_R" value="250"/><br />
<br />
<!-- reference --><br />
<define name="REF_OMEGA_P" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_P" value="0.85"/><br />
<define name="REF_MAX_P" value="400." unit="deg/s"/><br />
<define name="REF_MAX_PDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_Q" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_Q" value="0.85"/><br />
<define name="REF_MAX_Q" value="400." unit="deg/s"/><br />
<define name="REF_MAX_QDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_R" value="500" unit="deg/s"/><br />
<define name="REF_ZETA_R" value="0.85"/><br />
<define name="REF_MAX_R" value="180." unit="deg/s"/><br />
<define name="REF_MAX_RDOT" value="RadOfDeg(1800.)"/><br />
<br />
<!-- feedback --><br />
<define name="PHI_PGAIN" value="1000"/><br />
<define name="PHI_DGAIN" value="400"/><br />
<define name="PHI_IGAIN" value="200"/><br />
<br />
<define name="THETA_PGAIN" value="1000"/><br />
<define name="THETA_DGAIN" value="400"/><br />
<define name="THETA_IGAIN" value="200"/><br />
<br />
<define name="PSI_PGAIN" value="500"/><br />
<define name="PSI_DGAIN" value="300"/><br />
<define name="PSI_IGAIN" value="10"/><br />
<br />
<!-- feedforward --><br />
<define name="PHI_DDGAIN" value="300"/><br />
<define name="THETA_DDGAIN" value="300"/><br />
<define name="PSI_DDGAIN" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
<br />
; ''SP_MAX_*'': maximum ''PHI''/''THETA'' (roll/pitch) angles and maximum angular velocity ''R'' around yaw axis<br />
; ''DEADBAND_*'': RC stick deadband around the center for ''A'',''E'',''R'' (roll,pitch,yaw)<br />
; ''REF_*'': parameters for the [[Control_Loops#Reference_generators_2|reference generator]]<br />
; ''REF_OMEGA_*'' : second order model natural frequency for respective axis<br />
; ''REF_ZETA_*'' : second order model damping factor for respective axis<br />
; ''REF_MAX_x'' : bound on ref model angular speed<br />
; ''REF_MAX_xDOT'' : bound on ref model angular acceleration<br />
; ''[PHI|THETA|PSI]_[PID]GAIN'': gains for the feedback control of the respective axis<br />
; ''[PHI|THETA|PSI]_DDGAIN'': feedforward gains for the respective axis<br />
<br />
=== Quaternion ===<br />
Attitude controllers using quaternions (no gimbal lock).<br />
There is a fixed point implementation (recommended) and a floating point implementation for reference and testing.<br />
<br />
* fixed point: <source lang="xml"><subsystem name="stabilization" type="int_quat"/></source><br />
* floating point: <source lang="xml"><subsystem name="stabilization" type="float_quat"/></source><br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_quat"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== Euler ===<br />
Attitude controller using Euler Angles. Due to the inherent singularities (e.g. 90deg pitch) of the euler angles representation you can't use this controller if you want to fly in regimes close or at these singularities (e.g. acrobatics or transitioning vehicles).<br />
See [[Control_Loops#Attitude_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_euler"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== INDI ===<br />
Attitude controller based on an Incremental Nonlinear Dynamic Inversion inner loop. It controls the angular acceleration in an incremental way. Detailed information can be found in the paper 'Adaptive Incremental Nonlinear Dynamic Inversion for Micro Aerial Vehicles' (http://arc.aiaa.org/doi/abs/10.2514/1.G001490).<br />
<br />
The idea is that any moment on the drone, results in an angular acceleration. With the onboard gyroscope, we measure the angular rate. This means that if we take the derivative of the angular rate, we have a measure of all moments on the drone through the angular acceleration. This includes the moment caused by the inputs. We know what the angular acceleration is with the inputs that we are giving, so to change the angular acceleration to a desired value, we just need to increment these inputs. How much we should increment the inputs to get a certain increment in angular acceleration is determined by the ''control effectiveness''.<br />
<br />
The benefit of using INDI over PID is that the disturbance rejection is a lot faster. This means that an external moment on the drone due to wind or something else is counteracted as fast as the drone can measure it and the actuators can move. Compare this to the integrator gain of a PID controller, that only slowly removes steady state offsets.<br />
<br />
More practical information can be found on [[working with INDI]]<br />
<br />
== Rate Control ==<br />
You can also control the rotation rates of the vehicle with the RC, instead of using full (self-leveling) attitude control.<br />
For the control method, it is possible to choose a PI controller, by specifying <code>type="rate"</code> or <code>type="rate_indi"</code>, like in the example below.<br />
See [[Control_Loops#Rate_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<module name="stabilization" type="rate"/><br />
</firmware><br />
<br />
<section name="STABILIZATION_RATE" prefix="STABILIZATION_RATE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_P" value="10000"/><br />
<define name="SP_MAX_Q" value="10000"/><br />
<define name="SP_MAX_R" value="10000"/><br />
<define name="DEADBAND_P" value="20"/><br />
<define name="DEADBAND_Q" value="20"/><br />
<define name="DEADBAND_R" value="200"/><br />
<define name="REF_TAU" value="4"/><br />
<br />
<!-- feedback --><br />
<define name="GAIN_P" value="400"/><br />
<define name="GAIN_Q" value="400"/><br />
<define name="GAIN_R" value="350"/><br />
<br />
<define name="IGAIN_P" value="75"/><br />
<define name="IGAIN_Q" value="75"/><br />
<define name="IGAIN_R" value="50"/><br />
<br />
<!-- feedforward --><br />
<define name="DDGAIN_P" value="300"/><br />
<define name="DDGAIN_Q" value="300"/><br />
<define name="DDGAIN_R" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
[[Category:User_Documentation]] [[Category:Subsystems]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=23815Working with INDI2017-08-10T14:27:12Z<p>Ewoud: </p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi_simple"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_CUTOFF" value="8.0"/><br />
<define name="ESTIMATION_FILT_CUTOFF" value="8.0"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
Make sure that in your configuration (in paparazzi center) the settings for different controllers, that are not used, are ''removed''. The variables in these settings are not declared, so they will cause errors.<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness (G1) is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Maximum Yaw Rate ==<br />
The yaw control is usually least effective on a quadrotor. Therefore, the yaw command can easily saturate. To avoid yaw overshoot because of this, you can specify a maximum yaw rate.<br />
<br />
== Filtering ==<br />
The angular acceleration is derived from the angular rate. In taking the derivative, noise is amplified. Therefore, the angular acceleration signal can be quite noisy, and filtering is practically always needed. For this purpose a second order filter is used. Such a filter adds a bit of delay to the signal. More filtering will give more delay. This delay will cause disturbances to be measured slightly later and hence be compensated later. If you are not logging the flight data and able to inspect what level of filtering is necessary, it is best not to change this.<br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. Note that the value of alpha depends on the frequency that this model runs! There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.<br />
<br />
== My drone is oscillating ==<br />
If your drone is oscillating or unstable, make sure you check the following (in this order):<br />
<br />
=== Changed inertia ===<br />
If you were flying before, but added something to the drone and now it is oscillating, you probably just need a different control effectiveness. You can try the online adaptation. Make sure that things are not loosely attached to the drone, as this will introduce extra dynamics. Rigid connections are preferred.<br />
<br />
=== The Actuator dynamics ===<br />
If you do not have actuator feedback, it is important to have an accurate actuator model. If you are unsure about your actuator model, it can be worthwhile to try to determine it.<br />
<br />
=== INDI loop vs PD controller ===<br />
<br />
Check if the oscillation comes from the INDI loop (control of angular acceleration) or from the PD controller that commands the reference angular acceleration. It can be that the angular acceleration reference is just too demanding.<br />
<br />
Do this by reducing both the P and D gains. If this does not resolve the issue, you can try holding the drone in your hand (if this can be done safe!) and reducing both P and D gains to zero. The drone will now try to keep zero angular acceleration. If the drone is still oscillating, probably the control effectiveness is wrong (see step 1). Else, try to find P and D values that give a fast response without oscillation.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=23758Working with INDI2017-07-25T09:38:16Z<p>Ewoud: /* Example Airframe Section */</p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi_simple"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_CUTOFF" value="8.0"/><br />
<define name="ESTIMATION_FILT_CUTOFF" value="8.0"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
Make sure that in your configuration (in paparazzi center) the settings for different controllers, that are not used, are ''removed''. The variables in these settings are not declared, so they will cause errors.<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness (G1) is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Maximum Yaw Rate ==<br />
The yaw control is usually least effective on a quadrotor. Therefore, the yaw command can easily saturate. To avoid yaw overshoot because of this, you can specify a maximum yaw rate.<br />
<br />
== Filtering ==<br />
The angular acceleration is derived from the angular rate. In taking the derivative, noise is amplified. Therefore, the angular acceleration signal can be quite noisy, and filtering is practically always needed. For this purpose a second order filter is used. Such a filter adds a bit of delay to the signal. More filtering will give more delay. This delay will cause disturbances to be measured slightly later and hence be compensated later. If you are not logging the flight data and able to inspect what level of filtering is necessary, it is best not to change this.<br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.<br />
<br />
== My drone is oscillating ==<br />
If your drone is oscillating or unstable, make sure you check the following (in this order):<br />
<br />
=== Changed inertia ===<br />
If you were flying before, but added something to the drone and now it is oscillating, you probably just need a different control effectiveness. You can try the online adaptation. Make sure that things are not loosely attached to the drone, as this will introduce extra dynamics. Rigid connections are preferred.<br />
<br />
=== The Actuator dynamics ===<br />
If you do not have actuator feedback, it is important to have an accurate actuator model. If you are unsure about your actuator model, it can be worthwhile to try to determine it.<br />
<br />
=== INDI loop vs PD controller ===<br />
<br />
Check if the oscillation comes from the INDI loop (control of angular acceleration) or from the PD controller that commands the reference angular acceleration. It can be that the angular acceleration reference is just too demanding.<br />
<br />
Do this by reducing both the P and D gains. If this does not resolve the issue, you can try holding the drone in your hand (if this can be done safe!) and reducing both P and D gains to zero. The drone will now try to keep zero angular acceleration. If the drone is still oscillating, probably the control effectiveness is wrong (see step 1). Else, try to find P and D values that give a fast response without oscillation.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Module/guidance_vector_field&diff=23639Module/guidance vector field2017-03-24T11:58:22Z<p>Ewoud: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree><br />
<br />
== Introduction ==<br />
We have written an algorithm for solving the problem of tracking smooth curves by an unmanned aerial vehicle travelling with a constant airspeed and under a wind disturbance. The algorithm is based on the idea of following a guiding vector field which is constructed from the implicit function that describes the desired (possibly time-varying) trajectory. <br />
<br />
For fixed-wings the output of the algorithm can be directly expressed in terms of the bank angle of the UAV in order to achieve coordinated turns. Furthermore, the algorithm can be tuned offline such that physical constraints of the UAV, e.g., the maximum bank angle, will not be violated in a neighborhood of the desired trajectory.<br />
<br />
The implementation for rotorcraft is still in the TO DO list.<br />
<br />
This work is based on the paper [https://arxiv.org/abs/1610.02797 Guidance algorithm for smooth trajectory tracking of a fixed wing UAV flying in wind flows], presented at ICRA 2017. A more rigorous and detailed analysis can be found in the paper [https://www.researchgate.net/publication/309191959_A_guiding_vector_field_algorithm_for_path_following_control_of_nonholonomic_mobile_robots A guiding vector field algorithm for path following control of nonholonomic mobile robots].<br />
<br />
We can further exploit the convergence properties of the fixed-wing aircraft to the desired trajectory for controlling formations of several aircraft. Check the subsection python Apps. A detailed analysis can be found in the paper [https://www.researchgate.net/publication/315514301_Circular_formation_control_of_fixed-wing_UAVs_with_constant_speeds Circular formation control of fixed-wing UAVs with constant speeds] (submitted to IROS 2017). A video about how the circular formation algorithm works https://www.youtube.com/watch?v=q4b8JRU1Gbw .<br />
<br />
Here we show an animation of an airplane following an ellipse and a sinudoidal track.<br />
[[File:gvfGif.gif|center]]<br />
<br />
== How does the algorithm work? ==<br />
We start from the implicit equation of the trajectory, for example for a circumference we have that <math>\varphi(x,y) = x^2 + y^2 - R^2</math>, where <math>x, y</math> and <math>R</math> are the x, y coordinates with respect to HOME (<math>O</math> in the following figure) and R is the radius of the circumference. Note that when the vehicle is over the desired trajectory, then <math>\varphi(x,y) = 0</math>, otherwise it will be different from zero. We will use this concept of "level set" to define the notion of distance to the trajectory, namely <math>e := \varphi(x,y)</math>. It has to be noted that this is different from the Euclidean distance (see figure below).<br />
<br />
For the sake of clarity we will consider just 2D trajectories and parallel to the ground. Let us stack the x and y coordinates in <math>p := \begin{bmatrix}x & y\end{bmatrix}^T</math> and consider the following kinematical model for our vehicle<br />
<br />
<math>\begin{cases} \dot p &= sm(\psi) + w \\ \dot\psi &= u, \end{cases}</math><br />
<br />
where <math>s\in\mathbb{R}^+</math> is a constant that can be considered as the airspeed, <math>m = \begin{bmatrix}\cos(\psi) & \sin(\psi)\end{bmatrix}^T</math> with <math>\psi\in(-\pi, \pi]</math> being the attitude yaw angle, <math>w\in\mathbb{R}^2</math> is a constant with respect to <math>O</math> representing the wind and <math>u</math> is the control action that will make the vehicle to turn. We also notice that the course heading <math>\chi\in(-\pi, \pi]</math>, i.e. the direction the velocity vector <math>\dot p</math> is pointing at, in general is different from the yaw angle <math>\psi</math> because of the wind.<br />
<br />
[[File:GVF.png|center]]<br />
<br />
Given a desired trajectory, we compute its normal <math>n(p) := \nabla \varphi(p)</math> and its tangent <math>\tau(p) = En(p), \quad E=\begin{bmatrix}0 & 1 \\ -1 & 0\end{bmatrix}</math>. The idea is to steer the vehicle such that it follows the direction given by the unit vector calculated from <br />
<br />
<math>\dot p_d(p) := \tau(p) - k_e e(p)n(p),</math><br />
<br />
where <math>k_e</math> is a positive gain. At each point <math>p</math> we can build a unit vector from <math>\dot p_d(p)</math>. This collection of vectors is our Guidance Vector Field. Note that when the error is zero, then we are just tracking the tangent to the trajectory.<br />
<br />
We assume that the trajectory is twice differentiable (so its gradient and Hessian exists) and that it is regular in a neighborhood of <math>\mathcal{P}</math>, i.e.<br />
<br />
<math>\nabla\varphi(p) \neq 0, \quad p\in \mathcal{N}_{\mathcal{P}},\quad \mathcal{N}_{\mathcal{P}} := \{p \, : \, |\varphi(p)| \leq c^* > 0\}</math>.<br />
<br />
<br />
The algorithm needs for work the measurements of <math>\dot p</math> (typically derived from GPS), position <math>p</math> w.r.t. HOME (typically derived from GPS) and yaw angle <math>\psi</math> or sideslip angle <math>\beta = (\psi - \chi)</math>. The algorithm still works quite well in practice with only <math>\dot p</math> and <math>p</math>, in other words, you will only need to have installed a GPS. The latter is the implemented version in pprz/master.<br />
<br />
== Using the GVF in the flight plan ==<br />
<br />
{TODO: to enumerate all the functions available for the user.}<br />
<br />
So far we have added support for two kind of trajectories, ellipses and sinusoidals. Note that the former includes circumferences and the latter includes<br />
straight lines (zero frequency).<br />
<br />
For tracking an ellipse, one has to call the function<br />
<source lang="html"><br />
<call fun="gvf_ellipse(WP_STDBY, gvf_ellipse_a, gvf_ellipse_b, gvf_ellipse_alpha)"/><br />
</source><br />
where gvf_ellipse_a (horizontal axis), gvf_ellipse_b (vertical axis), gvf_ellipse_alpha (rotation w.r.t. North) can be defined in your settings file. <br />
<br />
<br />
For tracking a straight line that crosses HOME with course heading 45 degrees <br />
<source lang="html"><br />
<call fun="gvf_line_wp_heading(WP_HOME, 45)"/><br />
</source><br />
<br />
<br />
For tracking a sinusoidal, the same as the straight line but including the additional information about frequency, offset and amplitude (in meters)<br />
<source lang="html"><br />
<call fun="gvf_sin_wp_heading(WP_HOME, course_heading, freq, off_set, amplitude)"/><br />
</source><br />
<br />
<br />
For setting the tracking direction (the direction of the tangent vector <math>\tau</math> in the above figure)<br />
<source lang="html"><br />
<call fun="gvf_set_direction(s)"/><br />
</source><br />
where s is an integer number 1 or -1.<br />
<br />
== Gain tuning ==<br />
<br />
The user has to tune two gains <math>k_n, k_e</math>. The former one determines the convergence rate for aligning the vehicle to the vector field. A typical value for starting tuning <math>k_n</math> should be between 0.2 and 1. The latter gain determines how aggressive is the vector field. For example, in the following figure we have an ellipse with two different values of <math>k_e</math>, at the left we have a value of 3 and at the right 0.4. Note how in left one the vectors are "more aggressive" towards the trajectory. While a big value can make the vehicle to converge quickly to the trajectory, it can make the tracking unstable once the vehicle is close it. This is because the vector field might change so quick that physically the vehicle cannot follow it. Check the Section IV in the original paper in the introduction.<br />
<br />
It is a good practice in the flight plan to set the gains before calling the trajectory since it is pretty common to have different gains for different trajectories. For example<br />
<source lang="html"><br />
<call fun="gvf_set_direction(s)"/><br />
<call fun="gvf_set_gains(ke, kn)"/><br />
<call fun="gvf_ellipse(WP_STDBY, gvf_ellipse_a, gvf_ellipse_b, gvf_ellipse_alpha)"/><br />
</source><br />
<br />
<br />
== Python Apps == <br />
<br />
=== Visualizing the desired trajectory and the aircraft within the vector field===<br />
Until the "visual integration" of the GVF into the ground station is ready, one can track the vehicle and the trajectory by using the python script at "$PAPARAZZI_HOME/sw/ground_segment/python/gvf/gvfApp ac_id", where ac_id is the ID of the fixedwing to be tracked by the App.<br />
<br />
<gallery mode=packed heights=300px><br />
File:gvf_ellipse.png<br />
File:gvf_Sin.png<br />
</gallery><br />
<br />
=== Circular formations ===<br />
One can synchronize or arrange a group of fixed-wing aircraft (assuming they have equal ground speed) in a desired circle by using the python script at "$PAPARAZZI_HOME/sw/ground_segment/python/gvf/gvfFormation". For running the script, all your aircraft '''MUST''' follow a circle employing the guidance vector field, i.e., <br />
<source lang="html"><br />
<call fun="gvf_ellipse(WP_STDBY, gvf_ellipse_a, gvf_ellipse_b, gvf_ellipse_alpha)"/><br />
</source><br />
the values of gvf_ellipse_a, gvf_ellipse_b will be modified by the formation control script, and the value of gvf_ellipse_alpha is irrelevant. Note that the aircraft do not need necessarily to orbit around the same waypoint. <br />
<br />
We need three text files in order to run the script:<br />
* ids.txt , which labels the aircrafts. For example, if the file contains '14 56 34', then the aircraft with ids 14, 56 and 34 are labeled with the tags 1, 2 and 3 respectively.<br />
* topology.txt , which defines the links between the aircraft. The file contains a matrix where the number of rows is the number of aircraft, and the number of columns is the number of desired links. A link is defined by setting 1 and -1 in a column. Following the example, the matrix <math>\begin{bmatrix}1 & 0 \\ -1 & 1 \\ 0 & -1\end{bmatrix}</math> defines two links. The first one between the aircraft 1 and 2, and the second one between the aircraft 2 and 3.<br />
* sigmas.txt , which defines the desired angles <math>\sigma_k</math> between aircraft for each link <math>k</math>. Following the example, if the file contains '0 90', then the desired angle for the first link is 0 degrees (e.g., the aircraft 1 and 2 will meet each other) and the second desired angle will be +90 degrees (positive is clock-wise).<br />
<br />
Some useful tips:<br />
* How you place 1 and -1 in the topology matters in the following sense. In our example, for the second link, the +90 degrees is from the aircraft 2 to the aircraft 3. If the topology were <math>\begin{bmatrix}1 & 0 \\ -1 & -1 \\ 0 & 1\end{bmatrix}</math>, then the +90 degrees will be from the aircraft 3 to the aircraft 2.<br />
* Watch out for "impossible" configurations, e.g., do not set up loops in the topology such as 1 -> 2 -> 3 -> 1 <math>\begin{bmatrix}1 & 0 & -1\\ -1 & 1 & 0 \\ 0 & -1 & 1\end{bmatrix}</math>, so the desired sigmas could be asking for an impossible configuration in the circle. Avoid loops! even if the desired configuration is ok, they can introduce undesired equilibria in the system, i.e., different configurations.<br />
* The aircraft do not need to share the same center or waypoint. This script just control the sigmas.<br />
<br />
The script needs two additional scalar values:<br />
* radius , sets the desired radius of the circular formation, i.e., once the aircraft are synchronized, they will be orbiting the waypoint with this desired radius.<br />
* k, this is the gain of the control algorithm. As an example, for three aircraft with a desired circumference of 80 meters, a value of <math>k=10</math> works ok.<br />
<br />
The algorithm works by setting different radii to the aircraft. If two aircraft orbit a waypoint with different radius (assuming equal ground speeds), then the one with bigger radius travels more distance in a completed lap. We exploit this fact in order to control the different <math>\sigma_k</math>. We refer to [https://www.researchgate.net/publication/315514301_Circular_formation_control_of_fixed-wing_UAVs_with_constant_speeds Circular formation control of fixed-wing UAVs with constant speeds] for details about the control signal and how to calculate an appropriated gain k.<br />
<br />
In the following figure we show the rendezvous of three aircraft in the same circle by using this script.<br />
<br />
[[File:Circular.png|center]]<br />
<br />
== Defining your own trajectory ==<br />
<br />
The algorithm is placed in $PAPARAZZI_HOME/sw/airborne/modules/guidance/gvf .<br />
The trajectories are placed in $PAPARAZZI_HOME/sw/airborne/modules/guidance/gvf/trajectories .<br />
<br />
Here there is an example (the straight line) about how to code your own trajectory.<br />
You need to add at least two functions in the header<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/gvf.h<br />
<source lang="c"><br />
// Straigh line<br />
void gvf_line(float x, float y, float alpha);<br />
extern bool gvf_line_wp1_wp2(uint8_t wp1, uint8_t wp2);<br />
extern bool gvf_line_wp_heading(uint8_t wp, float alpha);<br />
</source><br />
}}<br />
<br />
where the first function will be called by the algorithm and the rest by the user in the flight plan. For example, the user in the flight plan <br />
calls to gvf_line_wp_heading<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/gvf.c<br />
<source lang="c"><br />
bool gvf_line_wp_heading(uint8_t wp, float alpha)<br />
{<br />
alpha = alpha*M_PI/180;<br />
<br />
float a = waypoints[wp].x;<br />
float b = waypoints[wp].y;<br />
<br />
gvf_line(a, b, alpha);<br />
<br />
return true;<br />
}<br />
</source><br />
}}<br />
<br />
The idea is that while you can define a straight line in many different ways, you make all the transformations<br />
in the function called by the user such that the algorithm is always evaluating the trajectory in the same way. It helps for maintaining the code and for tuning<br />
the gains (you do not want to have different set of gains depending on how you call your trajectory). <br />
<br />
We finally call the function gvf_line (hidden for the user) that will invoke the algorithm.<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/gvf.c<br />
<source lang="c"><br />
void gvf_line(float a, float b, float alpha)<br />
{<br />
float e;<br />
struct gvf_grad grad_line;<br />
struct gvf_Hess Hess_line;<br />
<br />
gvf_traj_type = 0;<br />
gvf_param[0] = a;<br />
gvf_param[1] = b;<br />
gvf_param[2] = alpha;<br />
<br />
gvf_line_info(&e, &grad_line, &Hess_line);<br />
gvf_control_2D(1e-2*gvf_ke, gvf_kn, e, &grad_line, &Hess_line);<br />
<br />
gvf_error = e;<br />
}<br />
</source><br />
}}<br />
<br />
The three first lines are the <math>\varphi(p), \nabla\varphi(p)</math> and <math>H(\varphi(p))</math>, where <math>H</math> stands for the Hessian. These three<br />
guys will be populated by gvf_line_info (in a moment we will be see how to write it).<br />
<br />
Then gvf_traj_type stands for the kind of trajectory. Right now we have 0 for lines, 1 for ellipses and 2 for sinusoidals. Feel free to choose an index that has not been taken. The rest gvf_param[x]'s are the parameters of the trajectory. You have up to seven for describing a trajectory.<br />
<br />
The function gvf_control_2D executes the algorithm for calculating the desired turn for the vehicle. It is a good practice that all the trajectories (not only straight lines) have the same order of magnitude (between 0.00 and 5.00) for <math>k_e</math>. So if you have to add a scaling factor, here is were you have to do it.<br />
<br />
The variables gvf_xx are sent to the ground station as telemetry, so you can draw the vector field, the trajectory, etc.<br />
<br />
Finally for defining <math>\varphi(p), \nabla\varphi(p)</math> and <math>H(\varphi(p))</math> you need to write the two files gvf_line.{c,h}<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/trajectories/gvf_line.h<br />
<source lang="c"><br />
extern void gvf_line_info(float *phi, struct gvf_grad *, struct gvf_Hess *);<br />
</source><br />
}}<br />
<br />
and in gvf_line.c you write the implicit math of your trajectory (quite explicit)<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/trajectories/gvf_line.c<br />
<source lang="c"><br />
void gvf_line_info(float *phi, struct gvf_grad *grad,<br />
struct gvf_Hess *hess){<br />
<br />
struct EnuCoor_f *p = stateGetPositionEnu_f();<br />
float px = p->x;<br />
float py = p->y;<br />
float a = gvf_param[0];<br />
float b = gvf_param[1];<br />
float alpha = gvf_param[2];<br />
<br />
// Phi(x,y)<br />
*phi = -(px-a)*cosf(alpha) + (py-b)*sinf(alpha);<br />
<br />
// grad Phi<br />
grad->nx = -cosf(alpha);<br />
grad->ny = sinf(alpha);<br />
<br />
// Hessian Phi<br />
hess->H11 = 0;<br />
hess->H12 = 0;<br />
hess->H21 = 0;<br />
hess->H22 = 0;<br />
}<br />
</source><br />
}}<br />
<br />
I have omitted it, but of course you have to take care of all the headings files and to add your new trajectory in $PAPARAZZI_HOME/conf/modules/gvf_module.xml<br />
<br />
== Demo ==<br />
There is a flightplan called 'demo_gvf.xml' in order to test the different settings in a simulation. Do not forget to choose default_telemetry_gvf.xml in your paparazzi center.<br />
<br />
== TO DO list ==<br />
<br />
* Better integration of the GVF with the ground station<br />
* Support to rotorcrafts<br />
<br />
<br />
<br />
[[Category:User_Documentation]] [[Category:Modules]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=23423Working with INDI2016-12-16T16:13:25Z<p>Ewoud: </p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi_simple"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_CUTOFF" value="8.0"/><br />
<define name="ESTIMATION_FILT_CUTOFF" value="8.0"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness (G1) is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Maximum Yaw Rate ==<br />
The yaw control is usually least effective on a quadrotor. Therefore, the yaw command can easily saturate. To avoid yaw overshoot because of this, you can specify a maximum yaw rate.<br />
<br />
== Filtering ==<br />
The angular acceleration is derived from the angular rate. In taking the derivative, noise is amplified. Therefore, the angular acceleration signal can be quite noisy, and filtering is practically always needed. For this purpose a second order filter is used. Such a filter adds a bit of delay to the signal. More filtering will give more delay. This delay will cause disturbances to be measured slightly later and hence be compensated later. If you are not logging the flight data and able to inspect what level of filtering is necessary, it is best not to change this.<br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.<br />
<br />
== My drone is oscillating ==<br />
If your drone is oscillating or unstable, make sure you check the following (in this order):<br />
<br />
=== Changed inertia ===<br />
If you were flying before, but added something to the drone and now it is oscillating, you probably just need a different control effectiveness. You can try the online adaptation. Make sure that things are not loosely attached to the drone, as this will introduce extra dynamics. Rigid connections are preferred.<br />
<br />
=== The Actuator dynamics ===<br />
If you do not have actuator feedback, it is important to have an accurate actuator model. If you are unsure about your actuator model, it can be worthwhile to try to determine it.<br />
<br />
=== INDI loop vs PD controller ===<br />
<br />
Check if the oscillation comes from the INDI loop (control of angular acceleration) or from the PD controller that commands the reference angular acceleration. It can be that the angular acceleration reference is just too demanding.<br />
<br />
Do this by reducing both the P and D gains. If this does not resolve the issue, you can try holding the drone in your hand (if this can be done safe!) and reducing both P and D gains to zero. The drone will now try to keep zero angular acceleration. If the drone is still oscillating, probably the control effectiveness is wrong (see step 1). Else, try to find P and D values that give a fast response without oscillation.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Module/guidance_vector_field&diff=23368Module/guidance vector field2016-10-31T08:37:13Z<p>Ewoud: /* Introduction */</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree><br />
<br />
== Introduction ==<br />
We have written an algorithm for solving the problem of tracking smooth curves by an unmanned aerial vehicle travelling with a constant airspeed and under a wind disturbance. The algorithm is based on the idea of following a guiding vector field which is constructed from the implicit function that describes the desired (possibly time-varying) trajectory. <br />
<br />
For fixed-wings the output of the algorithm can be directly expressed in terms of the bank angle of the UAV in order to achieve coordinated turns. Furthermore, the algorithm can be tuned offline such that physical constraints of the UAV, e.g. the maximum bank angle, will not be violated in a neighborhood of the desired trajectory.<br />
<br />
The implementation for rotorcraft is still in the TO DO list.<br />
<br />
This work is based on the paper [https://arxiv.org/abs/1610.02797 Guidance algorithm for smooth trajectory tracking of a fixed wing UAV flying in wind flows], submitted to ICRA 2017 (pending of approval).<br />
<br />
== How does the algorithm work? ==<br />
We start from the implicit equation of the trajectory, for example for a circumference we have that <math>\varphi(x,y) = x^2 + y^2 - R^2</math>, where <math>x, y</math> and <math>R</math> are the x, y coordinates with respect to HOME (<math>O</math> in the following figure) and R is the radius of the circumference. Note that when the vehicle is over the desired trajectory, then <math>\varphi(x,y) = 0</math>, otherwise it will be different from zero. We will use this concept of "level set" to define the notion of distance to the trajectory, namely <math>e := \varphi(x,y)</math>. It has to be noted that this is different from the Euclidean distance (see figure below).<br />
<br />
For the sake of clarity we will consider just 2D trajectories and parallel to the ground. Let us stack the x and y coordinates in <math>p := \begin{bmatrix}x & y\end{bmatrix}^T</math> and consider the following kinematical model for our vehicle<br />
<br />
<math>\begin{cases} \dot p &= sm(\psi) + w \\ \dot\psi &= u, \end{cases}</math><br />
<br />
where <math>s\in\mathbb{R}^+</math> is a constant that can be considered as the airspeed, <math>m = \begin{bmatrix}\cos(\psi) & \sin(\psi)\end{bmatrix}^T</math> with <math>\psi\in(-\pi, \pi]</math> being the attitude yaw angle, <math>w\in\mathbb{R}^2</math> is a constant with respect to <math>O</math> representing the wind and <math>u</math> is the control action that will make the vehicle to turn. We also notice that the course heading <math>\chi\in(-\pi, \pi]</math>, i.e. the direction the velocity vector <math>\dot p</math> is pointing at, in general is different from the yaw angle <math>\psi</math> because of the wind.<br />
<br />
[[File:GVF.png|center]]<br />
<br />
Given a desired trajectory, we compute its normal <math>n(p) := \nabla \varphi(p)</math> and its tangent <math>\tau(p) = En(p), \quad E=\begin{bmatrix}0 & 1 \\ -1 & 0\end{bmatrix}</math>. The idea is to steer the vehicle such that it follows the direction given by the unit vector calculated from <br />
<br />
<math>\dot p_d(p) := \tau(p) - k_e e(p)n(p),</math><br />
<br />
where <math>k_e</math> is a positive gain. At each point <math>p</math> we can build a unit vector from <math>\dot p_d(p)</math>. This collection of vectors is our Guidance Vector Field. Note that when the error is zero, then we are just tracking the tangent to the trajectory.<br />
<br />
We assume that the trajectory is twice differentiable (so its gradient and Hessian exists) and that it is regular in a neighborhood of <math>\mathcal{P}</math>, i.e.<br />
<br />
<math>\nabla\varphi(p) \neq 0, \quad p\in \mathcal{N}_{\mathcal{P}},\quad \mathcal{N}_{\mathcal{P}} := \{p \, : \, |\varphi(p)| \leq c^* > 0\}</math>.<br />
<br />
<br />
The algorithm needs for work the measurements of <math>\dot p</math> (typically derived from GPS), position <math>p</math> w.r.t. HOME (typically derived from GPS) and yaw angle <math>\psi</math> or sideslip angle <math>\beta = (\psi - \chi)</math>. The algorithm still works quite well in practice with only <math>\dot p</math> and <math>p</math>, in other words, you will only need to have installed a GPS.<br />
<br />
== Using the GVF in the flight plan ==<br />
<br />
{TODO: to enumerate all the functions available for the user.}<br />
<br />
So far we have added support for two kind of trajectories, ellipses and sinusoidals. Note that the former includes circumferences and the latter includes<br />
straight lines (zero frequency).<br />
<br />
For tracking an ellipse, one has to call the function<br />
<source lang="html"><br />
<call fun="gvf_ellipse(WP_STDBY, gvf_ellipse_a, gvf_ellipse_b, gvf_ellipse_alpha)"/><br />
</source><br />
where gvf_ellipse_a (horizontal axis), gvf_ellipse_b (vertical axis), gvf_ellipse_alpha (rotation w.r.t. North) can be defined in your settings file. <br />
<br />
<br />
For tracking a straight line that crosses HOME with course heading 45 degrees <br />
<source lang="html"><br />
<call fun="gvf_line_wp_heading(WP_HOME, 45)"/><br />
</source><br />
<br />
<br />
For tracking a sinusoidal, the same as the straight line but including the additional information about frequency, offset and amplitude (in meters)<br />
<source lang="html"><br />
<call fun="gvf_sin_wp_heading(WP_HOME, course_heading, freq, off_set, amplitude)"/><br />
</source><br />
<br />
<br />
For setting the tracking direction (the direction of the tangent vector <math>\tau</math> in the above figure)<br />
<source lang="html"><br />
<call fun="gvf_set_direction(s)"/><br />
</source><br />
where s is an integer number 1 or -1.<br />
<br />
== Gain tunning ==<br />
<br />
The user has to tune two gains <math>k_n, k_e</math>. The former one determines the convergence rate for aligning the vehicle to the vector field. A typical value for starting tuning <math>k_n</math> should be between 0.2 and 1. The latter gain determines how aggressive is the vector field. For example, in the following figure we have an ellipse with two different values of <math>k_e</math>, at the left we have a value of 3 and at the right 0.4. Note how in left one the vectors are "more aggressive" towards the trajectory. While a big value can make the vehicle to converge quickly to the trajectory, it can make the tracking unstable once the vehicle is close it. This is because the vector field might change so quick that physically the vehicle cannot follow it. Check the Section IV in the original paper in the introduction.<br />
<br />
It is a good practice in the flight plan to set the gains before calling the trajectory since it is pretty common to have different gains for different trajectories. For example<br />
<source lang="html"><br />
<call fun="gvf_set_direction(s)"/><br />
<call fun="gvf_set_gains(ke, kn)"/><br />
<call fun="gvf_ellipse(WP_STDBY, gvf_ellipse_a, gvf_ellipse_b, gvf_ellipse_alpha)"/><br />
</source><br />
<br />
<br />
== Python App == <br />
<br />
Until the "visual integration" of the GVF into the ground station is ready, one can track the vehicle and the trajectory by using the python script at $PAPARAZZI_HOME/sw/ground_segment/python/gvf/gvfApp .<br />
<br />
<gallery mode=packed heights=300px><br />
File:gvf_ellipse.png<br />
File:gvf_Sin.png<br />
</gallery><br />
<br />
== Defining your own trajectory ==<br />
<br />
The algorithm is placed in $PAPARAZZI_HOME/sw/airborne/modules/guidance/gvf .<br />
The trajectories are placed in $PAPARAZZI_HOME/sw/airborne/modules/guidance/gvf/trajectories .<br />
<br />
Here there is an example (the straight line) about how to code your own trajectory.<br />
You need to add at least two functions in the header<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/gvf.h<br />
<source lang="c"><br />
// Straigh line<br />
void gvf_line(float x, float y, float alpha);<br />
extern bool gvf_line_wp1_wp2(uint8_t wp1, uint8_t wp2);<br />
extern bool gvf_line_wp_heading(uint8_t wp, float alpha);<br />
</source><br />
}}<br />
<br />
where the first function will be called by the algorithm and the rest by the user in the flight plan. For example, the user in the flight plan <br />
calls to gvf_line_wp_heading<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/gvf.c<br />
<source lang="c"><br />
bool gvf_line_wp_heading(uint8_t wp, float alpha)<br />
{<br />
alpha = alpha*M_PI/180;<br />
<br />
float a = waypoints[wp].x;<br />
float b = waypoints[wp].y;<br />
<br />
gvf_line(a, b, alpha);<br />
<br />
return true;<br />
}<br />
</source><br />
}}<br />
<br />
The idea is that while you can define a straight line in many different ways, you make all the transformations<br />
in the function called by the user such that the algorithm is always evaluating the trajectory in the same way. It helps for maintaining the code and for tuning<br />
the gains (you do not want to have different set of gains depending on how you call your trajectory). <br />
<br />
We finally call the function gvf_line (hidden for the user) that will invoke the algorithm.<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/gvf.c<br />
<source lang="c"><br />
void gvf_line(float a, float b, float alpha)<br />
{<br />
float e;<br />
struct gvf_grad grad_line;<br />
struct gvf_Hess Hess_line;<br />
<br />
gvf_traj_type = 0;<br />
gvf_param[0] = a;<br />
gvf_param[1] = b;<br />
gvf_param[2] = alpha;<br />
<br />
gvf_line_info(&e, &grad_line, &Hess_line);<br />
gvf_control_2D(1e-2*gvf_ke, gvf_kn, e, &grad_line, &Hess_line);<br />
<br />
gvf_error = e;<br />
}<br />
</source><br />
}}<br />
<br />
The three first lines are the <math>\varphi(p), \nabla\varphi(p)</math> and <math>H(\varphi(p))</math>, where <math>H</math> stands for the Hessian. These three<br />
guys will be populated by gvf_line_info (in a moment we will be see how to write it).<br />
<br />
Then gvf_traj_type stands for the kind of trajectory. Right now we have 0 for lines, 1 for ellipses and 2 for sinusoidals. Feel free to choose an index that has not been taken. The rest gvf_param[x]'s are the parameters of the trajectory. You have up to seven for describing a trajectory.<br />
<br />
The function gvf_control_2D executes the algorithm for calculating the desired turn for the vehicle. It is a good practice that all the trajectories (not only straight lines) have the same order of magnitude (between 0.00 and 5.00) for <math>k_e</math>. So if you have to add a scaling factor, here is were you have to do it.<br />
<br />
The variables gvf_xx are sent to the ground station as telemetry, so you can draw the vector field, the trajectory, etc.<br />
<br />
Finally for defining <math>\varphi(p), \nabla\varphi(p)</math> and <math>H(\varphi(p))</math> you need to write the two files gvf_line.{c,h}<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/trajectories/gvf_line.h<br />
<source lang="c"><br />
extern void gvf_line_info(float *phi, struct gvf_grad *, struct gvf_Hess *);<br />
</source><br />
}}<br />
<br />
and in gvf_line.c you write the implicit math of your trajectory (quite explicit)<br />
<br />
{{Box Code||sw/airborne/modules/guidance/gvf/trajectories/gvf_line.c<br />
<source lang="c"><br />
void gvf_line_info(float *phi, struct gvf_grad *grad,<br />
struct gvf_Hess *hess){<br />
<br />
struct EnuCoor_f *p = stateGetPositionEnu_f();<br />
float px = p->x;<br />
float py = p->y;<br />
float a = gvf_param[0];<br />
float b = gvf_param[1];<br />
float alpha = gvf_param[2];<br />
<br />
// Phi(x,y)<br />
*phi = -(px-a)*cosf(alpha) + (py-b)*sinf(alpha);<br />
<br />
// grad Phi<br />
grad->nx = -cosf(alpha);<br />
grad->ny = sinf(alpha);<br />
<br />
// Hessian Phi<br />
hess->H11 = 0;<br />
hess->H12 = 0;<br />
hess->H21 = 0;<br />
hess->H22 = 0;<br />
}<br />
</source><br />
}}<br />
<br />
I have omitted it, but of course you have to take care of all the headings files and to add your new trajectory in $PAPARAZZI_HOME/conf/modules/gvf_module.xml<br />
<br />
== TO DO list ==<br />
<br />
* Better integration of the GVF with the ground station<br />
* Support to rotorcrafts<br />
<br />
[[Category:User_Documentation]] [[Category:Modules]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=File_logger&diff=23298File logger2016-08-23T18:43:16Z<p>Ewoud: </p>
<hr />
<div>=When you can use the file logger module=<br />
<br />
The file logger module can be used if you have internal storage space on your autopilot. <br />
This is for instance the case with most drones from Parrot, such as the Bebop.<br />
Therefore, in the rest of this page, the Bebop will be taken as an example.<br />
<br />
=Logging Data on the Parrot Bebop=<br />
<br />
Logging data onboard on the Bebop is pretty straight forward. <br />
The Bebop drone is equipped with onboard storage, which we use to store the logs. <br />
<br />
'''Step 1:'''<br />
First, open your <tt> airframe.xml </tt> file (for example in <tt> paparazzi/conf/airframes/TUDELFT/ </tt>). Make sure that under modules, the following lines are uncommented or included:<br />
<br />
<source lang="xml"><br />
<modules main_freq="512"><br />
<module name="logger_file"><br />
<define name="FILE_LOGGER_PATH" value="/data/ftp/internal_000"/><br />
</module><br />
</modules><br />
</source><br />
<br />
'''Step 2:'''<br />
In your logger file include the headers within paparazzi which contain the variables which you would like to log. This is done in the logger c file in <tt> paparazzi/sw/airborne/modules/loggers/file_logger.c </tt>. In this case I want to log data from <tt> stabilization_indi.c </tt>, so the following header should be included:<br />
<br />
<source lang="c"><br />
#include "firmwares/rotorcraft/stabilization/stabilization_indi.h"<br />
</source><br />
<br />
In the file <tt> file_logger.c </tt> you can specify which variables you want to have logged in the same fashion as normal "printf's" would work. The variable names and the variable types (float, int etc.) have to be specified.<br />
<br />
'''Step 3:'''<br />
Start and stop the file logger by going to the paparazzi ground control station. Then go to > Settings > Modules. Here you can start and stop a log. This is displayed in the picture below:<br />
<br />
[[File:Bebop logs.png|frameless|Enable data logging in the GCS.]]<br />
<br />
'''Step 4:'''<br />
First, make sure that your Parrot Bebop is on, and connected. Now the logged .csv files can be retrieved from the Bebop. This is done by opening a browser, and typing <tt> ftp://196.168.42.1/ </tt> in the navigation line. This will take you to the ftp folder on the Bebop. Browse to <tt> /Internal000/ </tt>. Here we can find the <tt>.csv </tt>files, named <tt> 00000.csv </tt> to <tt> 0000X.csv </tt> depending on the flights you logged. Copy the files to your computer for analysis.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=File_logger&diff=23297File logger2016-08-23T18:42:31Z<p>Ewoud: Created page with "=When you can use the file logger module= The file logger module can be used if you have internal storage space on you autopilot. This is for instance the case with most dro..."</p>
<hr />
<div>=When you can use the file logger module=<br />
<br />
The file logger module can be used if you have internal storage space on you autopilot. <br />
This is for instance the case with most drones from Parrot, such as the Bebop.<br />
Therefore, in the rest of this page, the Bebop will be taken as an example.<br />
<br />
=Logging Data on the Parrot Bebop=<br />
<br />
Logging data onboard on the Bebop is pretty straight forward. <br />
The Bebop drone is equipped with onboard storage, which we use to store the logs. <br />
<br />
'''Step 1:'''<br />
First, open your <tt> airframe.xml </tt> file (for example in <tt> paparazzi/conf/airframes/TUDELFT/ </tt>). Make sure that under modules, the following lines are uncommented or included:<br />
<br />
<source lang="xml"><br />
<modules main_freq="512"><br />
<module name="logger_file"><br />
<define name="FILE_LOGGER_PATH" value="/data/ftp/internal_000"/><br />
</module><br />
</modules><br />
</source><br />
<br />
'''Step 2:'''<br />
In your logger file include the headers within paparazzi which contain the variables which you would like to log. This is done in the logger c file in <tt> paparazzi/sw/airborne/modules/loggers/file_logger.c </tt>. In this case I want to log data from <tt> stabilization_indi.c </tt>, so the following header should be included:<br />
<br />
<source lang="c"><br />
#include "firmwares/rotorcraft/stabilization/stabilization_indi.h"<br />
</source><br />
<br />
In the file <tt> file_logger.c </tt> you can specify which variables you want to have logged in the same fashion as normal "printf's" would work. The variable names and the variable types (float, int etc.) have to be specified.<br />
<br />
'''Step 3:'''<br />
Start and stop the file logger by going to the paparazzi ground control station. Then go to > Settings > Modules. Here you can start and stop a log. This is displayed in the picture below:<br />
<br />
[[File:Bebop logs.png|frameless|Enable data logging in the GCS.]]<br />
<br />
'''Step 4:'''<br />
First, make sure that your Parrot Bebop is on, and connected. Now the logged .csv files can be retrieved from the Bebop. This is done by opening a browser, and typing <tt> ftp://196.168.42.1/ </tt> in the navigation line. This will take you to the ftp folder on the Bebop. Browse to <tt> /Internal000/ </tt>. Here we can find the <tt>.csv </tt>files, named <tt> 00000.csv </tt> to <tt> 0000X.csv </tt> depending on the flights you logged. Copy the files to your computer for analysis.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Data_Logger&diff=23296Data Logger2016-08-23T18:35:31Z<p>Ewoud: </p>
<hr />
<div>=Introduction=<br />
<br />
This page describes various '''onboard''' external devices called a "Data logger", that can be connected to the Paparazzi autopilot. <br />
<br />
Such a Data Logger device can be used to store telemetry data to a storage medium on board the aircraft. Such a storage medium can be an SD card or a Flash chip. For now logging is '''not''' done directly by the autopilot itself as the usage of a file system as well as possible lag you might get with a SD storage speed does not fit well with the real-time nature of Autopilots.<br />
<br />
Note that not all loggers accept SD HighCapacity(SDHC) cards as storage<br />
<br />
=Why Onboard=<br />
<br />
One would naturally first ask; why on on-board logger when we have data over the air?<br />
<br />
The answer to this is multi-fold; Sometimes it is not possible to log everything over the air because of speed, lag and datavolume limitations of data send wireless over the air. Or one needs to log when there is no telemetry at all in long distance flight. Or one want to log all the RAW IMU data to debug specific scenarios.<br />
<br />
To solve this issue, there are various loggers that can be connected to your Paparazzi Autopilot board.<br />
<br />
=Available Data logger options=<br />
<br />
There are numerous logging solutions, both with their pro's and con's; here the options:<br />
<br />
==* [[twoga-Logga|TWOGA-Logga]]==<br />
==* [[twoglogdedicated|An dedicated TWOG board for logging]]==<br />
==* [[Openlog|Openlog]]==<br />
==* [[SDLogger_SPI_Direct|SD Logger SPI Direct]]==<br />
==* [[Micro_logger|Micro Logger]]==<br />
==* [[file_logger|File Logger (Bebop)]]==<br />
<br />
=Storage format=<br />
<br />
A more unified method of storing data on the logger, [[Messages_Format#Telemetry_storage_format_for_data_logger|info available here]]<br />
<br />
[[Category:Hardware]] [[Category:Software]] [[Category:User_Documentation]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21249Working with INDI2016-06-08T10:16:22Z<p>Ewoud: </p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Maximum Yaw Rate ==<br />
The yaw control is usually least effective on a quadrotor. Therefore, the yaw command can easily saturate. To avoid yaw overshoot because of this, you can specify a maximum yaw rate.<br />
<br />
== Filtering ==<br />
The angular acceleration is derived from the angular rate. In taking the derivative, noise is amplified. Therefore, the angular acceleration signal can be quite noisy, and filtering is practically always needed. For this purpose a second order filter is used. Such a filter adds a bit of delay to the signal. More filtering will give more delay. This delay will cause disturbances to be measured slightly later and hence be compensated later. If you are not logging the flight data and able to inspect what level of filtering is necessary, it is best not to change this.<br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.<br />
<br />
== My drone is oscillating ==<br />
If your drone is oscillating or unstable, make sure you check the following (in this order):<br />
<br />
=== Changed inertia ===<br />
If you were flying before, but added something to the drone and now it is oscillating, you probably just need a different control effectiveness. You can try the online adaptation. Make sure that things are not loosely attached to the drone, as this will introduce extra dynamics. Rigid connections are preferred.<br />
<br />
=== The Actuator dynamics ===<br />
If you do not have actuator feedback, it is important to have an accurate actuator model. If you are unsure about your actuator model, it can be worthwhile to try to determine it.<br />
<br />
=== INDI loop vs PD controller ===<br />
<br />
Check if the oscillation comes from the INDI loop (control of angular acceleration) or from the PD controller that commands the reference angular acceleration. It can be that the angular acceleration reference is just too demanding.<br />
<br />
Do this by reducing both the P and D gains. If this does not resolve the issue, you can try holding the drone in your hand (if this can be done safe!) and reducing both P and D gains to zero. The drone will now try to keep zero angular acceleration. If the drone is still oscillating, probably the control effectiveness is wrong (see step 1). Else, try to find P and D values that give a fast response without oscillation.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21248Working with INDI2016-06-08T10:06:42Z<p>Ewoud: /* My drone is oscillating */</p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.<br />
<br />
== My drone is oscillating ==<br />
If your drone is oscillating or unstable, make sure you check the following (in this order):<br />
<br />
=== Changed inertia ===<br />
If you were flying before, but added something to the drone and now it is oscillating, you probably just need a different control effectiveness. You can try the online adaptation. Make sure that things are not loosely attached to the drone, as this will introduce extra dynamics. Rigid connections are preferred.<br />
<br />
=== The Actuator dynamics ===<br />
If you do not have actuator feedback, it is important to have an accurate actuator model. If you are unsure about your actuator model, it can be worthwhile to try to determine it.<br />
<br />
=== INDI loop vs PD controller ===<br />
<br />
Check if the oscillation comes from the INDI loop (control of angular acceleration) or from the PD controller that commands the reference angular acceleration. It can be that the angular acceleration reference is just too demanding.<br />
<br />
Do this by reducing both the P and D gains. If this does not resolve the issue, you can try holding the drone in your hand (if this can be done safe!) and reducing both P and D gains to zero. The drone will now try to keep zero angular acceleration. If the drone is still oscillating, probably the control effectiveness is wrong (see step 1). Else, try to find P and D values that give a fast response without oscillation.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21247Working with INDI2016-06-08T09:29:53Z<p>Ewoud: </p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.<br />
<br />
== My drone is oscillating ==<br />
If your drone is oscillating or unstable, make sure you check the following (in this order):</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21246Working with INDI2016-06-08T09:24:52Z<p>Ewoud: /* Adaptive INDI */</p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Always use caution with Adaptive INDI'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21245Working with INDI2016-06-08T09:23:43Z<p>Ewoud: /* Adaptive INDI */</p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Use Adaptive INDI on your own discretion'''<br />
<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21244Working with INDI2016-06-08T09:23:23Z<p>Ewoud: </p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Adaptive INDI ==<br />
'''Use Adaptive INDI on your own discretion'''<br />
If you enable adaptive INDI, a Least Mean Squares (LMS) algorithm will estimate the control effectiveness values online. It does this by taking the current estimate of the control effectiveness multiplied with the most recent change in input. This is the expected change in angular acceleration. This is then compared to the actual angular acceleration, and the control effectiveness is changed proportional to the error. The parameter ADAPTIVE_MU is the learning rate of the algorithm. A high value will adapt quicker, but can also respond more to disturbances and noise.<br />
<br />
Note that this assumes that all angular accelerations are caused by the inputs. This assumption usually holds indoors, but outside the wind can cause part of the angular acceleration. This can result in faulty adaptation. Also, when taking off with adaptation enabled, faulty learning can occur. This is because while on the ground, inputs will not result in angular accelerations. The algorithm may then estimate a very low control effectiveness. Lastly, if you have no actuator feedback/a bad estimate of the actuator dynamics, the learning may deteriorate.<br />
<br />
One approach is to only use the adaptation for estimation of the control effectiveness after airframe changes. Start flying the drone, and activate the learning while flying through the INDI settings. More importantly, de-activate the learning before landing, or kill the drone before touching the ground. Again, interaction with the ground may result in faulty learning. Save the control effectiveness values.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21243Working with INDI2016-06-08T09:00:30Z<p>Ewoud: </p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. Note that if you change the inertia of the drone, by adding weight, the control effectiveness is probably different than before. This is also the case when you add or remove bumpers/a flight hull.<br />
<br />
Also note that for quadrotors, a G2 value is introduced, which is there to account for the inertia of the rotors. When the rotors have a certain RPM, they have a certain drag, which is why they provide a yawing moment. More RPM, more drag, more moment. But to change the RPM of the rotors, the motors need to apply a moment to accelerate the rotors. This moment is applied to the drone as well (action = -reaction). To obtain best performance, we have to account for this effect in the controller. That is why there is a control effectiveness value for it.<br />
<br />
== Attitude Control ==<br />
The INDI controller itself controls angular accelerations. This means that if we want to command angular rates or attitude angles, we need to come up with a angular acceleration reference (or virtual control) that will result in the desired rate/attitude. This can be done with a simple PD controller. Since the control effectiveness (which includes the inertia of the vehicle) is accounted for by INDI, the P and D gains do not depend on the size of the drone. Instead, they only depend on the actuator dynamics. <br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21242Working with INDI2016-06-08T08:38:29Z<p>Ewoud: /* Actuator Dynamics */</p>
<hr />
<div>== Example Airframe Section == <br />
<br />
To use INDI for your drone, you have to specify:<br />
<module name="stabilization" type="indi"/><br />
or<br />
<module name="stabilization" type="rate_indi"/><br />
if you want to fly manual rate control.<br />
<br />
Below you can see an example of how INDI can be configured in the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE_INDI" prefix="STABILIZATION_INDI_"><br />
<!-- control effectiveness --><br />
<define name="G1_P" value="0.0639"/><br />
<define name="G1_Q" value="0.0361"/><br />
<define name="G1_R" value="0.0022"/><br />
<define name="G2_R" value="0.1450"/><br />
<br />
<!-- reference acceleration for attitude control --><br />
<define name="REF_ERR_P" value="600.0"/><br />
<define name="REF_ERR_Q" value="600.0"/><br />
<define name="REF_ERR_R" value="600.0"/><br />
<define name="REF_RATE_P" value="28.0"/><br />
<define name="REF_RATE_Q" value="28.0"/><br />
<define name="REF_RATE_R" value="28.0"/><br />
<br />
<!--Maxium yaw rate, to avoid instability--><br />
<define name="MAX_R" value="120.0" unit="deg/s"/><br />
<br />
<!-- second order filter parameters --><br />
<define name="FILT_OMEGA" value="50.0"/><br />
<define name="FILT_ZETA" value="0.55"/><br />
<define name="FILT_OMEGA_R" value="50.0"/><br />
<define name="FILT_ZETA_R" value="0.55"/><br />
<br />
<!-- first order actuator dynamics --><br />
<define name="ACT_DYN_P" value="0.1"/><br />
<define name="ACT_DYN_Q" value="0.1"/><br />
<define name="ACT_DYN_R" value="0.1"/><br />
<br />
<!-- Adaptive Learning Rate --><br />
<define name="USE_ADAPTIVE" value="FALSE"/><br />
<define name="ADAPTIVE_MU" value="0.0001"/><br />
</section><br />
</source><br />
}}<br />
<br />
<br />
== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21241Working with INDI2016-06-08T08:32:51Z<p>Ewoud: </p>
<hr />
<div>== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
== Control Effectiveness ==<br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Working_with_INDI&diff=21240Working with INDI2016-06-08T08:30:14Z<p>Ewoud: Created page with "== Actuator Dynamics == Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is sud..."</p>
<hr />
<div>== Actuator Dynamics ==<br />
<br />
Actuators don't react instantly. Motors need time to spin up, and servos can only move so many degrees per second. This means that if the input is suddenly changed, the angular acceleration is not immediately expected to change. If there is actuator feedback available, we know exactly how much the actuator has moved and at what moment how much angular acceleration we should expect. If actuator feedback is not available, an estimate of the actuator position has to be made.<br />
<br />
For electric motors, a first order system can be an accurate model. This can be written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. There are a few vehicles for which this value has been determined, such as the ARDrone, Bebop and AscTec Hummingbird. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Subsystem/stabilization&diff=21239Subsystem/stabilization2016-06-08T08:18:57Z<p>Ewoud: /* INDI */</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree><br />
== Stabilization subsystem ==<br />
The ''stabilization'' subsystem provides the attitude controller for rotorcrafts.<br />
<br />
Currently possible attitude ''stabilization'' subsystem types are<br />
* ''[[Subsystem/stabilization#Quaternion|int_quat]]''<br />
* ''[[Subsystem/stabilization#Quaternion|float_quat]]''<br />
* ''[[Subsystem/stabilization#Euler|int_euler]]''<br />
* ''[[Subsystem/stabilization#Euler|float_euler]]''<br />
* ''[[Subsystem/stabilization#INDI|indi]]''<br />
<br />
== Attitude Control Implementations ==<br />
There are several different attitude control algorithm implementations.<br />
<br />
They use the same ''STABILIZATION_ATTITUDE'' xml configuration section:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE" prefix="STABILIZATION_ATTITUDE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_PHI" value="45." unit="deg"/><br />
<define name="SP_MAX_THETA" value="45." unit="deg"/><br />
<define name="SP_MAX_R" value="90." unit="deg/s"/><br />
<define name="DEADBAND_A" value="0"/><br />
<define name="DEADBAND_E" value="0"/><br />
<define name="DEADBAND_R" value="250"/><br />
<br />
<!-- reference --><br />
<define name="REF_OMEGA_P" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_P" value="0.85"/><br />
<define name="REF_MAX_P" value="400." unit="deg/s"/><br />
<define name="REF_MAX_PDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_Q" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_Q" value="0.85"/><br />
<define name="REF_MAX_Q" value="400." unit="deg/s"/><br />
<define name="REF_MAX_QDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_R" value="500" unit="deg/s"/><br />
<define name="REF_ZETA_R" value="0.85"/><br />
<define name="REF_MAX_R" value="180." unit="deg/s"/><br />
<define name="REF_MAX_RDOT" value="RadOfDeg(1800.)"/><br />
<br />
<!-- feedback --><br />
<define name="PHI_PGAIN" value="1000"/><br />
<define name="PHI_DGAIN" value="400"/><br />
<define name="PHI_IGAIN" value="200"/><br />
<br />
<define name="THETA_PGAIN" value="1000"/><br />
<define name="THETA_DGAIN" value="400"/><br />
<define name="THETA_IGAIN" value="200"/><br />
<br />
<define name="PSI_PGAIN" value="500"/><br />
<define name="PSI_DGAIN" value="300"/><br />
<define name="PSI_IGAIN" value="10"/><br />
<br />
<!-- feedforward --><br />
<define name="PHI_DDGAIN" value="300"/><br />
<define name="THETA_DDGAIN" value="300"/><br />
<define name="PSI_DDGAIN" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
<br />
; ''SP_MAX_*'': maximum ''PHI''/''THETA'' (roll/pitch) angles and maximum angular velocity ''R'' around yaw axis<br />
; ''DEADBAND_*'': RC stick deadband around the center for ''A'',''E'',''R'' (roll,pitch,yaw)<br />
; ''REF_*'': parameters for the [[Control_Loops#Reference_generators_2|reference generator]]<br />
; ''REF_OMEGA_*'' : second order model natural frequency for respective axis<br />
; ''REF_ZETA_*'' : second order model damping factor for respective axis<br />
; ''REF_MAX_x'' : bound on ref model angular speed<br />
; ''REF_MAX_xDOT'' : bound on ref model angular acceleration<br />
; ''[PHI|THETA|PSI]_[PID]GAIN'': gains for the feedback control of the respective axis<br />
; ''[PHI|THETA|PSI]_DDGAIN'': feedforward gains for the respective axis<br />
<br />
=== Quaternion ===<br />
Attitude controllers using quaternions (no gimbal lock).<br />
There is a fixed point implementation (recommended) and a floating point implementation for reference and testing.<br />
<br />
* fixed point: <source lang="xml"><subsystem name="stabilization" type="int_quat"/></source><br />
* floating point: <source lang="xml"><subsystem name="stabilization" type="float_quat"/></source><br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_quat"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== Euler ===<br />
Attitude controller using Euler Angles. Due to the inherent singularities (e.g. 90deg pitch) of the euler angles representation you can't use this controller if you want to fly in regimes close or at these singularities (e.g. acrobatics or transitioning vehicles).<br />
See [[Control_Loops#Attitude_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_euler"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== INDI ===<br />
Attitude controller based on an Incremental Nonlinear Dynamic Inversion inner loop. It controls the angular acceleration in an incremental way. Detailed information can be found in the paper 'Adaptive Incremental Nonlinear Dynamic Inversion for Micro Aerial Vehicles' (http://arc.aiaa.org/doi/abs/10.2514/1.G001490).<br />
<br />
The idea is that any moment on the drone, results in an angular acceleration. With the onboard gyroscope, we measure the angular rate. This means that if we take the derivative of the angular rate, we have a measure of all moments on the drone through the angular acceleration. This includes the moment caused by the inputs. We know what the angular acceleration is with the inputs that we are giving, so to change the angular acceleration to a desired value, we just need to increment these inputs. How much we should increment the inputs to get a certain increment in angular acceleration is determined by the ''control effectiveness''.<br />
<br />
The benefit of using INDI over PID is that the disturbance rejection is a lot faster. This means that an external moment on the drone due to wind or something else is counteracted as fast as the drone can measure it and the actuators can move. Compare this to the integrator gain of a PID controller, that only slowly removes steady state offsets.<br />
<br />
More practical information can be found on [[working with INDI]]<br />
<br />
== Rate Control ==<br />
There is only one rate control implementation (which is included in the rotorcraft firmware by default). It allows you to fly a rotorcraft like a helicopter by controlling the angular rate directly instead of having (self-leveling) attitude control.<br />
See [[Control_Loops#Rate_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
</firmware><br />
<br />
<section name="STABILIZATION_RATE" prefix="STABILIZATION_RATE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_P" value="10000"/><br />
<define name="SP_MAX_Q" value="10000"/><br />
<define name="SP_MAX_R" value="10000"/><br />
<define name="DEADBAND_P" value="20"/><br />
<define name="DEADBAND_Q" value="20"/><br />
<define name="DEADBAND_R" value="200"/><br />
<define name="REF_TAU" value="4"/><br />
<br />
<!-- feedback --><br />
<define name="GAIN_P" value="400"/><br />
<define name="GAIN_Q" value="400"/><br />
<define name="GAIN_R" value="350"/><br />
<br />
<define name="IGAIN_P" value="75"/><br />
<define name="IGAIN_Q" value="75"/><br />
<define name="IGAIN_R" value="50"/><br />
<br />
<!-- feedforward --><br />
<define name="DDGAIN_P" value="300"/><br />
<define name="DDGAIN_Q" value="300"/><br />
<define name="DDGAIN_R" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
[[Category:User_Documentation]] [[Category:Subsystems]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Installation&diff=21142Installation2016-03-31T14:50:42Z<p>Ewoud: /* Quickstart for Ubuntu users */</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Installation</categorytree><br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
Paparazzi is very easily installed on any laptop or workstation running the [http://www.ubuntu.com/ Ubuntu Linux OS] or virtually any [http://www.debian.org/ Debian] based [http://en.wikipedia.org/wiki/Linux Linux] or Apple Macintosh running [http://en.wikipedia.org/wiki/OS_X Mac OS X]. There is also work being done to port Paparazzi to Windows.<br />
<br />
The steps required to install the software needed to be able to let your UAS fly are:<br />
<br />
# Install tools and prerequisites needed by Paparazzi.<br />
# Download the source code from the source repository.<br />
# Compile the Paparazzi software from sourcecode<br />
# Complete any final configuration<br />
<br />
== Quickstart for Ubuntu users ==<br />
Love one-liners? To get the latest Paparazzi up and running on your '''Ubuntu 12.04 or higher OS''', make sure you have internet, then just copy and paste the text below into your terminal and press [enter] ... and wait a while...<br />
<br />
sudo add-apt-repository -y ppa:paparazzi-uav/ppa && sudo add-apt-repository -y ppa:terry.guo/gcc-arm-embedded && sudo apt-get update && \ <br />
sudo apt-get -f -y install paparazzi-dev paparazzi-jsbsim gcc-arm-none-eabi && cd ~ && <nowiki>git clone --origin upstream https://github.com/paparazzi/paparazzi.git</nowiki> && \<br />
cd ~/paparazzi && git remote update -p && \<br />
git checkout -b v5.8 upstream/v5.8 && sudo cp conf/system/udev/rules/*.rules /etc/udev/rules.d/ && \<br />
make clean && make && ./paparazzi<br />
<br />
[[File:Done.jpg|frameless|center|Done!]]<br />
If all went well the Paparazzi Center should now be running... '''skip''' the rest of this page and go fly! <br />
<br />
If you are new you'll need to do some more things before you go fly like configuring your XML definition file detailing your airframe configuration. There is help here for that: [[Airframe_Configuration]]<br />
<br />
In case you have no autopilot hardware yet, no problem, you can get hardware [[Get_Hardware|here]] or just buy a ready to fly aircraft that can run Paparazzi Software like the Parrot Drones [http://www.parrot.com/products/bebop-drone/ Parrot Bebop] and run Paparazzi on your Parrot [[AR_Drone_2|ARDRone2]], [[Bebop|Bebop]] and Bebop2 (soon the Disco drone).<br />
<br />
== OS Specific Instructions ==<br />
<br />
For Linux an instructional video explaining it all in detail can be found here https://www.youtube.com/watch?v=eW0PCSjrP78<br />
<br />
The process of installing the prerequisite tools and dependencies needed by Paparazzi is specific to the operating system you are using. For detailed installation instructions, please see the following pages:<br />
*[[Installation/Linux|Installing prerequisites tools on Linux]]<br />
*[[Installation/MacOSX|Installing prerequisites tools on Mac OS X]]<br />
*[[Installation/RaspberryPi|Installing prerequisites tools on the RaspberryPi (Raspbian)]]<br />
<br />
For more advanced installation information or developers, please see the following pages:<br />
*[[Installation/FromScratch|Installing everything from scratch]] For non Debian based Linux distributions or if one just wants to be able to use all the latest and greatest compilers, or source code of everything to improve something. Then there is no other way than to install from scratch.<br />
*[[Installation/Windows|Installing prerequisite tools on Windows]] Note that this is '''a work in progress, and not finished yet'''. It would be fantastic if you are interested in running Paparazzi on this OS to help out with the porting. Being able to help is one of opensource software main features. If your skil- set is not so good in this area, but you still insist using Windows OS, then it is best to install a VirtualMachine from within Windows where you run the free Ubuntu OS of choice.<br />
<br />
=== Virtual Machines ===<br />
<br />
It is also possible to have your Debian/Ubuntu running in a virtual machine, for instance with [http://www.virtualbox.org/ VirtualBox]. This requires minimal changes to your computer setup, as you can run the VM from all common platforms (Windows, OS X, Linux). The virtual machine image can easily be transferred between different laptops, giving greater flexibility. Unfortunately, the Open-Source Edition of VirtualBox doesn't include the necessary USB support, so you'll need to get the regular version from the website.<br />
<br />
If you are new and this is your first time installing it is suggested you keep it simple. Use the standard Linux or OS X install. Select a system you can dedicate to the Linux installation. No VMs or dual boot configurations. The idea is do a very simple generic installation that is certain to have no issues. This reassures you that the installation process works and you can see and use a working Paparazzi install for some time before you try a more complicated install. The install is well documented and certain to succeed if followed exactly. Most issues arise when someone unfamiliar with Paparazzi or their OS tries a non-standard install that requires special steps that are not documented. Generally, commands can be copied and pasted for easy, step-by-step installation.<br />
<br />
== Getting the Source Code ==<br />
The Paparazzi source code is hosted on [https://github.com/paparazzi/paparazzi Github]. While you can download it as a tarball from https://github.com/paparazzi/paparazzi/releases, it is recommended to clone the repository with [[git]].<br />
<br />
From the directory of your choice type:<br />
git clone --origin upstream https://github.com/paparazzi/paparazzi.git<br />
Check out the released stable version branch:<br />
git checkout v5.8<br />
<br />
'''If this whole "Git" thing is new to you, more options and information can be found on the [[git|Git page]].'''<br />
<br />
== Launching the Software ==<br />
Make sure you have installed the <tt>paparazzi-dev</tt> package as described above. Without these you will not be able to compile the sourcecode.<br />
The first step is to compile. From the <tt>paparazzi</tt> directory (<tt>cd ~/paparazzi</tt>), run<br />
<br />
make<br />
<br />
You will have to run this command after each update of the source (<tt>git pull</tt> command).<br />
Launch the software from the <tt>paparazzi</tt> directory with<br />
<br />
./paparazzi<br />
<br />
From the [[Paparazzi_Center|Paparazzi Center]] interface, select the ''Microjet'' aircraft, select the ''sim'' target and ''Build'' it. Then ''Execute'' the ''Simulation'' session. The procedure is detailed in the [[Simulation]] page.<br />
<br />
=== Environment Variables ===<br />
<br />
If ('''and only if''') you want to directly launch some Paparazzi agents (the ''Tools'' of the [[Paparazzi_Center|Paparazzi Center]]) from the command line, without using the Paparazzi Center, you must have the Paparazzi source and home environment variables set correctly in your shell. These variables can be automatically set in your shell by adding the following lines to your .bashrc file:<br />
{{Box Code|~/.bashrc|<br />
<source lang="bash"><br />
export PAPARAZZI_HOME=''your paparazzi software directory''<br />
export PAPARAZZI_SRC=''your paparazzi software directory''<br />
</source><br />
}}<br />
<br />
Verify that your variables are set correctly with the following command:<br />
:<source lang="bash">env | grep PAPARAZZI</source><br />
which should return the following:<br />
<source lang="bash"><br />
PAPARAZZI_HOME=''your paparazzi software directory''<br />
PAPARAZZI_SRC=''your paparazzi software directory''<br />
</source><br />
<br />
<br />
If you wish to manually set the env variables (i.e. when compiling a backup copy of your code in a different folder) execute the following command from the folder you wish to set as your active paparazzi folder:<br />
:<source lang="bash">export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`</source><br />
<br />
== Software Updates ==<br />
'''We manage the software with the git version control system. Learn it! If you are new to it, see the [[Git|Git wiki page]].'''<br />
<br />
Paparazzi is a very rapidly evolving project and as such you might want to update your software regularly. See the [[RepositoryStructure|branching model and release process page]].<br />
<br />
Any new files you created will not be lost/overwritten when updating (like your own airframe file). Nevertheless, as with all things, backups are advised.<br />
If you modified source code, the best way is of course to use the version control system [[Git]] to commit your changes. Otherwise at least use the brute force method and save everything in another directory.<br />
<br />
Update your software with care and caution, and always test the functionality on the ground and in the air as some updates will affect tuning parameters. You might need to update your airframe file as well. The compiler will usually complain if there is a problem, at which point you can look at the [[Airframe_Configuration|Airframe Configuration wiki page]] again, look on the [[Contact#Mailing_List|mailing list]] or some of the most recent airframe files on git to find the proper syntax.<br />
<br />
'''See also the [[Release Upgrades]] page for information on how to update your configuration from one release to the next.'''<br />
<br />
=== Quick'n dirty description ===<br />
<br />
To download and automatically merge any updated source files, run the following command from your Paparazzi directory<br />
git pull<br />
<br />
After any git update or source code modification the code can be recompiled from ''your paparazzi software directory'' with the following command:<br />
<br />
make<br />
<br />
The ''make'' command will only recompile portions of the software where changed have been detected.<br />
If it does not behave as expected you can delete all compiled files and recompile from scratch with the following commands:<br />
<br />
make clean<br />
make<br />
<br />
If you'd like to check that the code compiles all example airframes then you can run the test suite using the command<br />
<br />
make test<br />
<br />
For more details see the [[Builds/Tests|tests page]].<br />
<br />
== Using the Live CD ==<br />
<br />
There is a [[LiveCD]] available, but it dates back to 2008. It is still an easy way to get a first glimpse of Paparazzi however without installing anything.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]] [[Category:Installation]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=JTAG&diff=20522JTAG2015-12-15T10:40:34Z<p>Ewoud: /* Upgrade BMP firmware */</p>
<hr />
<div>'''Is on the way being merged into [[DevGuide/GDB-Debug]]'''<br />
==Introduction==<br />
<br />
A JTAG interface is designed for on-chip debugging. It can also be used to flash your firmware if you do not have a means to upload software via USB already. For short, if you want to upload your own software or want to do serious paparazzi development work, the you need a JTAG adapter like this.<br />
<br />
See also:<br />
* [[FirmwareFlashing#JTAG|firmware flashing via JTAG]]<br />
* [[DevGuide/JTAG-Debug|debugging with JTAG]]<br />
<br />
==JTAG Adapters==<br />
There are multiple Paparazzi-compatible devices available that support JTAG.<br />
<br />
Below you find a list of JTAG devices that you can use in combination with e.g. a Paparazzi Lisa/M board. <br />
<br />
=== FLOSS JTAG ===<br />
<br />
The FLOSS JTAG is based on an FTDI chip that allows two simultaneous USB connections, which means that FLOSS JTAG allows JTAG and UART/COM connections.<br />
<br />
Let's take a look at upper side of the board. It contains JTAG connector (which is connected on photo) and two sets of RX/TX LEDs for JTAG and UART/COM interface separately. The JTAG connector is 2x5 pins, 0.05-inch pitch, and is compatible with the Samtec FFSD-05-D-06.00-01-N-RW-R ribbon cable.<br />
<br />
[[Image:Jtag-up.jpg]]<br />
<br />
On the other side of the board there is 4 pin UART/COM connector, which contains (from top to bottom in the image below): Ground (black), RX (orange), TX (yellow), and +5V (red)<br />
<br />
[[Image:Jtag-down.jpg]]<br />
<br />
Usage of board is pretty simple: JTAG can be used to upload firmware into the board and/or repair board with broken bootloader, and UART/COM interfaced can be used to make "COM port style" connection to the board. COM connection can be used for example for telemetry debug.<br />
<br />
More info available on the [http://randomprojects.org/wiki/Floss-JTAG randomprojects.org wiki].<br />
<br />
=== Black Magic Probe ===<br />
<br />
[[Image:BMPM_1_top.jpg|500x500px]][[Image:BMPM_1_bottom.jpg|500x500px]]<br />
<br />
Some additional info about the Black Magic Probe is available at the [http://www.blacksphere.co.nz/main/blackmagic Black Sphere Technology website].<br />
<br />
To use Black Magic Probe instead of FLOSS-JTAG or Luftboot for firmware flashing, append the following string to the upload command:<br />
<br />
On Linux:<br />
FLASH_MODE=JTAG_BMP BMP_PORT=/dev/ttyACM0<br />
On Mac OS:<br />
FLASH_MODE=JTAG_BMP BMP_PORT=/dev/cu.usbmodem<serial><br />
<br />
To make this the default flash method add this in the airframe file firmware section:<br />
<configure name="FLASH_MODE" value="JTAG_BMP"/><br />
<configure name="BMP_PORT" value="/dev/ttyACM0"/><br />
<br />
See the [[FirmwareFlashing]] page for other methods.<br />
<br />
==== Benefits ====<br />
<br />
There are good reasons to use the Black Magic Probe Mini instead of FLOSS-JTAG:<br />
<br />
*Lower cost<br />
*No need for OpenOCD as BMPM has a built in GDB server<br />
*Orders of magnitude faster as all the high speed protocol logic happens on the built-in STM32<br />
*Supports Serial Wire Debug (SWD)<br />
*Supports tracing using the SWD trace pin<br />
*No need for loading and unloading of FTDI drivers on Mac OS X<br />
<br />
====UART port====<br />
The pinout for the UART port on the back side of the BMP as seen on the image above and starting from the top is ground,rx,tx,3.3v . You can use this for receiving telemetry.<br />
<br />
====Upgrade BMP firmware====<br />
<br />
Check firmware version:<br />
$ sudo /usr/bin/arm-none-eabi-gdb<br />
(gdb) target extended-remote /dev/ttyACM0<br />
(gdb) monitor version<br />
<br />
To upgrade the brain of your Black Magic Probe, a.k.a. its firmware:<br />
<br />
- Download the compiled firmware from http://blacksphere.co.nz/builds/ (more info at https://github.com/blacksphere/blackmagic/wiki/Frequently-Asked-Questions)<br />
- Connect the Black Magic Probe while pressing the button<br />
- Download and run the stm32_mem.py script:<br />
$ git clone git://blackmagicdebug.git.sourceforge.net/gitroot/blackmagicdebug/blackmagicdebug<br />
$ cd blackmagicdebug/scripts<br />
$ ./stm32_mem.py blackmagic-XXXX.bin (this is the .bin file you downloaded in previous step)<br />
<br />
=== FT2232H Mini Module ===<br />
<br />
Use ftdi prog to change the Description String into: FLOSS-JTAG. <br/><br />
More information for this board at [[Serial_Adapter]].<br />
[[File:AlternativeFlossJtag.png]]<br />
<br />
[[Category:Hardware]] [[Category:Software]] [[Category:Developer_Documentation]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=JTAG&diff=20521JTAG2015-12-15T10:39:22Z<p>Ewoud: /* Upgrade BMP firmware */</p>
<hr />
<div>'''Is on the way being merged into [[DevGuide/GDB-Debug]]'''<br />
==Introduction==<br />
<br />
A JTAG interface is designed for on-chip debugging. It can also be used to flash your firmware if you do not have a means to upload software via USB already. For short, if you want to upload your own software or want to do serious paparazzi development work, the you need a JTAG adapter like this.<br />
<br />
See also:<br />
* [[FirmwareFlashing#JTAG|firmware flashing via JTAG]]<br />
* [[DevGuide/JTAG-Debug|debugging with JTAG]]<br />
<br />
==JTAG Adapters==<br />
There are multiple Paparazzi-compatible devices available that support JTAG.<br />
<br />
Below you find a list of JTAG devices that you can use in combination with e.g. a Paparazzi Lisa/M board. <br />
<br />
=== FLOSS JTAG ===<br />
<br />
The FLOSS JTAG is based on an FTDI chip that allows two simultaneous USB connections, which means that FLOSS JTAG allows JTAG and UART/COM connections.<br />
<br />
Let's take a look at upper side of the board. It contains JTAG connector (which is connected on photo) and two sets of RX/TX LEDs for JTAG and UART/COM interface separately. The JTAG connector is 2x5 pins, 0.05-inch pitch, and is compatible with the Samtec FFSD-05-D-06.00-01-N-RW-R ribbon cable.<br />
<br />
[[Image:Jtag-up.jpg]]<br />
<br />
On the other side of the board there is 4 pin UART/COM connector, which contains (from top to bottom in the image below): Ground (black), RX (orange), TX (yellow), and +5V (red)<br />
<br />
[[Image:Jtag-down.jpg]]<br />
<br />
Usage of board is pretty simple: JTAG can be used to upload firmware into the board and/or repair board with broken bootloader, and UART/COM interfaced can be used to make "COM port style" connection to the board. COM connection can be used for example for telemetry debug.<br />
<br />
More info available on the [http://randomprojects.org/wiki/Floss-JTAG randomprojects.org wiki].<br />
<br />
=== Black Magic Probe ===<br />
<br />
[[Image:BMPM_1_top.jpg|500x500px]][[Image:BMPM_1_bottom.jpg|500x500px]]<br />
<br />
Some additional info about the Black Magic Probe is available at the [http://www.blacksphere.co.nz/main/blackmagic Black Sphere Technology website].<br />
<br />
To use Black Magic Probe instead of FLOSS-JTAG or Luftboot for firmware flashing, append the following string to the upload command:<br />
<br />
On Linux:<br />
FLASH_MODE=JTAG_BMP BMP_PORT=/dev/ttyACM0<br />
On Mac OS:<br />
FLASH_MODE=JTAG_BMP BMP_PORT=/dev/cu.usbmodem<serial><br />
<br />
To make this the default flash method add this in the airframe file firmware section:<br />
<configure name="FLASH_MODE" value="JTAG_BMP"/><br />
<configure name="BMP_PORT" value="/dev/ttyACM0"/><br />
<br />
See the [[FirmwareFlashing]] page for other methods.<br />
<br />
==== Benefits ====<br />
<br />
There are good reasons to use the Black Magic Probe Mini instead of FLOSS-JTAG:<br />
<br />
*Lower cost<br />
*No need for OpenOCD as BMPM has a built in GDB server<br />
*Orders of magnitude faster as all the high speed protocol logic happens on the built-in STM32<br />
*Supports Serial Wire Debug (SWD)<br />
*Supports tracing using the SWD trace pin<br />
*No need for loading and unloading of FTDI drivers on Mac OS X<br />
<br />
====UART port====<br />
The pinout for the UART port on the back side of the BMP as seen on the image above and starting from the top is ground,rx,tx,3.3v . You can use this for receiving telemetry.<br />
<br />
====Upgrade BMP firmware====<br />
<br />
Check firmware version:<br />
$ sudo /usr/bin/arm-none-eabi-gdb<br />
(gdb) target extended-remote /dev/ttyACM0<br />
(gdb) monitor version<br />
<br />
To upgrade the brain of your Black Magic Probe, a.k.a. its firmware:<br />
<br />
- Download the compiled firmware from http://blacksphere.co.nz/builds/ (more info at https://github.com/blacksphere/blackmagic/wiki/Frequently-Asked-Questions)<br />
- Download and run the stm32_mem.py script:<br />
$ git clone git://blackmagicdebug.git.sourceforge.net/gitroot/blackmagicdebug/blackmagicdebug<br />
$ cd blackmagicdebug/scripts<br />
$ ./stm32_mem.py blackmagic-XXXX.bin (this is the .bin file you downloaded in previous step)<br />
<br />
=== FT2232H Mini Module ===<br />
<br />
Use ftdi prog to change the Description String into: FLOSS-JTAG. <br/><br />
More information for this board at [[Serial_Adapter]].<br />
[[File:AlternativeFlossJtag.png]]<br />
<br />
[[Category:Hardware]] [[Category:Software]] [[Category:Developer_Documentation]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Vibration&diff=20520Vibration2015-12-11T09:54:20Z<p>Ewoud: /* IMU + Vibrations and attitude */</p>
<hr />
<div>Vibration can be a major problem in small UAVs (fixedwing and rotorcraft alike). Vibration can come from a variety of sources, but in UAVs the most significant source is rotating machinery, i.e. the primary powerplants in the airframe.<br />
<br />
''Major Sources of Vibration:''<br />
* Main electric motors<br />
* Internal combustion (IC) engines<br />
* Unbalanced propellers<br />
''Minor Sources of Vibration:''<br />
* Flutter or resonance in flight surfaces and airframe<br />
* Actuators or servos for flight or payload control<br />
In general, the main source of thrust will be the primary source of vibration. Electric motors generally do not introduce strong vibrations into the airframe, though an unbalanced propeller on an electric motor can be very noticeable. On the other hand, IC engines, whether glow or spark ignition, usually introduce extreme amounts of vibration into an airframe.<br />
<br />
A brief introduction to vibration can be found on Wikipedia [http://en.wikipedia.org/wiki/Vibration here].<br />
<br />
=== Implications of Vibration ===<br />
Vibration can have many detrimental effects on UAV airframes. Some examples are:<br />
* airframe fatigue<br />
** can affect glue joints or high stress locations<br />
** reduces lifetime of servo actuators<br />
** touching components can wear away at one another<br />
*** fuel line or motor cable on sharp edge of bulkhead<br />
* foaming fuel<br />
* wiring fatigue (including RF connections)<br />
** wire strands on sharp connector or crimp edges<br />
** connectors rated for limited insertions, removals, as well as vibration<br />
** switches can degrade, fail, switch in flight<br />
***look for MIL spec parts with high vibration ratings<br />
* lower flight and powerplant efficiency<br />
* increased sensor noise and bias<br />
** gyros, accelerometers, magnetometers, pressure transducers, etc<br />
* potential for sensor saturation<br />
** in particular, gyros and accelerometers in IMU<br />
* degradation of payload sensor data quality<br />
**especially imagery with CMOS sensors, increase in rolling shutter effects, motion blur, shaky video<br />
<br />
Electronics (PCBs and components) are particularly affected by high frequency vibration. An interesting discussion about vibration isolation of PCBs and their transmissibility and dynamic response can be found in:<br />
''A. Veprik. Vibration protection of critical components of electronic equipment in harsh environmental conditions. Journal of Sound and Vibration, 259(1):161 – 175, 2003.''<br />
<br />
One of the '''most noticeable problems''' with high vibrations is in '''attitude estimation'''. MEMS '''gyros and accelerometers''' can be very '''sensitive to vibration''', and the filtering algorithm can not always fix the problem. The vibration can sometimes cause significant drift or divergence of the filtering algorithm, making the attitude estimation useless.<br />
<br />
Usually large amounts of vibration are obvious based on the feel and sight of a shaking airframe. Measuring the vibration can be very useful. It can provide insight as to the frequency of the vibration and the amplitude of the vibration. If vibration is proving problematic, making a baseline measurement is helpful to compare to vibrations after mitigation modifications. Often, modifications one may think would help deal with the vibration results in an even worse problem! In general, both the amplitudes and dominant frequencies of the vibration will change with modifications.<br />
<br />
Note that vibrations are also quite important for gyro's. On accelerometers the standard deviation is a good measure for the noise band. However, on gyro's it is not the noise band that is detrimental, but the fact that vibrations can change the bias (rapidly). <br />
<br />
MEMS and piezo gyroscopes (actively vibrating elements in x-direction that measure residual vibration in the y-direction since during a rotation due to inertia the active x vibration will lag and be visible in y) are by design always sensitive to vibrations (it's a vibrating element that senses vibrations), temperature (material properties) and g-forces (bending causes capacitive changes while the capacity is used to sense vibrations). <br />
<br />
To limit the effect of external vibrations the resonating frequency is quite high and different on each axis. (20 to 30 kHz) and many other tricks are used. So to asses the damage of external vibrations on gyros you should check the average (bias) with and without external vibrations and look at the vibration spectrum. The biggest problem here is that we are looking at frequencies above the accelerometer measurement range. Anything above 15kHz will have "some" influence in "some" cases.<br />
<br />
=== Mitigating Effects of Vibration ===<br />
There are a number of strategies for mitigating vibration effects in the airframe. The best results are in a combination of both mechanical damping and software filtering. Please note these are NOT equivalent. For example, if the bias of the gyro seems to change significantly at certain throttle settings it can not be undone with filtering afterwards, while mechanical damping can help prevent the bias change in the first place.<br />
<br />
Mechanical isolation is generally best, and can be applied (ideally) at the source of the vibration, or at the interface of a particularly sensitive component (i.e. IMU or camera). Isolating at the source helps all parts of the airframe, not just a single component.<br />
<br />
Good vibration damping is not easy either. Some simple rubber bobbins on PCBs for instance can also increase the vibration amplitude. And the lighter the electronics, the harder it is to dampen it. Very little soft foam on the corners has so far been the best trick. When possible it is good to put the battery + autopilot + all weight that can be found that needs to fly on 1 piece of wood, which is mounted on the fuselage using 4 small corners of foam. The smaller the weight, the looser the dampers you need (i.e. lower spring constant). For example, to dampen a Lisa/M board four pieces of 4x4x10 millimeter of packing-foam in the 4 corners are probably stiff enough.<br />
<br />
Unfortunately, mechanical isolation may not be sufficient under high vibration or for particularly sensitive components. It also may not be practical due to size and weight limitations. In these cases, digital (or analog) filtering may help sensor output. Filtering raw sensor data prior to use for the user or various algorithms has advantages and disadvantages. Depending on the filter chosen, one may lose important information in the signal, induce a time delay detrimental to real-time execution of algorithms, etc. Considerable discussion on digital signal processing and filtering can be found elsewhere. In some cases, small time delays or reduced information content are acceptable compromises for enhance performance elsewhere, like in an AHRS or INS estimator, or when processing or viewing images and video.<br />
<br />
Note that a low-pass filter on the gyroscopes in an IMU is almost never useful, while filtering on the accelerometers is usually better.<br />
<br />
=== IMU + Vibrations and attitude ===<br />
<br />
Be sure to always mind following constraints:<br />
<br />
* mechanical damping until all vibrations are at least withing measurement range at all frequencies : (careful in very small vehicles this vibration might be of higher frequency than the sensor can measure: e.g. 1kHz 20g vibration on aspirin will be seen as measurements of only 6 to 8g while gravity is becomes 0.5g instead of 1g, so not always obvious)<br />
* accelerometer should be filtering BEFORE AHRS computations but with minimal lag (a sudden 45 deg roll should not be counter-compensated for 0.5 seconds just because the accelerometer is slow). With mechanical damping at least gyro and accelero feel the same motion.<br />
* gyro filtering should be AFTER INTEGRTION in ahrs since simple filtering (e.g. xf = (xm-xf)/K ) can distort the integral<br />
* in AHRS with V x omega as compensation for centripetal force: omega is often filled with gyro measurements while in theory it should be the turn rate or looping rate. Short period dynamics of the plane should be filtered out first: e.g. at 20m/s during a 10deg/sec turn (=0.35g) a gust easily makes a 300deg/sec short period oscillation (=10.5g which is not present and not measured either and very quickly screws attitude)<br />
<br />
==== Complementary AHRS ====<br />
In the AHRS type int_cmpl_quat there is a heuristic that scales down the usage of the accelerometer if deviations from 1g are measured. This can potentially improve the state estimate as dynamic accelerations are not compensated for in the filter. However, if large deviations from 1g are continuously measured due to vibrations, the accelerometer is not used most of the time. This will cause the attitude estimate to drift. In this case, it is better not to use the heuristic and define AHRS_GRAVITY_HEURISTIC_FACTOR to 0 in the airframe file.<br />
<br />
=== Measuring Vibration ===<br />
<br />
In the '''Telemetry''' tab of the '''Settings''' tool, enable the collection of scaled sensor messages (''scaled_sensors''). Remember to commit the selection by pressing the ''green checkmark'' button.<br />
<br />
[[Image:Scaled_Sensor_Telemetry.png|750x650px]]<br />
<br />
Once the data is logged, the '''report_imu_scaled''' tool is used to quickly analyze and generate metrics related to the captured flight data.<br />
<br />
<nowiki><br />
$ ./sw/tools/calibration/report_imu_scaled.py -h<br />
Usage: report_imu_scaled.py [options] log_filename.data<br />
Run report_imu_scaled.py --help to list the options.<br />
<br />
Options:<br />
-h, --help show this help message and exit<br />
-i AC_ID, --id=AC_ID aircraft id to use<br />
-p, --plot Show resulting plots<br />
-s START, --start=START<br />
start time in seconds<br />
-e END, --end=END end time in seconds<br />
-v, --verbose <br />
</nowiki><br />
<br />
<nowiki><br />
./sw/tools/calibration/report_imu_scaled.py -p -s 100 -e 220 ../../paparazzi/var/logs/15_04_04__16_50_40.data<br />
</nowiki><br />
<br />
==== Accelerometer (Vibration)====<br />
<br />
<nowiki><br />
ACCEL : Time Range(100.006 : 220.982)<br />
ax ay az<br />
Min [ -2.413 -2.507 -24.158] m/s2<br />
Max [ 2.170 2.066 7.477] m/s2<br />
Mean [ -0.019 -0.580 -9.549] m/s2<br />
StDev [ 0.731 0.758 5.936] m/s2<br />
</nowiki><br />
<br />
[[Image:150404_165049_accel.png|750x650px]]<br />
<br />
==== Gyroscope ====<br />
<nowiki><br />
GYRO : Time Range(100.342 : 220.998)<br />
gp gq gr<br />
Min [-50.358 -47.924 -38.048] deg/s<br />
Max [ 51.574 47.000 25.668] deg/s<br />
Mean [ 0.661 0.019 -0.849] deg/s<br />
StDev [ 17.431 15.366 5.136] deg/s<br />
</nowiki><br />
<br />
[[Image:150404_165040_gyro.png|750x650px]]<br />
<br />
==== Magnetometer (EMI) ====<br />
<br />
<nowiki><br />
MAG : Time Range(100.022 : 220.934)<br />
mx my mz<br />
Min [ -0.534 -0.594 0.953] unit<br />
Max [ 0.089 0.000 1.079] unit<br />
Mean [ -0.201 -0.405 1.019] unit<br />
StDev [ 0.163 0.083 0.019] unit<br />
</nowiki><br />
<br />
[[Image:150404_165040_mag.png|750x650px]]<br />
<br />
=== Case Studies ===<br />
Feel free to add your own case study!<br />
<br />
==== Senior Telemaster with Gas Engine ====<br />
A Senior Telemaster ARF airframe was modified and equipped with a TWOG and Aspirin IMU (among others, see [[UAlberta UASGroup|here]] for details). A 25cc single cylinder 2-stroke electronic ignition gas engine is used to power the aircraft. The light wooden airframe combined with the high power from this engine results in very heavy vibration in the airframe.<br />
<br />
[[File:Vibration_telemaster_fuse.png|none|400px|Acceleration levels at Senior Telemaster fuselage floor]]<br />
[[File:Vibration_telemaster_fuse_fft.png|400px|FFT of acceleration levels at Senior Telemaster fuselage floor]]<br />
<br />
The airframe is configured to use the float_dcm AHRS algorithm. Under these vibration conditions, considerable drift in attitude estimation is visible.<br />
<br />
[[File:DCM_drift_vibration_telemaster.png|600px|none|Attitude drift using DCM algorithm from vibration in Senior Telemaster]]<br />
<br />
To deal with this problem, a mount for the IMU and other electronics was quickly thrown together, with little design. When installed in the airframe, the mount helped reduce high frequency vibration (more than a few hundred Hertz), but did little to mitigate lower frequency vibration. In fact, at a few specific operating frequencies, the mount actually resonated, resulting in WORSE performance. This effect was verified in a controlled vibration environment.<br />
<br />
PICTURE HERE OF SHAKER TABLE<br />
<br />
Based on these results, further investigation was made into isolating the IMU. Two approaches were pursued: a more carefully designed mounting system and software filtering. A number of spring/damper materials were tested, and it was found that latex foam rubber provided good characteristics, with damping and a relatively low spring constant. It is also easy to obtain at model aircraft hobby stores or from memory foam sleep products (pillows, mattresses). After extensive testing, the following was concluded. It is desirable for the natural frequency of the mount to be driven as low as possible. This ensures lowest transmissibility of damaging high frequency vibrations and reduces the amplitude of vibration at lower forcing frequencies. This would imply a low spring constant and/or high mass for the IMU based on the equation for [http://en.wikipedia.org/wiki/Vibration#Free_vibration_without_damping calculating natural frequency]. On the other hand, the IMU can not be allowed extensive motion. Large amplitude linear motion increases accelerometer noise while large angular motions increases gyroscope noise. Thus, the mount must be fairly soft, but with a limited range of motion. The final design is illustrated.<br />
<br />
[[File:Imu_mount_example1.JPG|none|400px|Illustration of IMU mount used in Senior Telemaster]]<br />
<br />
Alone, this new mount was not sufficient in reducing the attitude estimation drift to an acceptable level. In particular, the accelerometers were experiencing considerable noise. An evenly weighted moving average filter was applied in software to all raw accelerometer readings. While this induced a small delay in the sampled data, the DCM algorithm can handle this, as the acceleration is used only as a correction in pitch and roll for the gyro rate data integration. As a comparison, the GPS data comes in at a much slower rate, with some level of delay, and is used to correct yaw. A window size of 8 samples was used in the moving average filter, which, when sampled at 100Hz, does not significantly delay the data. Using this filter, the improvement in the attitude estimation was quite dramatic.<br />
<br />
[[File:Imu_mount_filter_vs_none.png|600px|none|Effect of filtering acceleration data on attitude drift and apparent transmissibility]]<br />
<br />
For interest, the gyro data was filtered in a similar manner to the accelerometer data, and the performance of the DCM algorithm was considerably reduced due to the delay and loss of information for numerical integration from the averaging at these low frequencies.<br />
<br />
A balance must be struck between the mechanical isolation and the filtering to achieve good performance. Work in progress for this aircraft will include designing a better engine mount to try to isolate the vibration at the source.</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Subsystem/stabilization&diff=19924Subsystem/stabilization2015-06-17T12:41:14Z<p>Ewoud: /* Attitude Control Implementations */</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree><br />
== Stabilization subsystem ==<br />
The ''stabilization'' subsystem provides the attitude controller for rotorcrafts.<br />
<br />
Currently possible attitude ''stabilization'' subsystem types are<br />
* ''[[Subsystem/stabilization#Quaternion|int_quat]]''<br />
* ''[[Subsystem/stabilization#Quaternion|float_quat]]''<br />
* ''[[Subsystem/stabilization#Euler|int_euler]]''<br />
* ''[[Subsystem/stabilization#Euler|float_euler]]''<br />
* ''[[Subsystem/stabilization#INDI|indi]]''<br />
<br />
== Attitude Control Implementations ==<br />
There are several different attitude control algorithm implementations.<br />
<br />
They use the same ''STABILIZATION_ATTITUDE'' xml configuration section:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE" prefix="STABILIZATION_ATTITUDE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_PHI" value="45." unit="deg"/><br />
<define name="SP_MAX_THETA" value="45." unit="deg"/><br />
<define name="SP_MAX_R" value="90." unit="deg/s"/><br />
<define name="DEADBAND_A" value="0"/><br />
<define name="DEADBAND_E" value="0"/><br />
<define name="DEADBAND_R" value="250"/><br />
<br />
<!-- reference --><br />
<define name="REF_OMEGA_P" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_P" value="0.85"/><br />
<define name="REF_MAX_P" value="400." unit="deg/s"/><br />
<define name="REF_MAX_PDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_Q" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_Q" value="0.85"/><br />
<define name="REF_MAX_Q" value="400." unit="deg/s"/><br />
<define name="REF_MAX_QDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_R" value="500" unit="deg/s"/><br />
<define name="REF_ZETA_R" value="0.85"/><br />
<define name="REF_MAX_R" value="180." unit="deg/s"/><br />
<define name="REF_MAX_RDOT" value="RadOfDeg(1800.)"/><br />
<br />
<!-- feedback --><br />
<define name="PHI_PGAIN" value="1000"/><br />
<define name="PHI_DGAIN" value="400"/><br />
<define name="PHI_IGAIN" value="200"/><br />
<br />
<define name="THETA_PGAIN" value="1000"/><br />
<define name="THETA_DGAIN" value="400"/><br />
<define name="THETA_IGAIN" value="200"/><br />
<br />
<define name="PSI_PGAIN" value="500"/><br />
<define name="PSI_DGAIN" value="300"/><br />
<define name="PSI_IGAIN" value="10"/><br />
<br />
<!-- feedforward --><br />
<define name="PHI_DDGAIN" value="300"/><br />
<define name="THETA_DDGAIN" value="300"/><br />
<define name="PSI_DDGAIN" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
<br />
; ''SP_MAX_*'': maximum ''PHI''/''THETA'' (roll/pitch) angles and maximum angular velocity ''R'' around yaw axis<br />
; ''DEADBAND_*'': RC stick deadband around the center for ''A'',''E'',''R'' (roll,pitch,yaw)<br />
; ''REF_*'': parameters for the [[Control_Loops#Reference_generators_2|reference generator]]<br />
; ''REF_OMEGA_*'' : second order model natural frequency for respective axis<br />
; ''REF_ZETA_*'' : second order model damping factor for respective axis<br />
; ''REF_MAX_x'' : bound on ref model angular speed<br />
; ''REF_MAX_xDOT'' : bound on ref model angular acceleration<br />
; ''[PHI|THETA|PSI]_[PID]GAIN'': gains for the feedback control of the respective axis<br />
; ''[PHI|THETA|PSI]_DDGAIN'': feedforward gains for the respective axis<br />
<br />
=== Quaternion ===<br />
Attitude controllers using quaternions (no gimbal lock).<br />
There is a fixed point implementation (recommended) and a floating point implementation for reference and testing.<br />
<br />
* fixed point: <source lang="xml"><subsystem name="stabilization" type="int_quat"/></source><br />
* floating point: <source lang="xml"><subsystem name="stabilization" type="float_quat"/></source><br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_quat"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== Euler ===<br />
Attitude controller using Euler Angles. Due to the inherent singularities (e.g. 90deg pitch) of the euler angles representation you can't use this controller if you want to fly in regimes close or at these singularities (e.g. acrobatics or transitioning vehicles).<br />
See [[Control_Loops#Attitude_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_euler"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== INDI ===<br />
Attitude controller based on an Incremental Nonlinear Dynamic Inversion inner loop. It controls the angular acceleration in an incremental way. More detailed information will follow after publication of the paper 'Adaptive Incremental Nonlinear Dynamic Inversion for Micro Aerial Vehicles'.<br />
<br />
Early adopters can take a look at the ardrone2_indi airframe file. Important settings are located in the STABILIZATION_ATTITUDE_INDI section. <br />
<br />
The control effectiveness is what relates inputs to the actuators to angular accelerations. These values are not meant to be tuned. They can be obtained from flight logs, or by using the adaptive algorithm. <br />
<br />
The reference acceleration gains are kinematic gains that provide a reference to the angular acceleration controller. These gains depend on the actuator dynamics, but they can also be tuned.<br />
<br />
The filter parameters are the omega and zeta of a second order filter on the gyroscope. Use a higher omega to get faster disturbance rejection, or a lower omega to filter more noise. I have used omega=50 for well-damped frames and omega=20 for badly damped frames.<br />
<br />
First order actuator dynamics are assumed, written as: act(i+1) = act(i) + alpha*(input - act(i)), where alpha is the value that can be specified in the airframe file. It can be obtained with a step response of the motors, using for instance a logic analyzer and a light sensor to record the spinup profile.<br />
<br />
It is advised to start out with ADAPTIVE_INDI FALSE. Eventually this feature can be very helpful, but it is a bit tricky. Problems can occur when:<br />
<br />
- You don't take off right away, but keep in contact with the ground. A wrong effectiveness is estimated. The estimation goes quite fast, so if the drone doesn't rotate because it is still on the ground, the actuators are estimated to be very ineffective and large commands will be sent to the motors. So interaction with anything other than air is not advised. <br />
<br />
- You have a hard mounted IMU with a lot of noise, this might affect the adaptation.<br />
<br />
== Rate Control ==<br />
There is only one rate control implementation (which is included in the rotorcraft firmware by default). It allows you to fly a rotorcraft like a helicopter by controlling the angular rate directly instead of having (self-leveling) attitude control.<br />
See [[Control_Loops#Rate_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
</firmware><br />
<br />
<section name="STABILIZATION_RATE" prefix="STABILIZATION_RATE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_P" value="10000"/><br />
<define name="SP_MAX_Q" value="10000"/><br />
<define name="SP_MAX_R" value="10000"/><br />
<define name="DEADBAND_P" value="20"/><br />
<define name="DEADBAND_Q" value="20"/><br />
<define name="DEADBAND_R" value="200"/><br />
<define name="REF_TAU" value="4"/><br />
<br />
<!-- feedback --><br />
<define name="GAIN_P" value="400"/><br />
<define name="GAIN_Q" value="400"/><br />
<define name="GAIN_R" value="350"/><br />
<br />
<define name="IGAIN_P" value="75"/><br />
<define name="IGAIN_Q" value="75"/><br />
<define name="IGAIN_R" value="50"/><br />
<br />
<!-- feedforward --><br />
<define name="DDGAIN_P" value="300"/><br />
<define name="DDGAIN_Q" value="300"/><br />
<define name="DDGAIN_R" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
[[Category:User_Documentation]] [[Category:Subsystems]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Subsystem/stabilization&diff=19923Subsystem/stabilization2015-06-17T12:04:45Z<p>Ewoud: /* Stabilization subsystem */</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree><br />
== Stabilization subsystem ==<br />
The ''stabilization'' subsystem provides the attitude controller for rotorcrafts.<br />
<br />
Currently possible attitude ''stabilization'' subsystem types are<br />
* ''[[Subsystem/stabilization#Quaternion|int_quat]]''<br />
* ''[[Subsystem/stabilization#Quaternion|float_quat]]''<br />
* ''[[Subsystem/stabilization#Euler|int_euler]]''<br />
* ''[[Subsystem/stabilization#Euler|float_euler]]''<br />
* ''[[Subsystem/stabilization#INDI|indi]]''<br />
<br />
== Attitude Control Implementations ==<br />
There are several different attitude control algorithm implementations.<br />
<br />
They use the same ''STABILIZATION_ATTITUDE'' xml configuration section:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="STABILIZATION_ATTITUDE" prefix="STABILIZATION_ATTITUDE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_PHI" value="45." unit="deg"/><br />
<define name="SP_MAX_THETA" value="45." unit="deg"/><br />
<define name="SP_MAX_R" value="90." unit="deg/s"/><br />
<define name="DEADBAND_A" value="0"/><br />
<define name="DEADBAND_E" value="0"/><br />
<define name="DEADBAND_R" value="250"/><br />
<br />
<!-- reference --><br />
<define name="REF_OMEGA_P" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_P" value="0.85"/><br />
<define name="REF_MAX_P" value="400." unit="deg/s"/><br />
<define name="REF_MAX_PDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_Q" value="800" unit="deg/s"/><br />
<define name="REF_ZETA_Q" value="0.85"/><br />
<define name="REF_MAX_Q" value="400." unit="deg/s"/><br />
<define name="REF_MAX_QDOT" value="RadOfDeg(8000.)"/><br />
<br />
<define name="REF_OMEGA_R" value="500" unit="deg/s"/><br />
<define name="REF_ZETA_R" value="0.85"/><br />
<define name="REF_MAX_R" value="180." unit="deg/s"/><br />
<define name="REF_MAX_RDOT" value="RadOfDeg(1800.)"/><br />
<br />
<!-- feedback --><br />
<define name="PHI_PGAIN" value="1000"/><br />
<define name="PHI_DGAIN" value="400"/><br />
<define name="PHI_IGAIN" value="200"/><br />
<br />
<define name="THETA_PGAIN" value="1000"/><br />
<define name="THETA_DGAIN" value="400"/><br />
<define name="THETA_IGAIN" value="200"/><br />
<br />
<define name="PSI_PGAIN" value="500"/><br />
<define name="PSI_DGAIN" value="300"/><br />
<define name="PSI_IGAIN" value="10"/><br />
<br />
<!-- feedforward --><br />
<define name="PHI_DDGAIN" value="300"/><br />
<define name="THETA_DDGAIN" value="300"/><br />
<define name="PSI_DDGAIN" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
<br />
; ''SP_MAX_*'': maximum ''PHI''/''THETA'' (roll/pitch) angles and maximum angular velocity ''R'' around yaw axis<br />
; ''DEADBAND_*'': RC stick deadband around the center for ''A'',''E'',''R'' (roll,pitch,yaw)<br />
; ''REF_*'': parameters for the [[Control_Loops#Reference_generators_2|reference generator]]<br />
; ''REF_OMEGA_*'' : second order model natural frequency for respective axis<br />
; ''REF_ZETA_*'' : second order model damping factor for respective axis<br />
; ''REF_MAX_x'' : bound on ref model angular speed<br />
; ''REF_MAX_xDOT'' : bound on ref model angular acceleration<br />
; ''[PHI|THETA|PSI]_[PID]GAIN'': gains for the feedback control of the respective axis<br />
; ''[PHI|THETA|PSI]_DDGAIN'': feedforward gains for the respective axis<br />
<br />
=== Quaternion ===<br />
Attitude controllers using quaternions (no gimbal lock).<br />
There is a fixed point implementation (recommended) and a floating point implementation for reference and testing.<br />
<br />
* fixed point: <source lang="xml"><subsystem name="stabilization" type="int_quat"/></source><br />
* floating point: <source lang="xml"><subsystem name="stabilization" type="float_quat"/></source><br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_quat"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
=== Euler ===<br />
Attitude controller using Euler Angles. Due to the inherent singularities (e.g. 90deg pitch) of the euler angles representation you can't use this controller if you want to fly in regimes close or at these singularities (e.g. acrobatics or transitioning vehicles).<br />
See [[Control_Loops#Attitude_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="stabilization" type="int_euler"/><br />
</firmware><br />
</source><br />
}}<br />
You also need the ''STABILIZATION_ATTITUDE'' xml configuration section as described above.<br />
<br />
== Rate Control ==<br />
There is only one rate control implementation (which is included in the rotorcraft firmware by default). It allows you to fly a rotorcraft like a helicopter by controlling the angular rate directly instead of having (self-leveling) attitude control.<br />
See [[Control_Loops#Rate_loop]] for diagrams of the control loop.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
</firmware><br />
<br />
<section name="STABILIZATION_RATE" prefix="STABILIZATION_RATE_"><br />
<!-- setpoints --><br />
<define name="SP_MAX_P" value="10000"/><br />
<define name="SP_MAX_Q" value="10000"/><br />
<define name="SP_MAX_R" value="10000"/><br />
<define name="DEADBAND_P" value="20"/><br />
<define name="DEADBAND_Q" value="20"/><br />
<define name="DEADBAND_R" value="200"/><br />
<define name="REF_TAU" value="4"/><br />
<br />
<!-- feedback --><br />
<define name="GAIN_P" value="400"/><br />
<define name="GAIN_Q" value="400"/><br />
<define name="GAIN_R" value="350"/><br />
<br />
<define name="IGAIN_P" value="75"/><br />
<define name="IGAIN_Q" value="75"/><br />
<define name="IGAIN_R" value="50"/><br />
<br />
<!-- feedforward --><br />
<define name="DDGAIN_P" value="300"/><br />
<define name="DDGAIN_Q" value="300"/><br />
<define name="DDGAIN_R" value="300"/><br />
</section><br />
</source><br />
}}<br />
<br />
[[Category:User_Documentation]] [[Category:Subsystems]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Rolling_Spider&diff=19756Rolling Spider2015-04-17T16:07:51Z<p>Ewoud: /* Connect with Bluetooth */</p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:RS_BLUE_FrontView_Wheels_Sticker.jpeg|right|500px|Parrot Rolling Spider]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
== Intro ==<br />
Originally the [http://www.parrot.com/usa/products/rolling-spider/ Rolling Spider] from [http://www.parrot.com/ Parrot] is a Bluetooth controlled flying quadrotor, designed to be controlled with an Android or iOS device. <br />
Not any more: With a few simple clicks you can run Paparazzi on the Bebop and have full autonomous flight and much more!<br />
<br />
== Features ==<br />
=== Connectivity ===<br />
* Bluetooth Smart technology, Bluetooth V4.0 BLE (Bluetooth Low Energy).<br />
* Normal bluetooth also possible<br />
<br />
=== Sensors ===<br />
* Ultrasonic sensor<br />
* 3-axis gyroscope and 3-axis accelerometer (MPU 6050)<br />
* Vertical camera <br />
* Pressure sensor<br />
<br />
=== Battery ===<br />
Lithium-Polymer and removable<br />
Lasts up 8 min (6 min with wheels) and full recharge in 90 min<br />
<br />
=== Weight / Dimensions ===<br />
* 55g (65g with wheels)<br />
* Rolling Spider diameter: 140 mm<br />
* Propellers' diameter: 55mm<br />
* Motor spacing: 85 mm<br />
<br />
== How to connect ==<br />
There are two ways to connect to the Rolling Spider with Paparazzi. The first one is an USB cable and the second one is Bluetooth (4.0 or normal). Both have the possibility to connect as WiFi access point and transfer files through FTP and execute programs over telnet. But be warned that connecting over USB disables the vertical camera, as it uses the same USB bus.<br />
<br />
=== Connect with USB ===<br />
* Set the Rolling spider on<br />
* Just plug in a micro-usb cable from your drone to the computer<br />
* A new network device will show up<br />
* Connect with '''192.168.2.1''' through ftp or telnet<br />
<br />
=== Connect with Bluetooth ===<br />
* Turn the rolling spider on<br />
* Make sure you have bluetooth enabled on your computer<br />
* Execute "hcitool scan" and look for the mac address of the "RS_...." device. (If you cannot find it look at [[#Setup normal Bluetooth]])<br />
* Install the bluez-utils package (if not installed) with "sudo apt-get install bluez-utils"<br />
* Execute "sudo pand --connect <MAC address> -dGN -n", to connect to the bluetooth of the drone. *<br />
* Execute "sudo ifconfig bnep0 192.168.1.2 up", to setup the ethernet device over bluetooth. *<br />
* Connect with '''192.168.1.1''' through ftp or telnet<br />
<nowiki>*</nowiki> This has to be done everytime you reboot the drone<br />
<br />
-- Note -- <br />
* You will need to enable the actuators by telnetting to the drone and typing: gpio 39 -d lo 0<br />
* After uploading Paparazzi, you have to start it manually via telnet.<br />
* Go to /data/video and type ./ap.elf<br />
<br />
=== Setup normal Bluetooth ===<br />
* First connect over Bluetooth 4.0 or USB to the drone as described above<br />
* Connect with telnet to the drone. (telnet 192.168.*.1)<br />
* Open the "/etc/init.d/rcS" file and search for the line with "BLEproxy". (vi /etc/init.d/rcS)<br />
* Now change the "BLEproxy" to "BLEproxy --normalbt"<br />
* Reboot your drone by executing: "reboot". (This makes sure the filesystem is saved)<br />
<br />
[[Category:Autopilots]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Rolling_Spider&diff=19755Rolling Spider2015-04-17T16:06:36Z<p>Ewoud: /* Connect with Bluetooth */</p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:RS_BLUE_FrontView_Wheels_Sticker.jpeg|right|500px|Parrot Rolling Spider]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
== Intro ==<br />
Originally the [http://www.parrot.com/usa/products/rolling-spider/ Rolling Spider] from [http://www.parrot.com/ Parrot] is a Bluetooth controlled flying quadrotor, designed to be controlled with an Android or iOS device. <br />
Not any more: With a few simple clicks you can run Paparazzi on the Bebop and have full autonomous flight and much more!<br />
<br />
== Features ==<br />
=== Connectivity ===<br />
* Bluetooth Smart technology, Bluetooth V4.0 BLE (Bluetooth Low Energy).<br />
* Normal bluetooth also possible<br />
<br />
=== Sensors ===<br />
* Ultrasonic sensor<br />
* 3-axis gyroscope and 3-axis accelerometer (MPU 6050)<br />
* Vertical camera <br />
* Pressure sensor<br />
<br />
=== Battery ===<br />
Lithium-Polymer and removable<br />
Lasts up 8 min (6 min with wheels) and full recharge in 90 min<br />
<br />
=== Weight / Dimensions ===<br />
* 55g (65g with wheels)<br />
* Rolling Spider diameter: 140 mm<br />
* Propellers' diameter: 55mm<br />
* Motor spacing: 85 mm<br />
<br />
== How to connect ==<br />
There are two ways to connect to the Rolling Spider with Paparazzi. The first one is an USB cable and the second one is Bluetooth (4.0 or normal). Both have the possibility to connect as WiFi access point and transfer files through FTP and execute programs over telnet. But be warned that connecting over USB disables the vertical camera, as it uses the same USB bus.<br />
<br />
=== Connect with USB ===<br />
* Set the Rolling spider on<br />
* Just plug in a micro-usb cable from your drone to the computer<br />
* A new network device will show up<br />
* Connect with '''192.168.2.1''' through ftp or telnet<br />
<br />
=== Connect with Bluetooth ===<br />
* Turn the rolling spider on<br />
* Make sure you have bluetooth enabled on your computer<br />
* Execute "hcitool scan" and look for the mac address of the "RS_...." device. (If you cannot find it look at [[#Setup normal Bluetooth]])<br />
* Install the bluez-utils package (if not installed) with "sudo apt-get install bluez-utils"<br />
* Execute "sudo pand --connect <MAC address> -dGN -n", to connect to the bluetooth of the drone. *<br />
* Execute "sudo ifconfig bnep0 192.168.1.2 up", to setup the ethernet device over bluetooth. *<br />
* Connect with '''192.168.1.1''' through ftp or telnet<br />
<nowiki>*</nowiki> This has to be done everytime you reboot the drone<br />
<br />
-- Note -- <br />
You will need to enable the actuators by telnetting to the drone and typing: gpio 39 -d lo 0\\<br />
After uploading Paparazzi, you have to start it manually via telnet.\\<br />
Go to /data/video and type ./ap.elf<br />
<br />
=== Setup normal Bluetooth ===<br />
* First connect over Bluetooth 4.0 or USB to the drone as described above<br />
* Connect with telnet to the drone. (telnet 192.168.*.1)<br />
* Open the "/etc/init.d/rcS" file and search for the line with "BLEproxy". (vi /etc/init.d/rcS)<br />
* Now change the "BLEproxy" to "BLEproxy --normalbt"<br />
* Reboot your drone by executing: "reboot". (This makes sure the filesystem is saved)<br />
<br />
[[Category:Autopilots]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Rolling_Spider&diff=19754Rolling Spider2015-04-17T16:04:39Z<p>Ewoud: /* Connect with Bluetooth */</p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:RS_BLUE_FrontView_Wheels_Sticker.jpeg|right|500px|Parrot Rolling Spider]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
== Intro ==<br />
Originally the [http://www.parrot.com/usa/products/rolling-spider/ Rolling Spider] from [http://www.parrot.com/ Parrot] is a Bluetooth controlled flying quadrotor, designed to be controlled with an Android or iOS device. <br />
Not any more: With a few simple clicks you can run Paparazzi on the Bebop and have full autonomous flight and much more!<br />
<br />
== Features ==<br />
=== Connectivity ===<br />
* Bluetooth Smart technology, Bluetooth V4.0 BLE (Bluetooth Low Energy).<br />
* Normal bluetooth also possible<br />
<br />
=== Sensors ===<br />
* Ultrasonic sensor<br />
* 3-axis gyroscope and 3-axis accelerometer (MPU 6050)<br />
* Vertical camera <br />
* Pressure sensor<br />
<br />
=== Battery ===<br />
Lithium-Polymer and removable<br />
Lasts up 8 min (6 min with wheels) and full recharge in 90 min<br />
<br />
=== Weight / Dimensions ===<br />
* 55g (65g with wheels)<br />
* Rolling Spider diameter: 140 mm<br />
* Propellers' diameter: 55mm<br />
* Motor spacing: 85 mm<br />
<br />
== How to connect ==<br />
There are two ways to connect to the Rolling Spider with Paparazzi. The first one is an USB cable and the second one is Bluetooth (4.0 or normal). Both have the possibility to connect as WiFi access point and transfer files through FTP and execute programs over telnet. But be warned that connecting over USB disables the vertical camera, as it uses the same USB bus.<br />
<br />
=== Connect with USB ===<br />
* Set the Rolling spider on<br />
* Just plug in a micro-usb cable from your drone to the computer<br />
* A new network device will show up<br />
* Connect with '''192.168.2.1''' through ftp or telnet<br />
<br />
=== Connect with Bluetooth ===<br />
* Turn the rolling spider on<br />
* Make sure you have bluetooth enabled on your computer<br />
* Execute "hcitool scan" and look for the mac address of the "RS_...." device. (If you cannot find it look at [[#Setup normal Bluetooth]])<br />
* Install the bluez-utils package (if not installed) with "sudo apt-get install bluez-utils"<br />
* Execute "sudo pand --connect <MAC address> -dGN -n", to connect to the bluetooth of the drone. *<br />
* Execute "sudo ifconfig bnep0 192.168.1.2 up", to setup the ethernet device over bluetooth. *<br />
* Connect with '''192.168.1.1''' through ftp or telnet<br />
<nowiki>*</nowiki> This has to be done everytime you reboot the drone<br />
<br />
-- Note -- <br />
You will need to enable the actuators by telnetting to the drone and typing: gpio 39 -d lo 0<br />
After uploading Paparazzi, you have to start it manually via telnet.<br />
Go to /data/video and type ./ap.elf<br />
<br />
=== Setup normal Bluetooth ===<br />
* First connect over Bluetooth 4.0 or USB to the drone as described above<br />
* Connect with telnet to the drone. (telnet 192.168.*.1)<br />
* Open the "/etc/init.d/rcS" file and search for the line with "BLEproxy". (vi /etc/init.d/rcS)<br />
* Now change the "BLEproxy" to "BLEproxy --normalbt"<br />
* Reboot your drone by executing: "reboot". (This makes sure the filesystem is saved)<br />
<br />
[[Category:Autopilots]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Rolling_Spider&diff=19727Rolling Spider2015-04-10T09:51:50Z<p>Ewoud: /* Connect with Bluetooth */</p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:RS_BLUE_FrontView_Wheels_Sticker.jpeg|right|500px|Parrot Rolling Spider]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
== Intro ==<br />
Originally the [http://www.parrot.com/usa/products/rolling-spider/ Rolling Spider] from [http://www.parrot.com/ Parrot] is a Bluetooth controlled flying quadrotor, designed to be controlled with an Android or iOS device. <br />
Not any more: With a few simple clicks you can run Paparazzi on the Bebop and have full autonomous flight and much more!<br />
<br />
== Features ==<br />
=== Connectivity ===<br />
* Bluetooth Smart technology, Bluetooth V4.0 BLE (Bluetooth Low Energy).<br />
* Normal bluetooth also possible<br />
<br />
=== Sensors ===<br />
* Ultrasonic sensor<br />
* 3-axis gyroscope and 3-axis accelerometer (MPU 6050)<br />
* Vertical camera <br />
* Pressure sensor<br />
<br />
=== Battery ===<br />
Lithium-Polymer and removable<br />
Lasts up 8 min (6 min with wheels) and full recharge in 90 min<br />
<br />
=== Weight / Dimensions ===<br />
* 55g (65g with wheels)<br />
* Rolling Spider diameter: 140 mm<br />
* Propellers' diameter: 55mm<br />
* Motor spacing: 85 mm<br />
<br />
== How to connect ==<br />
There are two ways to connect to the Rolling Spider with Paparazzi. The first one is an USB cable and the second one is Bluetooth (4.0 or normal). Both have the possibility to connect as WiFi access point and transfer files through FTP and execute programs over telnet. But be warned that connecting over USB disables the vertical camera, as it uses the same USB bus.<br />
<br />
=== Connect with USB ===<br />
* Set the Rolling spider on<br />
* Just plug in a micro-usb cable from your drone to the computer<br />
* A new network device will show up<br />
* Connect with '''192.168.2.1''' through ftp or telnet<br />
<br />
=== Connect with Bluetooth ===<br />
* Turn the rolling spider on<br />
* Make sure you have bluetooth enabled on your computer<br />
* Execute "hcitool scan" and look for the mac address of the "RS_...." device. (If you cannot find it look at [[#Setup normal Bluetooth]])<br />
* Install the bluez-utils package (if not installed) with "sudo apt-get install bluez-utils"<br />
* Execute "sudo pand --connect <MAC address> -dGN -n", to connect to the bluetooth of the drone. *<br />
* Execute "sudo ifconfig bnep0 192.168.1.2 up", to setup the ethernet device over bluetooth. *<br />
* Connect with '''192.168.1.1''' through ftp or telnet<br />
<nowiki>*</nowiki> This has to be done everytime you reboot the drone<br />
<br />
=== Setup normal Bluetooth ===<br />
* First connect over Bluetooth 4.0 or USB to the drone as described above<br />
* Connect with telnet to the drone. (telnet 192.168.*.1)<br />
* Open the "/etc/init.d/rcS" file and search for the line with "BLEproxy". (vi /etc/init.d/rcS)<br />
* Now change the "BLEproxy" to "BLEproxy --normalbt"<br />
* Reboot your drone by executing: "reboot". (This makes sure the filesystem is saved)<br />
<br />
[[Category:Autopilots]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=Module/AOA_adc&diff=16336Module/AOA adc2013-11-22T13:21:51Z<p>Ewoud: /* Hardware */</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree><br />
<br />
== Introduction ==<br />
<br />
AOA_adc is a simple module that is be written to test the flight behaviour with a Angle Of Attacke sensor. <br />
<br />
It reads the value of an defined ADC port and converts it to and angle. <br />
<br />
=== Implementation option A ===<br />
<br />
A mode variable named h_ctl_pitch_mode in the stabilization_attitude.c enables to switch between estimator_theta (IMU) and estimator_AOA to control the elevator.<br />
<br />
=== Measurements ===<br />
<br />
{TODO: description}<br />
<br />
== Hardware ==<br />
<br />
{TODO: image}<br />
<br />
Angle of Attack ADC Sensor<br />
*'''US DIGITAL MA3-A10-236-N'''<br />
If you are using the analog version of this sensor, be sure to connect it to a 5V tolerant ADC on you autopilot. For instance ADC2 on Lisa/M is not 5V tolerant, so a voltage divider is needed to scale the signal down to 3.3V.<br />
ModuleXML<br />
*AOA_adc.xml <br />
Code- and headerfile<br />
*sw/airborne/modules/sensors<br />
Settings file<br />
*AOA_adc.xml<br />
<br />
== Airframe Adjustments ==<br />
<br />
* (1) '''Insert''' the software module in the airframe:<br />
<source lang="xml"><br />
<modules><br />
<load name="AOA_adc.xml"> <br />
<configure name="ADC_AOA" value="ADC_6"/><br />
<define name="AOA_OFFSET" value="-0.135000005364"/> <br />
<define name="AOA_FILTER" value="0.875999987125"/> <br />
<define name="USE_AOA"/> <br />
</load> <br />
</modules><br />
</source><br />
* Legend:<br />
**The ACS_AOA defines on whitch port the US Digital Sensor is connected to.<br />
**The AOA_OFFSET is needed to adjust the Zero rad mark in the normal flightposition. It can be changed with the AOA_adc.xml settings loaded.<br />
**The AOA_FILTER describes the PT1 filter value of the angle. 0 = no filter<br />
**Define USE_AOA to make the module work.<br />
<br />
* (2) '''Load''' the settings XML in the GCS: AOA_adc.xml<br />
* (3) Now you can turn on the pitch stabilization by setting the '''PITCH_Mode''' to 1<br />
** PITCH_Mode = 0 --> estimator_thata from IMU (default)<br />
<br />
[[Category:Modules]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=NPS&diff=14106NPS2013-01-18T22:21:03Z<p>Ewoud: </p>
<hr />
<div>__TOC__<br />
<br />
NPS contains a sensors model and can use [http://jsbsim.sourceforge.net/ Jsbsim] as FDM (FlightDynamicModel) to allow fairly complex models.<br />
Other FDMs can be integrated easily.<br />
<br />
=== Installation ===<br />
<br />
See [[Installation|installation of Paparazzi]] and [[JSBSim]].<br />
<br />
==== Compilation ====<br />
<br />
* Compile paparazzi<br />
cd paparazzi<br />
make<br />
<br />
* Compile the vehicle<br />
make AIRCRAFT=Quad_LisaM_2 clean_ac nps<br />
<br />
===Start Simulation===<br />
* Start paparazzi_center if you want click to start programs<br />
./paparazzi<br />
<br />
* Start messages to monitor the middleware activity ( from the tool menu of paparazzi center) or with<br />
./sw/ground_segment/tmtc/messages <br />
<br />
* Start the sim<br />
./var/Quad_LisaM_2/nps/simsitl<br />
<br />
You should now see activity in the "messages" window<br />
<br />
* Plot the value of a message field.<br />
start 'plotter' (Real-time plotter from the tool menu of paparazzi center) or with<br />
./sw/logalizer/plotter<br />
for example drag the label 'int32 phi' from the ROTORCRAFT_FP message to the drawing area of the plotter<br />
<br />
<br />
* Use the datalink to change the tlemetry mode<br />
start 'settings' ( from the tool menu of paparazzi center) or with<br />
./sw/ground_segment/tmtc/settings -ac Quad_LisaM_2<br />
start 'server' to dispatch datalink messages ( from the tool menu of paparazzi center) or with<br />
./sw/ground_segment/tmtc/server <br />
change the field "telemetry" on the first page to "Att loop" and send by pressing the green check button. The label on the left or the drop box should change to "Att loop" confirming your essage has been received. "message" should now show that the message "STAB_ATTITUDE_INT" is received<br />
<br />
* Use flightgear to visualize your vehicle<br />
If you want a view of a quadrotor in flightgear, make a link from<br />
/usr/share/games/flightgear/Models/Aircraft/paparazzi to PAPARAZZI_SRC/conf/simulator/flightgear/ <br />
sudo ln -s $PAPARAZZI_SRC/conf/simulator/flightgear/ /usr/share/games/flightgear/Models/Aircraft/paparazzi<br />
start flighgear with<br />
fgfs --fdm=null --native-gui=socket,in,30,,5501,udp --prop:/sim/model/path=Models/Aircraft/paparazzi/mikrokopter.xml<br />
restart your simulator with<br />
./var/Quad_LisaM_2/nps/simsitl --fg_host 127.0.0.1<br />
<br />
* Save you session<br />
<br />
==== Troubleshooting ====<br />
* If you get an error like "JSBSim failed to open the configuration file: (null)/conf/simulator/jsbsim/aircraft/BOOZ2_A1.xml", you need to set your $PAPARAZZI_SRC and $PAPARAZZI_HOME environment variables. Add the following to your .bashrc, change paths according to where you put Paparazzi. Open a new terminal and launch the sim again.<br />
export PAPARAZZI_SRC=~/paparazzi<br />
export PAPARAZZI_HOME=~/paparazzi<br />
<br />
* If you did not install the jsbsim package your JSBSim installation under /opt/jsbsim will be used and you will have to set your library path (either in your shell startup file or when running the sim on the command line), e.g.:<br />
LD_LIBRARY_PATH=/opt/jsbsim/lib ./var/Quad_LisaM_2/nps/simsitl --fg_host 127.0.0.1<br />
<br />
=== Pausing or running the sim at a different speed ===<br />
You can pause the simulation with ''CTRL-z'' in the terminal. You can then enter a different time factor (default 1.0) to make the simulation run slower or faster than real-time. Hit enter to resume the simulation or ''CTRL-z'' again to suspend it like any normal Unix process (use the ''fg'' (foreground) command to un-suspend it again).<br />
<br />
=== Tuning the attitude control loop ===<br />
<br />
Here we are going to use the simulator to demonstrate a way of tuning the attitude control loop.<br />
<br />
* Restart your previous session<br />
<br />
* Set telemetry mode to "attitude_loop"<br />
<br />
* Display two real time plotter windows<br />
<br />
In the first one, plot the field "m_phi" from the "STAB_ATTITUDE_int" message. This is our estimation of roll angle.<br />
On top of that, plot the field "phi" from the "STAB_ATTITUDE_REF_INT" message. This is our reference roll angle, that is, the roll value we are trying to achieve.<br />
<br />
In the second plotter, plot the fields "delta_a_fb" and "delta_a_ff". Those are respectively the feedback and feedforward part of our roll command. The sum of those two terms is what is used as roll command.The feedforward part is the part used to follow our trajectory and the feedback part is the part used to reject perturbations.<br />
<br />
<br />
* In "Settings", go to the "Att Loop" tab<br />
We notice that the vehicle doesn't follow the step trajectory we are trying to make him do accurately.<br />
<br />
Start by setting the value of the proportional gain ('pgain_phi') to 1000 instead of 400. The vehicle now follows the trajectory faster but overshoots. To prevent that, increase the value of the derivative gain ('dgain p') from 300 to 700.<br />
<br />
If you look at the plotter where you're plotting the commands, you'll notice that during steps, the feedback command has to work hard. This means that our feedforward command is badly tuned, and namely not working hard enough. Increase the value of the feedforward gain ('ddgain p') from 300 to 540. You'll notice that now the feedback command has become marginal during the steps. This is the right value for the gain. Anything bigger will make the feedback command fight against the feedforward command during steps, anything smaller will make the feedback command have to complement the feedforward command.<br />
<br />
=== Something else ===<br />
<br />
* try starting flightgear with<br />
<br />
fgfs --fdm=null --native-gui=socket,in,30,,5501,udp --prop:/sim/model/path=Models/Aircraft/paparazzi/simple_bipe.xml<br />
<br />
an the sim with<br />
<br />
./var/Quad_LisaM_2/nps/simsitl --fg_host 127.0.0.1 --rc_script 1<br />
<br />
== Use a Joystick ==<br />
<br />
You can use a joystick (or connect your RC transmitter as a joystick) to control the quad in the simulator.<br />
<br />
<source lang="bash">./var/Quad_LisaM_2/nps/simsitl --fg_host 127.0.0.1 -j</source><br />
<br />
or, with a specific device index (0 is default):<br />
<br />
<source lang="bash">./var/Quad_LisaM_2/nps/simsitl --fg_host 127.0.0.1 --js_dev 0</source><br />
<br />
Joystick support uses the Simple DirectMedia Layer (SDL) library. Rather than specifying an input device name as one normally does on Linux, you just supply an index value (0, 1, 2,...) of the device you wish to use. Typically, the order of devices is the order in which you plugged them into your computer. The sim will display the name of the device being used to double check. If the <tt>-j</tt> option is used with no argument, the sim defaults to using device on index 0 (which is usually correct if you have only one joystick attached).<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Ewoudhttp://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=14099ImuCalibration2013-01-17T20:09:57Z<p>Ewoud: </p>
<hr />
<div>== Theory ==<br />
<br />
Accelerometer and Magnetometer calibration is critical to AHRS performance and can be performed using no special hardware. For the magnetometer, it is very important that the calibration be performed in the fully assembled vehicle, with all systems powered on. This is called hard-iron calibration and will allow us to compensate for any constant parasitic magnetic fields generated by the vehicle.<br />
The calibration process consists of finding a set of neutrals and scale factors for each sensor, such as <br />
<br />
<br />
<math><br />
\begin{pmatrix}physical\_value_x\\physical\_value_y\\physical\_value_z\end{pmatrix} = \begin{pmatrix}sf_x&0&0\\0&sf_y&0\\0&0&sf_z\end{pmatrix} * (\begin{pmatrix}sensor_x\\sensor_y\\sensor_z\end{pmatrix}-\begin{pmatrix}n_x\\n_y\\n_z\end{pmatrix})<br />
</math><br />
<br />
<br />
The principle of the calibration is the following: an accelerometer, on a vehicle at rest, measures a constant vector (the opposite of gravity) in the earth frame, expressed in the vehicle frame. <br />
<br />
<math><br />
DCM * \begin{pmatrix}0\\0\\-9.81\end{pmatrix} = <br />
\begin{pmatrix}sf_x&0&0\\0&sf_y&0\\0&0&sf_z\end{pmatrix} * (\begin{pmatrix}sensor_x\\sensor_y\\sensor_z\end{pmatrix}-\begin{pmatrix}n_x\\n_y\\n_z\end{pmatrix})<br />
</math><br />
<br />
<br />
DCM is a rotation matrix that converts between earth frame and body frame. It will change when we change the orientation of the vehicle. Nevertheless, a rotation conserves the norm of a vector. We can thus obtain the following scalar equation that doesn't depend on the vehicle orientation :<br />
<br />
<br />
<math><br />
9.81^2 = ( sf_x(sensor_x-n_x) )^2 + (sf_y(sensor_y-n_y) )^2 + (sf_z(sensor_z-n_z) )^2<br />
</math><br />
<br />
We can then record an important number of measurements in different orientations and find the set of scale factors and neutrals giving the norm closest to 9.81<br />
<br />
=== How It Works ===<br />
<br />
* It first makes an initial guess using min and max, i.e. for each axis<br />
** neutral = 0.5 * (max + min)<br />
** sensitivity = 0.5*(max-min)<br />
<br />
* It then uses a data fitting algorithm to optimize the initial guess.<br />
<br />
Screenshot of Scilab version.<br />
[[Image:calibAccel.png|240px]]<br />
<br />
== Calibration Script Installation==<br />
Vital scripts and places:<br />
# Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under: sw/tools/calibration/calibrate.py <br />
# Before you start calibrating clear log directory (PAPARAZZI_HOME/var/logs), it will greatly simplify log file search process.<br />
<br />
For the application to work, however, you need additional Python libraries. If you already have the package '''paparazzi-dev''' installed, the needed libraries were already installed as dependencies.<br />
If this is not the case you need to install '''python-scipy''' and '''python-matplotlib'''. This can be done via Synaptic Package Manager or via the command-line of Ubuntu.<br />
<br />
$ sudo apt-get install python-scipy<br />
$ sudo apt-get install python-matplotlib<br />
<br />
== How to Calibrate Your IMU ==<br />
Basic procedure:<br />
# Flash the board with your normal AP firmware (if it is not already on it.)<br />
# Switch to the "raw sensors" telemetry mode via ''[[GCS#Settings|GCS->Settings]]->Telemetry'' and launch "server" to record a [[Logs|log]].<br />
# Move your IMU/airframe into different positions to record relevant measurements for each axis.<br />
#* It is important that you get the min/max sensor values on each axis!<br />
# Stop the server so it will write the [[Logs|log file]] (to ''var/logs'').<br />
# Run the Python script on it to get your calibration coefficients and add them to your airframe file.<br />
#* If you have data from more than one aircraft in your logfile, you will need to specify the aircraft id via the ''--id'' option.<br/>It can be found in the [[Paparazzi_Center|Paparazzi Center]] upper left side. (first comes A/C name, and then id value)<br />
<br />
Run the script with the ''--help'' to list available options:<br />
''sw/tools/calibration/calibrate.py --help<br />
<br />
=== Calibrating the Accelerometers ===<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|The front of IMU is marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.<br />
Image:Acc_cailbration.jpg|Orientations during accelerometer calibration<br />
</gallery></div><br />
<br />
Since accelerometers are very sensitive to distortions, strapping board to some heavy object like big LiPO battery. It will help keep the board steady while rotating.<br />
<br />
To calibrate the accelerometers turn and hold (~10 sec/side) the IMU on all six sides of the cube:<br />
# upright,<br />
# inverted,<br />
# on the nose,<br />
# on the tail,<br />
# on the right side,<br />
# on the left side.<br />
<br />
Please note that the IMU axes matter here, and NOT the airframe axes.<br>So if you have your IMU mounted at an angle, make sure you align the IMU and not the aircraft axes with gravity. Also for the accelerometer calibration the IMU doesn't need to be mounted in the airframe (opposed to the magnetometer calibration).<br />
<br />
You can also take some measurements banking 45 degrees.<br>Try to get a homogeneous distribution of your measurements. It is better to let the aircraft rest while measuring.<br />
<br />
Then stop the server so it will write the log file (containing the needed '''IMU_ACCEL_RAW''' messages) and run the Python script on it to get your calibration coefficients: <br />
<br />
''<nowiki>sw/tools/calibration/calibrate.py -s ACCEL var/logs/YY_MM_DD__hh_mm_ss.data</nowiki>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
First of all it is important to know that all ferromagnetic materials near the mag disort the measurements. So preferably you do the mag calibration with the mag/autopilot mounted in your frame and as far away from metal and magnets as possible.<br />
<br />
==== Calibrating for the Earth magnetic field ====<br />
The most crucial part for the magnetometer calibration: Ideally you would spin it around all axes until you have densely covered the whole sphere with measurements.<br>Since that is often a bit hard to do with the whole airframe you can also just make sure to really get the min/max on each axis by aligning the magnetometer axes along the local magnetic field vector:<br />
# Calculate the inclination and declination of the magnetic field where you live that can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here]. Just put in zip/country+city/coordinates & date to get proper degrees. See MAG1 figure.<br />
# Now point the each mag axis in the direction you got from previous step.<br />
<br />
It can also be convenient to [[RTPlotter|plot]] the ''IMU_MAG_RAW'' values to see when you get the maximum on each axis.<br />
# Launch [[Paparazzi_Center|Paparazzi Center]]->Tools->Realtime_Plotter and Tools->Messages<br />
# Drag&Drop each axis of the ''IMU_MAG_RAW'' message to the Plotter canvas.<br />
<br />
<br />
After you took all measurements, stop the server so it will write the log file and run the Python script on it to get your calibration coefficients:<br />
''<nowiki>sw/tools/calibration/calibrate.py -s MAG var/logs/YY_MM_DD__hh_mm_ss.data</nowiki>''<br />
<br />
This basically does a hard-iron (offset of the sphere) and soft-iron (distortion to an ellipsoid) calibration. You can see the results in Figure MAG2.<br />
<gallery widths=200px heigths=200px><br />
Image:Mag_london_inc-dec.jpg|fig. MAG1 - An example for London<br />
Image:Mag_fit_3d.png|fig. MAG2 - Measurements fitted to ellipsoid<br />
</gallery><br />
<br />
The magnetic field changes depending on where you are in the world, because of this you have to [[Subsystem/ahrs#Local_Magnetic_Field|set the local magnetic field]]. Or if you are using the [[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|older euler filter]] recalibrate your magnetometer to fly somewhere else.<br />
<br />
==== Calibrating for Current ====<br />
When flying, currents running through the wires induce a magnetic field. This can create an offset in the measurement of the magnetic north, for which can be calibrated. Note that this interference can also be reduced by putting the magnetometer somewhere away from power wires and by twisting power wires together.<br />
<br />
Before doing this calibration, it is important to disengage any control by switching to autopilot mode AP_MODE_RC_DIRECT.<br />
<br />
# Set up a current sensor in Paparazzi, or define MILLIAMP_AT_FULL_THROTTLE in your airframe file to enable a current estimation. <br />
# Put the UAV on the ground and hold it steady.<br />
# Switch to telemetry message "mag_current_calibration".<br />
# Slowly ramp up the throttle.<br />
# Stop the server so it will write the log file and run the python script by entering:<br />
<br />
''<nowiki>sw/tools/calibration/calibrate_mag_current.py var/logs/YY_MM_DD__hh_mm_ss.data</nowiki>'' <br />
<br />
Note that a change in you airframe configuration or the wiring will require a new calibration. You can check if the calibration worked by watching the psi angle as you ramp up the motors while holding the UAV steady. Be sure to do this without the control system active.<br />
<br />
=== Calibrating the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<br><br />
The gyro neutrals (bias) are usually not a problem, since they are set by the AHRS aligner at each startup and some [[Subsystem/ahrs|AHRS algorithms]] continuously estimate the bias during flight.<br />
<br />
== Finding and Checking Signs ==<br />
<br />
'''For [[Subsystem/imu|supported IMUs]], the correct default signs are already defined in the code.'''<br />
<br />
If using a new IMU or sign for yours are not in the code yet, here is the way to find them.<br />
<br />
We're calibrating everything relative to the IMU frame - Paparazzi has a parameter to define the orientation of the IMU with respect to the body of the vehicle that we'll use later, once you'll have decided of a good mechanical mounting.<br />
<br />
Paparazzi uses North East Down (NED) frame, that is positive x is pointing to the front, positive y to the right and positive z down.<br />
<br />
===Accelerometer:===<br />
An accelerometer measures the non gravitational acceleration, that is <math>\ddot{x} - g</math>. <math>g</math> is pointing down, so <math>-g</math> is pointing up. So stop moving, disregard earth rotation and you'll measure <math>-g</math>.<br />
<br />
*When your IMU is level you should see x=0 y=0 z=-9.81<br />
*When pitching up -g is aligning with x, so you should see x>0, y=0 and z<0<br />
*When banking left -g is aligning with y, so you should see x=0, y>0 and z<0<br />
<br />
===Magnetometer:===<br />
A magnetometer measures the Earth's magnetic field. In the northern hemisphere, this points north and down and in the Southern hemisphere north and up.<br />
<br />
Thus in the northern hemisphere:<br />
*When you align your IMU with the direction of north, you should see x>0, y=0, z>0.<br />
*When pitching the IMU down, the magnetic vector is aligning with x, so x should increase and z should decrease to zero.<br />
*If yawing your IMU to the left, the magnetic vector is aligning with y, so y should be positive, x should decrease to zero and z stay positive.<br />
<br />
And in the southern hemisphere:<br />
*When you align your IMU with the direction of north, you should see x>0, y=0, z<0<br />
*When pitching the IMU up, the magnetic vector is aligning with x, so x should increase and z should increase towards zero.<br />
*If yawing your IMU to the left, the magnetic vector is aligning with y, so y should be positive, x should decrease to zero and z stay negative.<br />
<br />
===Gyrometer:===<br />
You need some turntable to calibrate the scale factors of your gyros. For signs, the definition of the frame gives the following properties:<br />
<br />
*When rolling right, <math>p</math> should be positive.<br />
*When pitching up, <math>q</math> should be positive.<br />
*When yawing to the right, <math>r</math> should be positive.<br />
<br />
===Verification:===<br />
Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
*Bank right should give positive phi <br />
*Pitch up should give positive theta<br />
*Yaw right should give increasing psi<br />
<br />
*The value you'll see after letting the IMU rest will end up being the "measure" (that is accelerometer and magnetometer.) If those are wrong, the problem is in the calibration of your sensors.<br />
*The values you get while moving the IMU are influenced by the gyros. If what you see is the value going crazy when you move and then stabilizing to something good after you stop moving, the problem is in your gyros.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Ewoud