http://wiki.paparazziuav.org/w/api.php?action=feedcontributions&user=P0rc0+r0ss0&feedformat=atomPaparazziUAV - User contributions [en]2024-03-29T12:35:53ZUser contributionsMediaWiki 1.37.1http://wiki.paparazziuav.org/w/index.php?title=Installation/Linux/udev&diff=12719Installation/Linux/udev2012-06-16T20:36:37Z<p>P0rc0 r0ss0: </p>
<hr />
<div>This page describes common paparazzi port naming convention.<br />
<br />
= Paparazzi device list =<br />
/dev/paparazzi/xbee - interface that is used for telemetry connections. (transperent, airborne)<br />
/dev/paparazzi/jtag - interface used for jtag debugging.<br />
/dev/paparazzi/sereial - interface that is used for local board connections.<br />
<br />
.wine/dosdevices/com4 - interface for X-CTU (see [[Modems/xbee | xbee configuration page]]).<br />
<br />
To have you linux making automatic symlinks to right devices, your [[udev]] file should look like:<br />
ACTION!="add|change", GOTO="paparazzi_rules_end"<br />
<br />
# other bare FT232R FTDI chip without EEPROM<br />
SUBSYSTEM=="tty", ATTRS{product}=="FT232R USB UART", SYMLINK+="paparazzi/serial", GROUP="plugdev"<br />
<br />
# MaxStream xbee pro box<br />
SUBSYSTEM=="tty", ATTRS{product}=="MaxStream PKG-U", SYMLINK+="paparazzi/xbee", GROUP="plugdev"<br />
<br />
# MaxStream FLOSS JTAG<br />
ATTRS{interface}=="FLOSS-JTAG", ATTRS{bInterfaceNumber}=="00", SYMLINK+="paparazzi/jtag", GROUP="plugdev"<br />
ATTRS{interface}=="FLOSS-JTAG", ATTRS{bInterfaceNumber}=="01", SYMLINK+="paparazzi/serial", GROUP="plugdev"<br />
<br />
LABEL="tty_FTDI232_end"<br />
<br />
SUBSYSTEM!="usb", GOTO="paparazzi_rules_end"<br />
ENV{DEVTYPE}!="usb_device", GOTO="paparazzi_rules_end"<br />
<br />
ATTR{manufacturer}=="Transition Robotics Inc.", ATTR{product}=="Lisa/M (Upgrade)*", GROUP="plugdev"<br />
<br />
#SUBSYSTEMS=="usb", ATTRS{serial}=="*_fbw", NAME="test_fbw", SYMLINK+="paparazzi/%s{serial}", MODE="0666"<br />
<br />
# FTDI 2232 parallel converter / Amontec JTAG-Tiny (access through libftdi)<br />
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="cff8", GROUP="plugdev"<br />
<br />
# FTDI 2232 based jtag for Lisa/L and usb upload<br />
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666", GROUP="plugdev"<br />
<br />
# all (fake VID 0x7070) LPCUSB devices (access through libusb)<br />
ATTRS{idVendor}=="7070", GROUP="plugdev"<br />
<br />
# make joysticks/gamepads readable on event interface (writeable for force feedback), see input_event.sh<br />
KERNEL=="event*", IMPORT{program}="input_event.sh %p", NAME="input/%k", GROUP="plugdev", MODE="0640" ENV{FF_DEVICE}=="1", MODE="0660"<br />
<br />
# FTDI with uBlox direct on USB<br />
ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a5", KERNEL=="ttyACM*", SYMLINK+="paparazzi/acm", GROUP="plugdev"<br />
<br />
LABEL="paparazzi_rules_end"</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Modems/xbee&diff=12711Modems/xbee2012-06-14T16:58:51Z<p>P0rc0 r0ss0: /* Installation of X-CTU */</p>
<hr />
<div>Paparazzi supports the following modem protocols:<br />
* Standard transparent serial (pprz protocol, AT mode) - compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.<br />
* Digi (formerly Maxstream) API protocol (xbee) - compatible with all Digi modems including the 9XTend and Zigbee. This protocol enables hardware addressing through API mode, allowing multiple aircraft to be managed from a single ground modem.<br />
<br/><br />
<br />
== Introduction ==<br />
<br />
=== Installation of X-CTU ===<br />
The simples way to configure the XBee modems is to use the [http://www.digi.com/support/productdetail?pid=3352 X-CTU] software from Digi. It runs under Windows or under Wine.<br />
<br />
Under Wine make sure you have the USB serial link connecting to XBee mapped to a com port (please consult [[Installation/Linux/udev | paparazzi linux device naming]]):<br />
<br />
* First of all you should install wine.<br />
* Then install winetricks (X-CTU requires MS Visual C++ Redistributable package so winetricks will make things much easier to get installed).<br />
* Then ('''!important''') run wine configuration before doing something else, so wine can create ~/.wine<br />
* Make symlink to your modem device.<br />
<br />
$ sudo ln -s /dev/paparazzi/xbee ~/.wine/dosdevices/com4<br />
<br />
* Set permissions for COM port (if you are not root):<br />
<br />
$ sudo ls -l /dev/paparazzi/xbee<br />
lrwxrwxrwx 1 root root 10 june 14 19:00 /dev/paparazzi/xbee -> /dev/ttyUSB0<br />
$ sudo chown <your_user_name_here> /dev/ttyUSB0<br />
<br />
* Run X-CTU setup and install it.<br />
* Then run installed application. When window opens switch to "User Com Ports" tab and add com port "COM4. Note: This procedure have to be made every time you start X-CTU on Linux.<br />
* Click "Test/Query" button. If you get some modem information (like serial, etc.) after a little time, then you have modem link established.<br />
<br />
If X-CTU complains on com port connectivity, try adding theese strings to ~/.wine/system.reg<br />
[hardware\\DEVICEMAP\\SERIALCOMM]<br />
"COM1"="COM1"<br />
<br />
If your X-CTU does not update its firmware correctely from the web, follow the steps described in the chapter "Manually Update the X-CTU firmware files" of [http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux this page].<br />
<br />
=== Configuring XBee AT mode using X-CTU ===<br />
This is the recommended way to start. With this firmware the modems basically act as a serial link replacement and don't do any mesh networking. The pprz protocol is based on this mode.<br />
<br/><br />
Basic approach:<br />
# Connect your XBee to your PC. There are several vendors of [[Modems#GCS_Adaptation|USB boards]].<br />
# Start the X-CTU programm and go to the modem configuration.<br />
# Click on READ<br />
# Select the appropriate function set with AT command set.<br />
# set PAN ID, etc... depending on which XBee you use<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly. At a higher baudrate setting, transmission can only be done in one direction.<br />
# Then write the firmware to the module.<br />
If X-CTU asks you to reset the XBee, you have to connect the RST pin (5) to the GND pin (10) of the XBee. You can do this manually using tweezers or a short wire.<br />
<br />
=== Configuring XBee using minicom ===<br />
<br />
Alternatively you can use the text-based modem control and terminal emulation program [http://en.wikipedia.org/wiki/Minicom minicom] instead of X-CTU to configure your XBee:<br />
<br />
# Connect XBee to your computer<br />
# Setup minicom (by default XBee modems come set up for 9600 baud)<br />
# Type Ctrl-A A in minicom this will set it up to add linefeeds to the stream<br />
# Type three '+' in quick succession resulting in "+++" string (you have 10s to type your next command otherwise the modem will revert back to transparent mode)<br />
#* you get a confirmation: 'OK'<br />
# Type "AT<enter>"<br />
#* you get a confirmation: 'OK'<br />
# Type "ATBD<enter>"<br />
#* you get the baudrate code: '3'<br />
# To set another baudrate select one of the following by typing "ATBD <baud code><enter>"<br />
#* 0 = 1200<br />
#* 1 = 2400<br />
#* 2 = 4800<br />
#* 3 = 9600<br />
#* 4 = 19200to connect the ground XBee radio modem to the GCS computer<br />
#* 5 = 38400<br />
#* 6 = 57600<br />
#* 7 = 115200<br />
# To store the new baudrate in the rom type "ATWR<enter>"<br />
# Now you can close minicom<br />
# Reconnect modem<br />
# Restart minicom with the new baudrate<br />
# Test that the modem is setup correctly by tiping "+++" and getting "OK" confirmation<br />
<br />
== XBee Pro ZB (AT command set) ==<br />
This 2.4GHz modem uses ZigBee PRO Feature Set and is compatible with devices from other vendors using the ZigBee PRO Feature Set.<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE COORDINATOR AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Pairing your Modems ===<br />
<br />
For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station.<br />
<br />
=== Reviving a non-responding Xbee Pro ===<br />
<br />
To bring an apparently dead XBee Pro Series 2 back to life, do the following:<br />
<br />
#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).<br />
#Open X-CTU.<br />
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).<br />
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.<br />
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.<br />
#Before you click OK to the dialog box, plug in the XBee module (carefully).<br />
#Click OK to clear the message and it should start programming automatically.<br />
<br />
=== Other tutorials ===<br />
<br />
[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]<br />
<br />
[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]<br />
<br />
== XBee Pro ZNet 2.5 (AT command set) ==<br />
These are legacy modems and not recommended/sold by Digi anymore.<br />
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.<br />
<br/><br />
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.<br />
# Set the Destination Address Low (DL) to FFFF.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Setup ===<br />
<br />
For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.<br />
* Flash one module (ground station) with the coordinator AT firmware<br />
* Flash aircraft module with router or end-device AT firmware<br />
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.<br />
<br />
If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:<br />
* Set PAN ID to some unique (but same) ID on both modules<br />
* Set a Node Identifier for each module (e.g. ground, aircraft)<br />
<br/><br />
<br />
== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# '''Set Coordinator Enable to "1 - COORDINATOR".'''<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
(Tested on XBP24 Firmwareversion 10E6)<br />
<br />
== XBee Pro 868 MHZ ==<br />
<br />
=== Getting Them Working ===<br />
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.<br />
<br />
I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.<br />
<br />
#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 &lt;baud rate, just a number, no angled brackets&gt;</code>, you can also use pico- or microcom)<br />
#Type AT and enter. You should get an OK back.<br />
#ATMT and enter. You should get a number&mdash;this represents the number of extra times each packet will be broadcast. We now need to change this to zero.<br />
#ATMT0 and enter => OK<br />
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.<br />
#ATRR0 and enter => OK<br />
#Type ATWR to store the new stuff in the firmware. You should get an OK.<br />
#Set the datalink to transparent mode both in your airframe file and on the datalink.<br />
<br />
You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though. <br />
<br />
You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.<br />
<br />
== XBee Pro XSC (900MHZ) ==<br />
<br />
== Configuring XBee API mode (xbee protocol) ==<br />
<br />
[[Category:Hardware]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Modems/xbee&diff=12710Modems/xbee2012-06-14T16:54:34Z<p>P0rc0 r0ss0: /* Installation of X-CTU */</p>
<hr />
<div>Paparazzi supports the following modem protocols:<br />
* Standard transparent serial (pprz protocol, AT mode) - compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.<br />
* Digi (formerly Maxstream) API protocol (xbee) - compatible with all Digi modems including the 9XTend and Zigbee. This protocol enables hardware addressing through API mode, allowing multiple aircraft to be managed from a single ground modem.<br />
<br/><br />
<br />
== Introduction ==<br />
<br />
=== Installation of X-CTU ===<br />
The simples way to configure the XBee modems is to use the [http://www.digi.com/support/productdetail?pid=3352 X-CTU] software from Digi. It runs under Windows or under Wine.<br />
<br />
Under Wine make sure you have the USB serial link connecting to XBee mapped to a com port (please consult [[Installation/Linux/udev | paparazzi linux device naming]]):<br />
<br />
* First of all you should install wine.<br />
* Then install winetricks (X-CTU requires MS Visual C++ Redistributable package so winetricks will make things much easier to get installed).<br />
* Then ('''!important''') run wine configuration before doing something else, so wine can create ~/.wine<br />
* Make symlink to your modem device.<br />
<br />
$ sudo ln -s /dev/paparazzi/xbee ~/.wine/dosdevices/com4<br />
<br />
* Set permissions for COM port (if you are not root):<br />
<br />
$ sudo ls -l /dev/paparazzi/xbee<br />
lrwxrwxrwx 1 root root 10 june 14 19:00 /dev/paparazzi/xbee -> /dev/ttyUSB0<br />
$ sudo chown <your_user_name_here> /dev/ttyUSB0<br />
<br />
* Run X-CTU setup and install it.<br />
* Then run installed application. When window opens switch to "User Com Ports" tab and add com port "COM4. Note: This procedure have to be made every time you start X-CTU on Linux.<br />
* Click "Test/Query" button. If you get some modem information (like serial, etc.) after a little time, then you have modem link established.<br />
<br />
If your X-CTU does not update its firmware correctely from the web, follow the steps described in the chapter "Manually Update the X-CTU firmware files" of [http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux this page].<br />
<br />
=== Configuring XBee AT mode using X-CTU ===<br />
This is the recommended way to start. With this firmware the modems basically act as a serial link replacement and don't do any mesh networking. The pprz protocol is based on this mode.<br />
<br/><br />
Basic approach:<br />
# Connect your XBee to your PC. There are several vendors of [[Modems#GCS_Adaptation|USB boards]].<br />
# Start the X-CTU programm and go to the modem configuration.<br />
# Click on READ<br />
# Select the appropriate function set with AT command set.<br />
# set PAN ID, etc... depending on which XBee you use<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly. At a higher baudrate setting, transmission can only be done in one direction.<br />
# Then write the firmware to the module.<br />
If X-CTU asks you to reset the XBee, you have to connect the RST pin (5) to the GND pin (10) of the XBee. You can do this manually using tweezers or a short wire.<br />
<br />
=== Configuring XBee using minicom ===<br />
<br />
Alternatively you can use the text-based modem control and terminal emulation program [http://en.wikipedia.org/wiki/Minicom minicom] instead of X-CTU to configure your XBee:<br />
<br />
# Connect XBee to your computer<br />
# Setup minicom (by default XBee modems come set up for 9600 baud)<br />
# Type Ctrl-A A in minicom this will set it up to add linefeeds to the stream<br />
# Type three '+' in quick succession resulting in "+++" string (you have 10s to type your next command otherwise the modem will revert back to transparent mode)<br />
#* you get a confirmation: 'OK'<br />
# Type "AT<enter>"<br />
#* you get a confirmation: 'OK'<br />
# Type "ATBD<enter>"<br />
#* you get the baudrate code: '3'<br />
# To set another baudrate select one of the following by typing "ATBD <baud code><enter>"<br />
#* 0 = 1200<br />
#* 1 = 2400<br />
#* 2 = 4800<br />
#* 3 = 9600<br />
#* 4 = 19200to connect the ground XBee radio modem to the GCS computer<br />
#* 5 = 38400<br />
#* 6 = 57600<br />
#* 7 = 115200<br />
# To store the new baudrate in the rom type "ATWR<enter>"<br />
# Now you can close minicom<br />
# Reconnect modem<br />
# Restart minicom with the new baudrate<br />
# Test that the modem is setup correctly by tiping "+++" and getting "OK" confirmation<br />
<br />
== XBee Pro ZB (AT command set) ==<br />
This 2.4GHz modem uses ZigBee PRO Feature Set and is compatible with devices from other vendors using the ZigBee PRO Feature Set.<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE COORDINATOR AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Pairing your Modems ===<br />
<br />
For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station.<br />
<br />
=== Reviving a non-responding Xbee Pro ===<br />
<br />
To bring an apparently dead XBee Pro Series 2 back to life, do the following:<br />
<br />
#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).<br />
#Open X-CTU.<br />
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).<br />
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.<br />
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.<br />
#Before you click OK to the dialog box, plug in the XBee module (carefully).<br />
#Click OK to clear the message and it should start programming automatically.<br />
<br />
=== Other tutorials ===<br />
<br />
[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]<br />
<br />
[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]<br />
<br />
== XBee Pro ZNet 2.5 (AT command set) ==<br />
These are legacy modems and not recommended/sold by Digi anymore.<br />
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.<br />
<br/><br />
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.<br />
# Set the Destination Address Low (DL) to FFFF.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Setup ===<br />
<br />
For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.<br />
* Flash one module (ground station) with the coordinator AT firmware<br />
* Flash aircraft module with router or end-device AT firmware<br />
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.<br />
<br />
If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:<br />
* Set PAN ID to some unique (but same) ID on both modules<br />
* Set a Node Identifier for each module (e.g. ground, aircraft)<br />
<br/><br />
<br />
== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# '''Set Coordinator Enable to "1 - COORDINATOR".'''<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
(Tested on XBP24 Firmwareversion 10E6)<br />
<br />
== XBee Pro 868 MHZ ==<br />
<br />
=== Getting Them Working ===<br />
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.<br />
<br />
I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.<br />
<br />
#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 &lt;baud rate, just a number, no angled brackets&gt;</code>, you can also use pico- or microcom)<br />
#Type AT and enter. You should get an OK back.<br />
#ATMT and enter. You should get a number&mdash;this represents the number of extra times each packet will be broadcast. We now need to change this to zero.<br />
#ATMT0 and enter => OK<br />
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.<br />
#ATRR0 and enter => OK<br />
#Type ATWR to store the new stuff in the firmware. You should get an OK.<br />
#Set the datalink to transparent mode both in your airframe file and on the datalink.<br />
<br />
You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though. <br />
<br />
You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.<br />
<br />
== XBee Pro XSC (900MHZ) ==<br />
<br />
== Configuring XBee API mode (xbee protocol) ==<br />
<br />
[[Category:Hardware]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Installation/Linux/udev&diff=12709Installation/Linux/udev2012-06-14T16:17:22Z<p>P0rc0 r0ss0: </p>
<hr />
<div>This page describes common paparazzi port device convention.<br />
<br />
= Paparazzi device list =<br />
/dev/paparazzi/xbee - interface that is used for telemetry connections. (transperent, airborne)<br />
/dev/paparazzi/jtag - interface used for jtag debugging.<br />
/dev/paparazzi/sereial - interface that is used for local board connections.<br />
<br />
.wine/dosdevices/com4 - interface for X-CTU (see [[Modems/xbee | xbee configuration page]]).<br />
<br />
To have you linux making automatic symlinks to right devices, your [[udev]] file should look like:<br />
ACTION!="add|change", GOTO="paparazzi_rules_end"<br />
<br />
# other bare FT232R FTDI chip without EEPROM<br />
SUBSYSTEM=="tty", ATTRS{product}=="FT232R USB UART", SYMLINK+="paparazzi/serial", GROUP="plugdev"<br />
<br />
# MaxStream xbee pro box<br />
SUBSYSTEM=="tty", ATTRS{product}=="MaxStream PKG-U", SYMLINK+="paparazzi/xbee", GROUP="plugdev"<br />
<br />
# MaxStream FLOSS JTAG<br />
ATTRS{interface}=="FLOSS-JTAG", ATTRS{bInterfaceNumber}=="00", SYMLINK+="paparazzi/jtag", GROUP="plugdev"<br />
ATTRS{interface}=="FLOSS-JTAG", ATTRS{bInterfaceNumber}=="01", SYMLINK+="paparazzi/serial", GROUP="plugdev"<br />
<br />
LABEL="tty_FTDI232_end"<br />
<br />
SUBSYSTEM!="usb", GOTO="paparazzi_rules_end"<br />
ENV{DEVTYPE}!="usb_device", GOTO="paparazzi_rules_end"<br />
<br />
ATTR{manufacturer}=="Transition Robotics Inc.", ATTR{product}=="Lisa/M (Upgrade)*", GROUP="plugdev"<br />
<br />
#SUBSYSTEMS=="usb", ATTRS{serial}=="*_fbw", NAME="test_fbw", SYMLINK+="paparazzi/%s{serial}", MODE="0666"<br />
<br />
# FTDI 2232 parallel converter / Amontec JTAG-Tiny (access through libftdi)<br />
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="cff8", GROUP="plugdev"<br />
<br />
# FTDI 2232 based jtag for Lisa/L and usb upload<br />
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666", GROUP="plugdev"<br />
<br />
# all (fake VID 0x7070) LPCUSB devices (access through libusb)<br />
ATTRS{idVendor}=="7070", GROUP="plugdev"<br />
<br />
# make joysticks/gamepads readable on event interface (writeable for force feedback), see input_event.sh<br />
KERNEL=="event*", IMPORT{program}="input_event.sh %p", NAME="input/%k", GROUP="plugdev", MODE="0640" ENV{FF_DEVICE}=="1", MODE="0660"<br />
<br />
# FTDI with uBlox direct on USB<br />
ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a5", KERNEL=="ttyACM*", SYMLINK+="paparazzi/acm", GROUP="plugdev"<br />
<br />
LABEL="paparazzi_rules_end"</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Installation/Linux/udev&diff=12708Installation/Linux/udev2012-06-14T16:12:36Z<p>P0rc0 r0ss0: </p>
<hr />
<div>This page describes common paparazzi port device convention.<br />
<br />
= Paparazzi device list =<br />
/dev/paparazzi/xbee - interface that is used for telemetry connections. (transperent, airborne)<br />
/dev/paparazzi/jtag - interface used for jtag debugging.<br />
/dev/paparazzi/sereial - interface that is used for local board connections.<br />
<br />
.wine/dosdevices/com4 - interface for X-CTU (see [[Modems/xbee | xbee configuration page]]).<br />
<br />
To have you linux making automatic symlinks to right devices, your [[udev]] file should look like:</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Udev&diff=12707Udev2012-06-14T16:11:58Z<p>P0rc0 r0ss0: </p>
<hr />
<div>Also see [http://www.openuas.org/pub/writing_udev_rules.html writing udev rules].<br />
<br />
Please see [[Installation/Linux/udev | paparazzi naming description]] for understanding why do we need udev rules.<br />
<br />
You can get the serial number of your FTDI usb/serial converter<br />
connected to your xbee via<br />
udevadm info --query=all --attribute-walk --name=/dev/ttyUSB0<br />
and looking for the lines<br />
ATTRS{manufacturer}=="FTDI"<br />
ATTRS{product}=="FT232R USB UART"<br />
ATTRS{serial}=="A80081ej"<br />
where the last one would be your serial you need to write into the rules file, e.g.<br />
# your own XBee ground modem with FTDI USB adapter (adapt serial number)<br />
SUBSYSTEM=="tty", ATTRS{product}=="FT232R USB UART", ATTRS{serial}=="A80081ej", SYMLINK+="paparazzi/xbee", GOTO="tty_FTDI232_end"<br />
<br />
<br />
To see what udev rules would match (It may show incorrect results, because<br />
some values may be different, or not available at a simulation run.)<br />
udevadm test --action=add $(udevadm info --query=path --name /dev/ttyUSB0)<br />
<br />
To actually retrigger without having to re-plug it:<br />
sudo udevadm trigger<br />
<br />
== example udev rule for the floss-jtag serial ==<br />
SUBSYSTEM=="tty", ATTRS{interface}=="FLOSS-JTAG", ATTRS{bInterfaceNumber}=="01", SYMLINK+="jtag-serial"</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Modems/xbee&diff=12706Modems/xbee2012-06-14T16:07:45Z<p>P0rc0 r0ss0: /* Installation of X-CTU */</p>
<hr />
<div>Paparazzi supports the following modem protocols:<br />
* Standard transparent serial (pprz protocol, AT mode) - compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.<br />
* Digi (formerly Maxstream) API protocol (xbee) - compatible with all Digi modems including the 9XTend and Zigbee. This protocol enables hardware addressing through API mode, allowing multiple aircraft to be managed from a single ground modem.<br />
<br/><br />
<br />
== Introduction ==<br />
<br />
=== Installation of X-CTU ===<br />
The simples way to configure the XBee modems is to use the [http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=125 X-CTU] software from Digi. It runs under Windows or under Wine.<br />
<br />
Under Wine make sure you have the USB serial link connecting to XBee mapped to a com port (please consult [[Installation/Linux/udev | paparazzi linux device naming]]):<br />
<br />
sudo ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com4<br />
<br />
If your X-CTU does not update its firmware correctely from the web, follow the steps described in the chapter "Manually Update the X-CTU firmware files" of [http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux this page].<br />
<br />
=== Configuring XBee AT mode using X-CTU ===<br />
This is the recommended way to start. With this firmware the modems basically act as a serial link replacement and don't do any mesh networking. The pprz protocol is based on this mode.<br />
<br/><br />
Basic approach:<br />
# Connect your XBee to your PC. There are several vendors of [[Modems#GCS_Adaptation|USB boards]].<br />
# Start the X-CTU programm and go to the modem configuration.<br />
# Click on READ<br />
# Select the appropriate function set with AT command set.<br />
# set PAN ID, etc... depending on which XBee you use<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly. At a higher baudrate setting, transmission can only be done in one direction.<br />
# Then write the firmware to the module.<br />
If X-CTU asks you to reset the XBee, you have to connect the RST pin (5) to the GND pin (10) of the XBee. You can do this manually using tweezers or a short wire.<br />
<br />
=== Configuring XBee using minicom ===<br />
<br />
Alternatively you can use the text-based modem control and terminal emulation program [http://en.wikipedia.org/wiki/Minicom minicom] instead of X-CTU to configure your XBee:<br />
<br />
# Connect XBee to your computer<br />
# Setup minicom (by default XBee modems come set up for 9600 baud)<br />
# Type Ctrl-A A in minicom this will set it up to add linefeeds to the stream<br />
# Type three '+' in quick succession resulting in "+++" string (you have 10s to type your next command otherwise the modem will revert back to transparent mode)<br />
#* you get a confirmation: 'OK'<br />
# Type "AT<enter>"<br />
#* you get a confirmation: 'OK'<br />
# Type "ATBD<enter>"<br />
#* you get the baudrate code: '3'<br />
# To set another baudrate select one of the following by typing "ATBD <baud code><enter>"<br />
#* 0 = 1200<br />
#* 1 = 2400<br />
#* 2 = 4800<br />
#* 3 = 9600<br />
#* 4 = 19200to connect the ground XBee radio modem to the GCS computer<br />
#* 5 = 38400<br />
#* 6 = 57600<br />
#* 7 = 115200<br />
# To store the new baudrate in the rom type "ATWR<enter>"<br />
# Now you can close minicom<br />
# Reconnect modem<br />
# Restart minicom with the new baudrate<br />
# Test that the modem is setup correctly by tiping "+++" and getting "OK" confirmation<br />
<br />
== XBee Pro ZB (AT command set) ==<br />
This 2.4GHz modem uses ZigBee PRO Feature Set and is compatible with devices from other vendors using the ZigBee PRO Feature Set.<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE COORDINATOR AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Pairing your Modems ===<br />
<br />
For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station.<br />
<br />
=== Reviving a non-responding Xbee Pro ===<br />
<br />
To bring an apparently dead XBee Pro Series 2 back to life, do the following:<br />
<br />
#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).<br />
#Open X-CTU.<br />
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).<br />
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.<br />
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.<br />
#Before you click OK to the dialog box, plug in the XBee module (carefully).<br />
#Click OK to clear the message and it should start programming automatically.<br />
<br />
=== Other tutorials ===<br />
<br />
[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]<br />
<br />
[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]<br />
<br />
== XBee Pro ZNet 2.5 (AT command set) ==<br />
These are legacy modems and not recommended/sold by Digi anymore.<br />
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.<br />
<br/><br />
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.<br />
# Set the Destination Address Low (DL) to FFFF.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Setup ===<br />
<br />
For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.<br />
* Flash one module (ground station) with the coordinator AT firmware<br />
* Flash aircraft module with router or end-device AT firmware<br />
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.<br />
<br />
If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:<br />
* Set PAN ID to some unique (but same) ID on both modules<br />
* Set a Node Identifier for each module (e.g. ground, aircraft)<br />
<br/><br />
<br />
== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# '''Set Coordinator Enable to "1 - COORDINATOR".'''<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
(Tested on XBP24 Firmwareversion 10E6)<br />
<br />
== XBee Pro 868 MHZ ==<br />
<br />
=== Getting Them Working ===<br />
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.<br />
<br />
I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.<br />
<br />
#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 &lt;baud rate, just a number, no angled brackets&gt;</code>, you can also use pico- or microcom)<br />
#Type AT and enter. You should get an OK back.<br />
#ATMT and enter. You should get a number&mdash;this represents the number of extra times each packet will be broadcast. We now need to change this to zero.<br />
#ATMT0 and enter => OK<br />
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.<br />
#ATRR0 and enter => OK<br />
#Type ATWR to store the new stuff in the firmware. You should get an OK.<br />
#Set the datalink to transparent mode both in your airframe file and on the datalink.<br />
<br />
You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though. <br />
<br />
You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.<br />
<br />
== XBee Pro XSC (900MHZ) ==<br />
<br />
== Configuring XBee API mode (xbee protocol) ==<br />
<br />
[[Category:Hardware]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Installation/Linux/udev&diff=12705Installation/Linux/udev2012-06-14T16:07:30Z<p>P0rc0 r0ss0: Created page with "This page describes common paparazzi port device convention. = Paparazzi device list = /dev/paparazzi/xbee - interface that is used for telemetry connections. (transperent, airb…"</p>
<hr />
<div>This page describes common paparazzi port device convention.<br />
<br />
= Paparazzi device list =<br />
/dev/paparazzi/xbee - interface that is used for telemetry connections. (transperent, airborne)<br />
/dev/paparazzi/jtag - interface used for jtag debugging.<br />
/dev/paparazzi/sereial - interface that is used for local board connections.<br />
<br />
.wine/dosdevices/com4 - interface for X-CTU (see [[Modems/xbee | xbee configuration page]]).</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=XBee_configuration&diff=12704XBee configuration2012-06-14T16:05:36Z<p>P0rc0 r0ss0: Redirected page to Modems/xbee</p>
<hr />
<div>#REDIRECT [[Modems/xbee]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Modems/xbee&diff=12703Modems/xbee2012-06-14T16:05:14Z<p>P0rc0 r0ss0: Created page with "Paparazzi supports the following modem protocols: * Standard transparent serial (pprz protocol, AT mode) - compatible with all modems and can be used to connect the autopilot dir…"</p>
<hr />
<div>Paparazzi supports the following modem protocols:<br />
* Standard transparent serial (pprz protocol, AT mode) - compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.<br />
* Digi (formerly Maxstream) API protocol (xbee) - compatible with all Digi modems including the 9XTend and Zigbee. This protocol enables hardware addressing through API mode, allowing multiple aircraft to be managed from a single ground modem.<br />
<br/><br />
<br />
== Introduction ==<br />
<br />
=== Installation of X-CTU ===<br />
The simples way to configure the XBee modems is to use the [http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=125 X-CTU] software from Digi. It runs under Windows or under Wine.<br />
<br />
Under Wine make sure you have the USB serial link connecting to XBee mapped to a com port:<br />
<br />
sudo ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com4<br />
<br />
If your X-CTU does not update its firmware correctely from the web, follow the steps described in the chapter "Manually Update the X-CTU firmware files" of [http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux this page].<br />
<br />
=== Configuring XBee AT mode using X-CTU ===<br />
This is the recommended way to start. With this firmware the modems basically act as a serial link replacement and don't do any mesh networking. The pprz protocol is based on this mode.<br />
<br/><br />
Basic approach:<br />
# Connect your XBee to your PC. There are several vendors of [[Modems#GCS_Adaptation|USB boards]].<br />
# Start the X-CTU programm and go to the modem configuration.<br />
# Click on READ<br />
# Select the appropriate function set with AT command set.<br />
# set PAN ID, etc... depending on which XBee you use<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly. At a higher baudrate setting, transmission can only be done in one direction.<br />
# Then write the firmware to the module.<br />
If X-CTU asks you to reset the XBee, you have to connect the RST pin (5) to the GND pin (10) of the XBee. You can do this manually using tweezers or a short wire.<br />
<br />
=== Configuring XBee using minicom ===<br />
<br />
Alternatively you can use the text-based modem control and terminal emulation program [http://en.wikipedia.org/wiki/Minicom minicom] instead of X-CTU to configure your XBee:<br />
<br />
# Connect XBee to your computer<br />
# Setup minicom (by default XBee modems come set up for 9600 baud)<br />
# Type Ctrl-A A in minicom this will set it up to add linefeeds to the stream<br />
# Type three '+' in quick succession resulting in "+++" string (you have 10s to type your next command otherwise the modem will revert back to transparent mode)<br />
#* you get a confirmation: 'OK'<br />
# Type "AT<enter>"<br />
#* you get a confirmation: 'OK'<br />
# Type "ATBD<enter>"<br />
#* you get the baudrate code: '3'<br />
# To set another baudrate select one of the following by typing "ATBD <baud code><enter>"<br />
#* 0 = 1200<br />
#* 1 = 2400<br />
#* 2 = 4800<br />
#* 3 = 9600<br />
#* 4 = 19200to connect the ground XBee radio modem to the GCS computer<br />
#* 5 = 38400<br />
#* 6 = 57600<br />
#* 7 = 115200<br />
# To store the new baudrate in the rom type "ATWR<enter>"<br />
# Now you can close minicom<br />
# Reconnect modem<br />
# Restart minicom with the new baudrate<br />
# Test that the modem is setup correctly by tiping "+++" and getting "OK" confirmation<br />
<br />
== XBee Pro ZB (AT command set) ==<br />
This 2.4GHz modem uses ZigBee PRO Feature Set and is compatible with devices from other vendors using the ZigBee PRO Feature Set.<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE COORDINATOR AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Pairing your Modems ===<br />
<br />
For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station.<br />
<br />
=== Reviving a non-responding Xbee Pro ===<br />
<br />
To bring an apparently dead XBee Pro Series 2 back to life, do the following:<br />
<br />
#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).<br />
#Open X-CTU.<br />
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).<br />
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.<br />
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.<br />
#Before you click OK to the dialog box, plug in the XBee module (carefully).<br />
#Click OK to clear the message and it should start programming automatically.<br />
<br />
=== Other tutorials ===<br />
<br />
[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]<br />
<br />
[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]<br />
<br />
== XBee Pro ZNet 2.5 (AT command set) ==<br />
These are legacy modems and not recommended/sold by Digi anymore.<br />
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.<br />
<br/><br />
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.<br />
# Set the Destination Address Low (DL) to FFFF.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Setup ===<br />
<br />
For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.<br />
* Flash one module (ground station) with the coordinator AT firmware<br />
* Flash aircraft module with router or end-device AT firmware<br />
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.<br />
<br />
If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:<br />
* Set PAN ID to some unique (but same) ID on both modules<br />
* Set a Node Identifier for each module (e.g. ground, aircraft)<br />
<br/><br />
<br />
== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# '''Set Coordinator Enable to "1 - COORDINATOR".'''<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
(Tested on XBP24 Firmwareversion 10E6)<br />
<br />
== XBee Pro 868 MHZ ==<br />
<br />
=== Getting Them Working ===<br />
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.<br />
<br />
I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.<br />
<br />
#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 &lt;baud rate, just a number, no angled brackets&gt;</code>, you can also use pico- or microcom)<br />
#Type AT and enter. You should get an OK back.<br />
#ATMT and enter. You should get a number&mdash;this represents the number of extra times each packet will be broadcast. We now need to change this to zero.<br />
#ATMT0 and enter => OK<br />
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.<br />
#ATRR0 and enter => OK<br />
#Type ATWR to store the new stuff in the firmware. You should get an OK.<br />
#Set the datalink to transparent mode both in your airframe file and on the datalink.<br />
<br />
You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though. <br />
<br />
You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.<br />
<br />
== XBee Pro XSC (900MHZ) ==<br />
<br />
== Configuring XBee API mode (xbee protocol) ==<br />
<br />
[[Category:Hardware]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=XBee_configuration&diff=12702XBee configuration2012-06-13T20:50:47Z<p>P0rc0 r0ss0: /* Installation of X-CTU */</p>
<hr />
<div>Paparazzi supports the following modem protocols:<br />
* Standard transparent serial (pprz protocol, AT mode) - compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.<br />
* Digi (formerly Maxstream) API protocol (xbee) - compatible with all Digi modems including the 9XTend and Zigbee. This protocol enables hardware addressing through API mode, allowing multiple aircraft to be managed from a single ground modem.<br />
<br/><br />
<br />
== Introduction ==<br />
<br />
=== Installation of X-CTU ===<br />
The simples way to configure the XBee modems is to use the [http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=125 X-CTU] software from Digi. It runs under Windows or under Wine.<br />
<br />
Under Wine make sure you have the USB serial link connecting to XBee mapped to a com port:<br />
<br />
sudo ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com4<br />
<br />
If your X-CTU does not update its firmware correctely from the web, follow the steps described in the chapter "Manually Update the X-CTU firmware files" of [http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux this page].<br />
<br />
=== Configuring XBee AT mode using X-CTU ===<br />
This is the recommended way to start. With this firmware the modems basically act as a serial link replacement and don't do any mesh networking. The pprz protocol is based on this mode.<br />
<br/><br />
Basic approach:<br />
# Connect your XBee to your PC. There are several vendors of [[Modems#GCS_Adaptation|USB boards]].<br />
# Start the X-CTU programm and go to the modem configuration.<br />
# Click on READ<br />
# Select the appropriate function set with AT command set.<br />
# set PAN ID, etc... depending on which XBee you use<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly. At a higher baudrate setting, transmission can only be done in one direction.<br />
# Then write the firmware to the module.<br />
If X-CTU asks you to reset the XBee, you have to connect the RST pin (5) to the GND pin (10) of the XBee. You can do this manually using tweezers or a short wire.<br />
<br />
=== Configuring XBee using minicom ===<br />
<br />
Alternatively you can use the text-based modem control and terminal emulation program [http://en.wikipedia.org/wiki/Minicom minicom] instead of X-CTU to configure your XBee:<br />
<br />
# Connect XBee to your computer<br />
# Setup minicom (by default XBee modems come set up for 9600 baud)<br />
# Type Ctrl-A A in minicom this will set it up to add linefeeds to the stream<br />
# Type three '+' in quick succession resulting in "+++" string (you have 10s to type your next command otherwise the modem will revert back to transparent mode)<br />
#* you get a confirmation: 'OK'<br />
# Type "AT<enter>"<br />
#* you get a confirmation: 'OK'<br />
# Type "ATBD<enter>"<br />
#* you get the baudrate code: '3'<br />
# To set another baudrate select one of the following by typing "ATBD <baud code><enter>"<br />
#* 0 = 1200<br />
#* 1 = 2400<br />
#* 2 = 4800<br />
#* 3 = 9600<br />
#* 4 = 19200to connect the ground XBee radio modem to the GCS computer<br />
#* 5 = 38400<br />
#* 6 = 57600<br />
#* 7 = 115200<br />
# To store the new baudrate in the rom type "ATWR<enter>"<br />
# Now you can close minicom<br />
# Reconnect modem<br />
# Restart minicom with the new baudrate<br />
# Test that the modem is setup correctly by tiping "+++" and getting "OK" confirmation<br />
<br />
== XBee Pro ZB (AT command set) ==<br />
This 2.4GHz modem uses ZigBee PRO Feature Set and is compatible with devices from other vendors using the ZigBee PRO Feature Set.<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE END DEVICE AT''' (or ZIGBEE ROUTER AT).<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZIGBEE COORDINATOR AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Pairing your Modems ===<br />
<br />
For maximum performance you can pair the ground modem to the airborne modem. Set the "DH - Destination Address High" and "DL - Destination Address Low" to the unique serial number "SH - Serial Number High" and "SL - Serial Number Low" of the other modem. Do so both on the ground modem and on the airborne modem. Failing to properly pair your modems will likely result in poor throughput and data loss between your airframe and your ground control station.<br />
<br />
=== Reviving a non-responding Xbee Pro ===<br />
<br />
To bring an apparently dead XBee Pro Series 2 back to life, do the following:<br />
<br />
#Connect the USB device that holds the XBee to your laptop/desktop (without the XBee connected).<br />
#Open X-CTU.<br />
#In the tab used to program the device, select the proper modem (normally you would do a READ to get the values).<br />
#Choose the option you want to program (i.e., "END DEVICE" or "COORDINATOR") as if you were programming it.<br />
#With the XBee not in the device, click "WRITE". It will hang, timeout, and bring up a dialog box.<br />
#Before you click OK to the dialog box, plug in the XBee module (carefully).<br />
#Click OK to clear the message and it should start programming automatically.<br />
<br />
=== Other tutorials ===<br />
<br />
[http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee PixHawk: HowTo configure XBee]<br />
<br />
[http://wiki.openpilot.org/display/Doc/Configure+Xbee+via+Linux openpilot: XBee RF modems]<br />
<br />
== XBee Pro ZNet 2.5 (AT command set) ==<br />
These are legacy modems and not recommended/sold by Digi anymore.<br />
It is recommended to upgrade these to XBee Pro ZB with the [ftp://ftp1.digi.com/support/images/ZNet%202.5%20to%20ZB%20Conversion%20Kit.zip ZNet 2.5 to ZB Conversion Kit] from Digi.<br />
<br/><br />
If you want to use ZNet 2.5 feature set nevertheless, here is how to configure it:<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 ROUTER/END DEVICE AT'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Select the function set '''ZNET 2.5 COORDINATOR DEVICE AT'''.<br />
# Set the Destination Address Low (DL) to FFFF.<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Setup ===<br />
<br />
For the ZigBee ZNet 2.5 and ZB modules to work one of the modules has to be flashed with the coordinator firmware. All the others in the same PAN can either run as routers or end-devices.<br />
* Flash one module (ground station) with the coordinator AT firmware<br />
* Flash aircraft module with router or end-device AT firmware<br />
To allow modules to join any PAN set the PAN ID to zero (default setting). Then the coordinator will generate a random PAN ID and routers and end-devices will join the first PAN they find.<br />
<br />
If you operate in an environment with multiple zigbee PANs it is recommended to set the PAN ID explicitly:<br />
* Set PAN ID to some unique (but same) ID on both modules<br />
* Set a Node Identifier for each module (e.g. ground, aircraft)<br />
<br/><br />
<br />
== XBee Pro DigiMesh / 802.15.4 ("Series 1") ==<br />
<br />
=== Flashing the airborne module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# Set the PAN ID to any number, must be the same as the pan id of the coordinator (Ground Station).<br />
# Set the Node Identifier (NI) to your aircraft name or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
=== Flashing the ground station module ===<br />
# Connect your XBee, start X-CTU, click READ<br />
# Leave the function set on '''XBEE PRO 802.15.4'''.<br />
# '''Set Coordinator Enable to "1 - COORDINATOR".'''<br />
# Set the PAN ID to any number, must be the same as the pan id of the end device (aircraft).<br />
# Set the Node Identifier (NI) to PPRZ_GROUND or any other appropriate name.<br />
# Set the baudrate you want to use. 57600 is the maximum baudrate setting for bidirectional transfers to work correctly.<br />
# Then write the firmware to the module.<br />
<br />
(Tested on XBP24 Firmwareversion 10E6)<br />
<br />
== XBee Pro 868 MHZ ==<br />
<br />
=== Getting Them Working ===<br />
Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.<br />
<br />
I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.<br />
<br />
#Attach Xbee and start serial comm program (I use <code>screen /dev/ttyUSB0 &lt;baud rate, just a number, no angled brackets&gt;</code>, you can also use pico- or microcom)<br />
#Type AT and enter. You should get an OK back.<br />
#ATMT and enter. You should get a number&mdash;this represents the number of extra times each packet will be broadcast. We now need to change this to zero.<br />
#ATMT0 and enter => OK<br />
#ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.<br />
#ATRR0 and enter => OK<br />
#Type ATWR to store the new stuff in the firmware. You should get an OK.<br />
#Set the datalink to transparent mode both in your airframe file and on the datalink.<br />
<br />
You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though. <br />
<br />
You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. '''Thanks to CheBuzz for this info''', and for helping me work all this out at 11pm the night before EMAV09.<br />
<br />
== XBee Pro XSC (900MHZ) ==<br />
<br />
== Configuring XBee API mode (xbee protocol) ==<br />
<br />
[[Category:Hardware]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Modems&diff=12701Modems2012-06-13T20:40:17Z<p>P0rc0 r0ss0: /* Digi XBee modules */</p>
<hr />
<div>The Paparazzi autopilots generally feature a TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Telemetry_.28Modem.29|Airframe Configuration]] and [[XBee_configuration|XBee Configuration]] pages.<br />
<br />
== Digi XBee modules ==<br />
<br />
Digi (formerly Maxstream) offers an increasing variety of Zigbee protocol modems well suited for Paparazzi in 2.4 GHz, 900MHz and 868Mhz frequencies. The "Pro" series are long range, up to 40km! Standard series are slightly smaller/lighter/lower power consumption and very short range. All versions are all pin compatible and weigh around 2 grams with wire antennas. All Digi modems can be operated in transparent mode (as a serial line replacement) or in "API mode" with hardware addressing, managed networking, and RSSI (signal strength) data with the Paparazzi "Xbee" option. Three antenna options are offered: the SMA version is ideal for ground modems, wire antennas for aircraft, and chip antennas for those with very limited space.<br />
<br />
* XBee (PRO) ZB (the current series)<br />
* XBee (PRO) ZNet 2.5 (formerly Series 2) (only legacy -> use XBee-PRO ZB)<br />
The XBee & XBee-PRO ZB share hardware (ember stack) with XBee & XBee-PRO ZNet 2.5. As a result, modules can be "converted" from one platform to another by loading different firmware onto a given module.<br />
<br />
These two also share the same hardware and can be converted from one to another by flashing a different firmware:<br />
* XBee-PRO 802.15.4 (formerly Series 1)<br />
* XBee-PRO DigiMesh 2.4<br />
<br />
'''Note: Modules based on Freescale chipset (formerly Series 1) are not compatible with Ember chipset based modules (Series 2).'''<br />
<br />
See the [[XBee_configuration|XBee Configuration]] page. This [http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee tutorial] is also good to configure and get started with XBee Pro.<br />
<br />
=== Module Comparison ===<br />
{|border="1"<br />
|-valign="top"<br />
||'''Module'''||'''Point-to-Multipoint'''||'''ZigBee/Mesh'''||'''Chipset'''|||'''Software stack'''||'''Frequency'''||'''TX Power normal/PRO'''||'''Notes'''<br />
|-<br />
|'''XBee ZB'''<br />
|<br />
|yes<br />
|Ember<br />
|EmberZNet PRO 3.1 (ZigBee 2007)<br />
|2.4 GHz<br />
|2mW/50mW<br />
|coordinator needed<br />
|-<br />
|'''XBee ZNet 2.5'''<br />
|<br />
|yes<br />
|Ember<br />
|EmberZNet 2.5 ZigBee<br />
|2.4 GHz<br />
|2mW/50mW<br />
|(only legacy -> use XBee-PRO ZB) coordinator needed<br />
|-<br />
|'''XBee DigiMesh 2.4'''<br />
|<br />
|yes<br />
|Freescale<br />
|<br />
|2.4 GHz<br />
|<br />
|all nodes equal (no special coordinators/routers/end-devices)<br />
|-<br />
|'''XBee 802.15.4'''<br />
|yes<br />
|<br />
|Freescale<br />
|<br />
|2.4 GHz<br />
|<br />
|<br />
|-<br />
|'''XBee-PRO 868'''<br />
|yes<br />
|<br />
|?<br />
|<br />
|868 MHz<br />
|500mW<br />
|Only High Power Frequency allowed in the UK. 2.4GHz limited to 10mW<br />
|}<br />
<br />
<br />
==== Comparison Conclusion ====<br />
<br />
(Copied from DIGI manual)<br />
<br />
''If the application strictly needs to communicate in a point-to-point or a point-to-multipoint <br />
fashion, 802.15.4 will be able handle all the communications between your devices and will <br />
be simpler to implement than trying to use a module with ZigBee firmware to accomplish the <br />
same goal. ZigBee is necessary if you need to use repeating or the mesh networking <br />
functionality.'' <br />
<br />
-Interpretation for paparazzi: if inter-aircraft communication is required one should go for the zigbee ZB series 2 modules. <br />
<br />
==== Pinout ====<br />
<br />
[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]<br />
<br style="clear:both"><br />
<br />
{|border="1"<br />
|-valign="top"<br />
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||<br />
|-<br />
|1<br />
| +3.3v<br />
| Power<br />
|Red<br />
|-<br />
|2<br />
|DOUT<br />
|Tx output - connect to Autopilot Rx<br />
|Green<br />
|-<br />
|3<br />
|DIN<br />
|Rx input - connect to Autopilot Tx<br />
|Blue<br />
|-<br />
|10<br />
|GND<br />
| Ground<br />
|Black<br />
|}<br />
<br />
The image view is from above, top, thus NOT at the side where the connector pins come out<br />
<br />
Note : DTR and RTS need to be wired for upgrading firmware<br />
<br />
=== GCS Adaptation ===<br />
<br />
There are several vendors of hardware to connect the ground XBee radio modem to the GCS computer.<br />
<br />
====Adafruit====<br />
<br />
[[Image:xbeeadapter_LRG.jpg|thumb|left|Adafruit XBee adapter board]][[Image:xbeeadapterftdi_LRG.jpg|thumb|Adafruit XBee adapter with FTDI cable]]<br />
[http://www.adafruit.com/index.php?main_page=product_info&cPath=29&products_id=126 Adafruit] (yes, that really is their name) offers a great adapter board kit for the Xbee modules that includes a 5-3.3V voltage regulator, power and activity LEDs, and pins to connect directly to your FTDI cable for $10! Some assembly required.<br />
<br />
<br style="clear:both"><br />
<br />
====Droids====<br />
<br />
[[Image:XBee_Simple_Board.jpg|thumb|left|XBee Simple Board]]<br />
<br />
[[Image:XBee_USB_Board.jpg|thumb|left|XBee USB Board]]<br />
<br />
[http://www.droids.it/cmsvb4/content.php?143-990.001-XBee-Simple-Board XBee Simple Board]<br />
<br />
Simpler, lighter, smaller footprint, bit more expensive, comes assembled and tested. --GR<br />
<br />
<br />
[http://www.droids.it/cmsvb4/content.php?152-990.002-XBee-USB-Board XBee USB Board]<br />
<br />
For direct connection to USB (no FTDI cable required)<br />
<br />
<br style="clear:both"><br />
<br />
====PPZUAV====<br />
<br />
[[Image:FTDI_Utility_Board.jpg|thumb|left|FTDI Utility Board 1.0]]<br />
<br />
[https://mini.ppzuav.com/osc/product_info.php?cPath=13&products_id=111 ppzuav.com]<br />
<br />
FTDI Utility Board 1.0 (no FTDI cable required)<br />
<br />
<br style="clear:both"><br />
<br />
====Sparkfun====<br />
<br />
[[Image:XBee_Explorer_USB.jpg|thumb|left|XBee Explorer USB]]<br />
<br />
[http://www.sparkfun.com/products/8687 sparkfun.com]<br />
<br />
XBee Explorer USB (no FTDI cable required)<br />
<br />
<br style="clear:both"><br />
<br />
=== Digi XBee Pro DigiMesh / 802.15.4 ("Series 1") ===<br />
*Note: Products based on XBee ZNet 2.5 (formerly Series 2) modules do not communicate with products based on XBee DigiMesh / 802.15.4 (formerly Series 1) modules.<br />
<br />
These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices. For the plane, get the whip antenna version if you are not planning to build a custom antenna.<br />
<br />
{|<br />
|-valign="top"<br />
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]<br />
|<br />
* Frequency Band 2.4Ghz<br />
* Output Power 100mW (Xbee Pro)<br />
* Sensitivity -100 dBm <br />
* RF Data Rate Up to 250 Kbps<br />
* Interface data rate Up to 115.2 Kbps<br />
* Power Draw (typical) 214 mA TX / 55 mA RX <br />
* Supply Voltage 3.3v<br />
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight <br />
* Dimensions 24 x 33mm<br />
* Weight 4 grams<br />
* Interface 20-pin mini connector <br />
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)<br />
* Price: Approximately $32<br />
|<br />
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]<br />
|}<br />
Mouser: [http://au.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMtJacPDJcUJYzVn8vIv7g2fIpf5DCzJqko%3d 888-XBP24-PKC-001-UA]<br><br />
NOTE: If you wish to use this unit with another XBee type other than the 802.15.4 (i.e. XBee-PRO ZB) then purchase a modem with the U.fl connector.<br />
<br />
==== Documentation ====<br />
<br />
* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]<br />
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]<br />
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]<br />
* To program your Xbee you need X-CTU you can download it [http://www.digi.com/support/productdetl.jsp?pid=3352&osvid=57&tp=5&s=316 here]. (only windows)<br />
* explanation on X-CTU [http://www.ladyada.net/make/xbee/configure.html here].<br />
* [http://ftp1.digi.com/support/firmware/update/xbee/ Drivers for XB24 and XBP24 modules]<br />
<br />
=== Digi XBee Pro ZB / ZNet 2.5 ("Series 2") ===<br />
<br />
The low-power XBee ZB and extended-range XBee-PRO ZB use the ZigBee PRO Feature Set for advanced mesh networking.<br />
<br />
{|<br />
|-valign="top"<br />
|[[Image:XBee_Pro_2SB.jpg|thumb|left|Digi XBee Pro ZB]]<br />
|<br />
* Low-cost, low-power mesh networking<br />
* Interoperability with ZigBee PRO Feature Set devices from other vendors*<br />
* Support for larger, more dense mesh networks<br />
* 128-bit AES encryption<br />
* Frequency agility<br />
* Over-the-air firmware updates (change firmware remotely)<br />
* ISM 2.4 GHz operating frequency<br />
* XBee: 2 mW (+3 dBm) power output (up to 400 ft RF LOS range)<br />
* XBee-PRO: 50 mW (+17 dBm) power output (up to 1 mile RF LOS range)<br />
* RPSMA connector, U.FL connector, Chip antenna, or Wired Whip antenna<br />
* price : ~34 USD<br />
|<br />
|}<br />
These are available from Mouser:<br><br />
[http://au.mouser.com/Search/Refine.aspx?Keyword=888-XBP24-Z7WIT-004 888-XBP24-Z7WIT-004] XBee-PRO ZB with whip antenna<br><br />
[http://au.mouser.com/Search/Refine.aspx?Keyword=XBP24-Z7SIT-004 888-XBP24-Z7SIT-004] XBee-PRO ZB with RPSMA<br />
<br />
See [[XBee_configuration|XBee Configuration]] for setup.<br />
<br />
==== Documentation ====<br />
* [http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp]<br />
<br />
=== Digi XBee Pro 868 ===<br />
<br />
'''WARNING - THESE MODEMS HAVE A 10% DUTY CYCLE, AND CURRENTLY HAVE SEVERE ISSUES WITH PAPARAZZI'''<br />
<br />
868MHz is a limited band. Please read the [[868MHz Issues]]<br />
<br />
XBee-PRO 868 modules are long range embedded RF modules for European applications. Purpose-built for exceptional RF performance, XBee-PRO 868 modules are ideal for applications with challenging RF environments, such as urban deployments, or where devices are several kilometers apart.<br />
<br />
<br />
{|<br />
|-valign="top"<br />
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro 868]]<br />
|<br />
* 868 MHz short range device (SRD) G3 band for Europe<br />
* Software selectable Transmit Power<br />
* 40 km RF LOS w/ dipole antennas<br />
* 80 km RF LOS w/ high gain antennas (TX Power reduced)<br />
* Simple to use peer-to-peer/point-to-mulitpoint topology<br />
* 128-bit AES encryption<br />
* 500 mW EIRP<br />
* 24 kbps RF data rate<br />
* price : ~70 USD<br />
|<br />
|}<br />
<br />
See [[XBee_configuration#XBee_Pro_868_MHZ|XBee Configuration]] for setup.<br />
<br />
==== Documentation ====<br />
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp]<br />
<br />
=== Digi XBee 868LP ===<br />
<br />
868MHz is a limited band. Please read the [[868MHz Issues]]<br />
<br />
XBee 868LP modules are a low-power 868 MHz RF module for use in Europe. The range is much shorter than it's brother the XBee PRO-868, but it can use the 868 G4 band which does not have restrictions on its duty cycle.<br />
<br />
{|<br />
|-valign="top"<br />
|[[Image:868lp.jpg|thumb|left|XBee 868LP]]<br />
|<br />
* 868 MHz short range device (SRD) G4 band for Europe<br />
* 4 km RF LOS w/ u.fl antennas<br />
* 5 mW EIRP<br />
* 80 kbps RF data rate<br />
* price : ~23 USD<br />
|<br />
|}<br />
<br />
==== Documentation ====<br />
* [http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview]<br />
<br />
=== Digi XBee Pro 900 (XBEE09P) ===<br />
<br />
XBee Pro 900 modules are long range embedded RF modules for US applications. Purpose-built for exceptional RF performance, XBee-Pro 900 modules are ideal for applications with challenging RF environments, such as urban deployments, or where devices are several kilometers apart.<br />
<br />
==== Documentation ====<br />
* [ftp://ftp1.digi.com/support/documentation/90000903_a.pdf]<br />
<br />
I've been using a pair of these for about 6 months now and they works great. To set it up I just used a serial terminal app like CoolTerm or screen and made sure I could send messages between the two of them. - cwozny<br />
<br />
=== Digi XBee Pro XSC 900MHz ===<br />
<br />
Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4 GHz video compatibility of their high end 900 MHz models. Sounds like the perfect modem for anyone who can use 900 MHz. Give them a try and post your results here!<br />
{|<br />
|-valign="top"<br />
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]<br />
|<br />
* Frequency Band 900 MHz<br />
* Output Power 100 mW (+20 dBm)<br />
* Sensitivity -100 dBm <br />
* Data Rate: 9600 bps<br />
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight <br />
* Interface 20-pin mini connector (Xbee compatible pinout)<br />
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)<br />
* price : $39 USD (on DigiKey)<br />
|<br />
|}<br />
<br />
==== Documentation ====<br />
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]<br />
==== Trials ====<br />
Tested one today and it worked great. Going to try a multiUAV test with it soon<br />
--Danstah<br />
<br><br />
<br><br />
MultiUAV tests concluded this is probably not the best module to use. Even though it says you can change the baudrate inside x-ctu that is not the case, it is fixed at 9600 bps. This is a great modem however for single UAV's and I do recommend.<br />
--Danstah<br />
<br><br />
<br><br />
Why would the European (868 MHz) be good to 24kbps and this only to 9600? When I was altering my XBees (2.4Ghz Pro's) I had this problem altering baud rates until I read you have to send a "commit and reboot" type command after setting the baud rate. Could this be the case? --GR<br />
<br />
== Maxstream 9XTend ==<br />
<br />
These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side, about 20 grams, but give good performance at range. They have adjustable transmit power settings from 100mW to 1W. Testing has shown range up to 5.6km (3.5 Miles) with XTend set to 100mW with small 3.1dB dipole antenna.<br />
<br />
{|<br />
|-valign="top"<br />
|<br />
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]<br />
|<br />
* Frequency Band 900Mhz and 2.4Ghz (2 versions)<br />
* Output Power 1mW to 1W software selectable<br />
* Sensitivity -110 dBm (@ 9600 bps)<br />
* RF Data Rate 9.6 or 115.2 Kbps<br />
* Interface data rate up to 230.4 Kbps<br />
* Power Draw (typical) 730 mA TX / 80 mA RX <br />
* Supply Voltage 2.8 to 5.5v<br />
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight <br />
* Dimensions 36 x 60 x 5mm<br />
* Weight 18 grams<br />
* Interface 20-pin mini connector <br />
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)<br />
* price : ~179 USD<br />
|<br />
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]<br />
|}<br />
<br />
=== Pinout ===<br />
<br />
[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]<br />
<br />
{| border="1"<br />
|-valign="top"<br />
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''<br />
|-<br />
||1||GND||1 (GND)||Ground <br />
|-<br />
||2||VCC||2 (5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)<br />
|-<br />
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX<br />
|-<br />
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX<br />
|-<br />
||7||Shutdown||2||This pin must be connected to the 5V bus for normal operation<br />
|}<br />
Notes:<br><br />
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.<br />
<br style="clear:both"><br />
<br />
=== Documentation ===<br />
<br />
* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]<br />
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]<br />
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]<br />
<br />
=== Configuration ===<br />
<br />
These modems need to be carefully configured based on your usage scenario to obtain the highest performance. In addition, it is always good to make sure the firmware is up to date.<br />
<br />
Some typical configurations that may work well (again depends on your particular situation) are given below. For further details, be sure to consult the XTend users manual. Your application may need a different or modified configuration. In addition, the radios do not need identical settings and can in fact be optimized with different settings. A good example is delays and retries: if each radio has the same number of retries and no delay, when a collision occurs each will continuously try to re-transmit, locking up the transmission for some time with no resolution or successful packet delivery. Instead, it is best to set the module whose data should have a lower latency to have no delay and a lower number of retries, while the other module has a delay set (RN > 0) and a greater number of retries. See acknowledged mode example below.<br />
<br />
* Acknowledged Polling Mode ('''Recommended'''):<br />
** This causes one radio to be the base and the other(s) to be the remote(s). It eliminates collisions because remotes do not send data unless requested by the base. It can work in acknowledged mode (RR>0), basic reliable mode (MT>0) or in basic mode (no acknowledgement or multiple packets). It is recommended that the lower latency and/or higher data rate side be configured as the base (i.e. if you are sending lots of telemetry then the air module configured as the base is probably a good idea, but if you are using datalink joystick control, the ground side might be better as the base. It may require some experimentation).<br />
* Acknowledged Point-to-(Multi)Point Mode:<br />
** Each radio sends a packet and requests and acknowledgement that the packet was sent from the receiving side. The retries and delays must be set appropriately to ensure packet collisions are dealt with appropriately. It can also work without acknowledgements in basic reliable mode (MT>0) without any acknowledgements (RR=0, MT=0). Some experimentation may be required.<br />
<br />
{| border="1"<br />
|-valign="top"<br />
||'''''Setting Name'''''||colspan="2"|'''''Acknowledged Mode'''''||colspan="2"|'''''Polling Mode (Acknowledged)'''''||'''''Notes'''''<br />
|-<br />
|| ||'''''Airside Module'''''||'''''Groundside Module'''''||'''''Base Module'''''||'''''Remote Module'''''||<br />
|-<br />
||BD||6||6||6||6||Adjust to match your configured autopilot and ground station baud rates (default for these is 57600bps)<br />
|-<br />
||DT||default||default||0x02||0x01||Can be adjusted if consistency maintained across addressing functionalities (see manual)<br />
|-<br />
||MD||default||default||3 (0x03)||4 (0x04)||<br />
|-<br />
||MT||0||0||0||0||Use this to enable Basic Reliable transmission, link bandwidth requirement increases (see manual)<br />
|-<br />
||MY||default||default||0x01||0x02||Can be adjusted if consistency maintained across addressing functionalities (see manual)<br />
|-<br />
||PB||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)<br />
|-<br />
||PD||default||default||default||default||Can be adjusted to increase polling request rate and DI buffer flush timeout (see manual)<br />
|-<br />
||PE||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)<br />
|-<br />
||PL||default||default||default||default||''Transmit power level should be reduced for lab testing!!''<br />
|-<br />
||RN||0 (0x00)||8 (0x08)||default||default||<br />
|-<br />
||RR||6 (0x06)||12 (0x0C)||6 (0x06)||12 (0x0C)||<br />
|}<br />
<br />
'''Note:''' All settings are assumed to be default except those listed. Those listed are in decimal unless hex 0x prefix included. Depending on your firmware version, slight modifications may be necessary.<br />
<br />
Here is some additional information and alternative instructions to configure the polling mode from the Digi site: [http://www.digi.com/support/kbase/kbaseresultdetl?id=2178 Polling Mode for the 9XTend Radio Modem]<br />
<br />
== Aerocomm ==<br />
Aerocomm's API mode is already implemented but some system integration is required. Full API more with addressed packets works well and was tested with AC4790-1x1 5mW low power modules. Maximim range achieved with a whip quater-wave antenna was 1Km.<br />
<br />
How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]<br />
<br />
See folder paparazzi3 / trunk / sw / aerocomm. It has all the required files to use this modem on the airborne and ground station side. The link.ml file is a direct replacement of the "main" link.ml file of the ground sttaion and will be merged into it in the future.. or you can do it as well.<br />
<br />
<br />
{|<br />
|<br />
=== AC4868-250 ===<br />
* Frequency Band 868MHz (For Europe). 868MHz is a limited band. Please read the [[868MHz Issues]]<br />
* Output Power (w/ 2dBi antenna) 250 mW <br />
* Sensitivity (@ full RF data rate) -103 dB <br />
* RF Data Rate Up to 28.8 Kbps <br />
* INterface Data Rate Up to 57.6 Kbps <br />
* Power Draw (typical) 240 mA TX / 36 mA RX <br />
* Supply Voltage 3.3v & 5V or 3.3v only<br />
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight <br />
* Dimensions 49 x 42 x 5mm <br />
* Weight < 21 grams<br />
* Interface 20-pin mini connector <br />
* Antenna MMCX jack Connector <br />
* price : ~80$<br />
|<br />
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]<br />
|-<br />
|<br />
<br />
=== AC4790-200 ===<br />
* Frequency 902-928MHz (North America, Australia, etc).<br />
* Output Power 5-200mW<br />
* Sensitivity (@ full RF data rate) -110dB<br />
* RF Data Rate up to 76.8 Kbps<br />
* INterface Data Rate Up to Up to 115.2 Kbps <br />
* Power Draw (typical) 68 mA<br />
* Supply Voltage 3.3v & 5.5V<br />
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight <br />
* Dimensions 42 x 48 x 5mm <br />
* Weight < 20 grams<br />
* Interface 20-pin mini connector <br />
* Antenna MMCX jack Connector or internal<br />
* price : ~80$<br />
|<br />
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]<br />
|<br />
|-<br />
|<br />
<br />
=== AC4790-1000 ===<br />
* Frequency 902-928MHz (North America, Australia, etc).<br />
* Output Power 5-1000mW<br />
* Sensitivity (@ full RF data rate) -99dB<br />
* RF Data Rate up to 76.8 Kbps<br />
* INterface Data Rate Up to Up to 115.2 Kbps <br />
* Power Draw (typical) 650 mA<br />
* Supply Voltage 3.3V only<br />
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna<br />
* Dimensions 42 x 48 x 5mm <br />
* Weight < 20 grams<br />
* Interface 20-pin mini connector <br />
* Antenna MMCX jack Connector<br />
* price : ~80$<br />
|}<br />
<br />
=== Pinout ===<br />
<br />
[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Aerocomm AC4868 modem pinout]]<br />
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Aerocomm AC4490 wiring example]]<br />
<br style="clear:both"><br />
<br />
{| border="1"<br />
|+ Wiring the Aerocomm AC4868 to the Tiny<br />
|-valign="top"<br />
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny v1.1 Serial-1'''''||'''''Tiny v2.11 Serial'''''||'''''Notes'''''<br />
|-<br />
||2||Tx||green||7||7||''(Note 1)''<br />
|-<br />
||3||Rx||blue||8||8||''(Note 1)''<br />
|-<br />
||5||GND||black||1||1|| -<br />
|-<br />
||10+11||VCC||red||2||3||+3.3v ''(Note 2)''<br />
|-<br />
||17||C/D||white||3||?||Low = Command High = Data<br />
|}<br />
''Note 1 : names are specified with respect to the AEROCOMM module''<br />
<br />
''Note 2 : AC4790-1000 needs pins 10 and 11 jumped to work properly''<br />
<br />
=== Documentation ===<br />
* [http://www.aerocomm.com/rf_transceiver_modules/ac4790_mesh-ready_transceiver.htm AC4790 product page]<br />
* [http://www.aerocomm.com/docs/Datasheet_AC4790_HI.pdf AC4790 Datasheet]<br />
* [http://www.aerocomm.com/docs/User_Manual_AC4790.pdf AC4790 Manual]<br />
* [http://www.aerocomm.com/rf_transceiver_modules/ac4868_868mhz_rf_transceiver.htm AC4848 product page]<br />
* [http://www.aerocomm.com/docs/Datasheet_AC4868_HI.pdf AC4868 Datasheet]<br />
* [http://www.aerocomm.com/docs/User_Manual_AC4868.pdf AC4868 user manual]<br />
<br />
== Radiotronix ==<br />
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise as connected RTS/CTS sporadically leads to a reprogramming of the modem. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions. Note that a 1/2 wave dipole antenna works best on-board as it doesn't require a ground-plane and has a reasonably omnidirectional radiation pattern.<br />
{|<br />
|<br />
=== WI232EUR ===<br />
* Frequency Band: 868 MHz (for Europe)<br />
* Output Power: 32 mW <br />
* RF Data Rate: Up to 76.8 kbps <br />
* Interface Data Rate: up to 115.2 kbps <br />
* Power Draw (typical): 65 mA TX / 20 mA RX <br />
* Supply Voltage: 3.3v<br />
* Range (typical, depends on antenna & environment): 500 meters line-of-sight <br />
* Dimensions: 24 x 21 x 4mm <br />
* Weight: ~2 grams<br />
* Interface: solder connector <br />
* Antenna: solder connector <br />
* Price: ~25$<br />
|<br />
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem (picture shows connection to Tiny 1.1)]]<br />
|-<br />
|<br />
<br />
=== Pinout ===<br />
<br />
<br style="clear:both"><br />
<br />
{| border="1"<br />
|+ Wiring the WI232EUR to the Tiny v1.1<br />
|-valign="top"<br />
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''<br />
|-<br />
||6||TxD||7||''(Note 1)''<br />
|-<br />
||5||RxD||8||''(Note 1)''<br />
|-<br />
||15-18||GND||1|| - <br />
|-<br />
||19||VCC||2||+3.3v<br />
|-<br />
||4||/CMD||-||''(Note 2)''<br />
|-<br />
||7||CTS||-||''(Note 3)''<br />
|}<br />
''Note 1 : names are specified with respect to the Radiotronix module''<br />
<br />
''Note 2 : connect to RTS to program device with Evaluation software''<br />
<br />
''Note 3 : connect to CTS to program device with Evaluation software''<br />
<br />
|<br />
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]<br />
|-<br />
|<br />
|}<br />
=== Documentation ===<br />
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]<br />
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]<br />
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]<br />
<br />
== Bluetooth ==<br />
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.<br />
{|<br />
|<br />
=== "Sparkfun" Roving Networks (WRL-08497) ===<br />
* Frequency Band 2.4GHz<br />
* Output Power 32 mW <br />
* RF Data Rate up to ~300 kbps in SPP<br />
* Interface Data Rate up to 921 kbps <br />
* Power Draw (typical) 50 mA TX / 40 mA RX <br />
* Supply Voltage 3.3v<br />
* Range (typical, depends on antenna & environment) 100 meters line-of-sight <br />
* Dimensions 26 x 13 x 2mm <br />
* Weight ~1.5 grams<br />
* Interface solder connector <br />
* price : ~45$<br />
|<br />
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]<br />
|-<br />
|<br />
<br />
To connect to it, get the MAC address of the bluetooth modem<br />
<br />
me@mybox:~$ hcitool scan<br />
Scanning ...<br />
00:06:66:00:53:AD FireFly-53AD<br />
<br />
either make a virtual connection to a Bluetooth serial port each time you connect<br />
<br />
sudo rfcomm bind 0 00:06:66:00:53:AD<br />
<br />
or configure it once in /etc/bluetooth/rfcomm.conf<br />
<br />
rfcomm0 {<br />
bind yes;<br />
device 00:06:66:00:53:AD;<br />
}<br />
<br />
now you can use Bluetooth as '''/dev/rfcomm0''' with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.<br />
|}<br />
<br />
== Coronis WaveCard ==<br />
<br />
These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.<br />
<br />
'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''<br />
{|<br />
|-valign="top"<br />
|<br />
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)<br />
* Output Power 25mW and 500mW (2 versions)<br />
* Sensitivity -110 dBm (@ 9600 bps)<br />
* Data Rate 100 Kbps<br />
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX <br />
* Supply Voltage ...<br />
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight <br />
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)<br />
* 50 ohm RF port for antenna connection<br />
|<br />
[[Image:wavecard.jpg|Coronis Wavecard]]<br />
|}<br />
<br />
=== Documentation ===<br />
<br />
* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]<br />
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]<br />
<br />
== Telemetry via Video Transmitter==<br />
<br />
[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]<br />
In order for the UAV to transmit video from an onboard camera, an analog video transmitter can be used. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different. <br />
<br />
It is possible to use the audio channel to send simple telemetry data to the groundstation. Uploading telemetry not possible via analog audio transmitter only.<br />
<br style="clear:both"><br />
<br />
== Antennas ==<br />
<br />
Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.<br />
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]] <br />
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]] <br />
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]] <br />
<br style="clear:both"><br />
<br />
This wiki page might give some ideas about antennas: http://en.wikipedia.org/wiki/Dipole_antenna<br />
<br />
[[Category:Hardware]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12651ImuCalibration2012-06-11T10:51:09Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 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 />
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 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>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Airframe-90x68.jpg&diff=12645File:Airframe-90x68.jpg2012-06-11T09:24:46Z<p>P0rc0 r0ss0: uploaded a new version of "File:Airframe-90x68.jpg"</p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Airframe-90x68.jpg&diff=12644File:Airframe-90x68.jpg2012-06-11T09:21:41Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Ublox-90x90.jpg&diff=12642File:Ublox-90x90.jpg2012-06-11T09:16:38Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Mag_fit_3d-90x90.jpg&diff=12640File:Mag fit 3d-90x90.jpg2012-06-11T09:04:18Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Quad-90x64.jpg&diff=12639File:Quad-90x64.jpg2012-06-11T08:57:05Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Solarstorm-64x64.jpg&diff=12636File:Solarstorm-64x64.jpg2012-06-11T08:39:22Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Linux-64x64.jpg&diff=12635File:Linux-64x64.jpg2012-06-11T08:32:13Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12617ImuCalibration2012-06-10T20:11:16Z<p>P0rc0 r0ss0: /* Calibrating the Magnetometer */</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 />
<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.<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 />
=== Calibrating the Accelerometers ===<br />
<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.<br />
Image:Acc_cailbration.jpg|Orientation sequence during accelerometer calibration<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
First of all, it is important to know, that magnetometer is quite sensitive to all the magnetic (metallic) objects around, so during calibration try to keep IMU as far away from metal and magnets as possible. Preferably you do the mag calibration with the mag/autopilot mounted in your frame, since all ferromagnetic materials near the mag disort the magnetic field you measure. You basically do a hard-iron (offset of the sphere) and soft-iron (distortion to an ellipsoid) calibration.<br />
<div style="float: right; width: 250px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Mag_london_inc-dec.jpg|fig. MAG1 - Here is an example for London<br />
</gallery></div><br />
Whole procedure consists of several simple steps:<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 />
# Start Paparazzi Center, prepare GCS and switch sensors to "raw_sensors" mode if you haven't done it yet.<br />
# Point every axis at least once in the direction (and opposite) of the magnetic field to get the minimum and maximum values. Ideally you would spin it around all axes until you have covered the whole sphere with measurements. However it is also sufficient to '''align each magnetometer axes along the local magnetic field vector''' once in both directions to get the min/max values. The local magnetic vector is line that directs from point where you hold your IMU in direction which you get from previous step.'''*'''<br />
# Feed all the data found in var/logs/YY_MM_DD__hh_mm_ss.data file to scirpt:<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<br />
the resulted data should be added to airframe configuration file.<br />
<br />
'''*''' - It is usually convenient to [[RTPlotter|plot]] the ''IMU_MAG_RAW'' values to see when you get the maximum on each axis. To do it open [[Paparazzi_Center | Paparazzi Center]]->Tools->Plotter and <same path>->Messages, find IMU_MAG parameter and click on it, three values appear to the right. Drag and drop each value to Plotter canvas. This will allow you to see graphs.<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12616ImuCalibration2012-06-10T19:50:24Z<p>P0rc0 r0ss0: /* Calibrating the Magnetometer */</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 />
<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.<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 />
=== Calibrating the Accelerometers ===<br />
<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.<br />
Image:Acc_cailbration.jpg|Orientation sequence during accelerometer calibration<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
First of all, it is important to know, that magnetometer is quite sensitive to all the magnetic (metallic) objects around, so during calibration try to keep IMU as far away from metal and magnets as possible. Preferably you do the mag calibration with the mag/autopilot mounted in your frame, since all ferromagnetic materials near the mag disort the magnetic field you measure. You basically do a hard-iron (offset of the sphere) and soft-iron (distortion to an ellipsoid) calibration.<br />
<div style="float: right; width: 250px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Mag_london_inc-dec.jpg|fig. MAG1 - Here is an example for London<br />
</gallery></div><br />
Whole procedure consists of three simple steps:<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 />
# Point every axis at least once in the direction (and opposite) of the magnetic field to get the minimum and maximum values. Ideally you would spin it around all axes until you have covered the whole sphere with measurements. However it is also sufficient to '''align each magnetometer axes along the local magnetic field vector''' once in both directions to get the min/max values. The local magnetic vector is line that directs from point where you hold your IMU in direction which you get from previous step.<br />
<br />
It is usually convenient to [[RTPlotter|plot]] the ''IMU_MAG_RAW'' values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Mag_london_inc-dec.jpg&diff=12615File:Mag london inc-dec.jpg2012-06-10T19:42:06Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12614ImuCalibration2012-06-10T19:40:45Z<p>P0rc0 r0ss0: /* Calibrating the Magnetometer */</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 />
<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.<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 />
=== Calibrating the Accelerometers ===<br />
<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.<br />
Image:Acc_cailbration.jpg|Orientation sequence during accelerometer calibration<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
First of all, it is important to know, that magnetometer is quite sensitive to all the magnetic (metallic) objects around, so during calibration try to keep IMU as far away from metal and magnets as possible.<br />
Whole procedure consists of three simple steps:<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.<br />
# <br />
<br />
Preferably you do the mag calibration with the mag/autopilot mounted in your frame, since all ferromagnetic materials near the mag disort the magnetic field you measure. You basically do a hard-iron (offset of the sphere) and soft-iron (distortion to an ellipsoid) calibration...<br />
<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis (not just take the same orientations as when calibrating the accelerometer). Ideally you would spin it around all axes until you have covered the whole sphere with measurements. However it is also sufficient to '''align each magnetometer axes along the local magnetic field vector''' once in both directions to get the min/max values.<br />
<br />
It is usually convenient to [[RTPlotter|plot]] the ''IMU_MAG_RAW'' values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12612ImuCalibration2012-06-10T18:36:44Z<p>P0rc0 r0ss0: </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 />
<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.<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 />
=== Calibrating the Accelerometers ===<br />
<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.<br />
Image:Acc_cailbration.jpg|Orientation sequence during accelerometer calibration<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so '''align the magnetometer axes along the local magnetic field vector''' (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to [[RTPlotter|plot]] the ''IMU_MAG_RAW'' values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12609ImuCalibration2012-06-10T17:40:00Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 />
Paparazzi comes with a Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under:<br />
<br />
sw/tools/calibration/calibrate.py <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 />
<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.<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 />
=== Calibrating the Accelerometers ===<br />
<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis. Warning! Aspirin 1.5 has x and y silkscreen swapped.<br />
Image:Acc_cailbration.jpg|Orientation sequence during accelerometer calibration<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so align the magnetometer axes along the local magnetic field vector (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to plot the values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12603ImuCalibration2012-06-10T16:50:46Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 />
Paparazzi comes with a Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under:<br />
<br />
sw/tools/calibration/calibrate.py <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 />
<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 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 log file (to ''var/logs'').<br />
* Run the Python script on it to get your calibration coefficients.<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 />
=== Calibrating the Accelerometers ===<br />
<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis.<br />
Image:Acc_cailbration.jpg|Orientation sequence during accelerometer calibration<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so align the magnetometer axes along the local magnetic field vector (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to plot the values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12575ImuCalibration2012-06-10T15:56:40Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 />
Paparazzi comes with a Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under:<br />
<br />
sw/tools/calibration/calibrate.py <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 />
<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 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 log file (to ''var/logs'').<br />
* Run the Python script on it to get your calibration coefficients.<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 />
=== Calibrating the Accelerometers ===<br />
<br />
<br />
<div style="float: right; width: 500px; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis.<br />
Image:Acc_cailbration.jpg|orientations<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so align the magnetometer axes along the local magnetic field vector (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to plot the values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12573ImuCalibration2012-06-10T15:55:09Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 />
Paparazzi comes with a Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under:<br />
<br />
sw/tools/calibration/calibrate.py <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 />
<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 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 log file (to ''var/logs'').<br />
* Run the Python script on it to get your calibration coefficients.<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 />
=== Calibrating the Accelerometers ===<br />
<div style="float: right; width: 45%; overflow: hidden"><gallery widths=200px heigths=200px><br />
Image:Aspirin_imu_front_small.jpg|Note that front of aircraft can be found on IMU marked as X axis.<br />
Image:Acc_cailbration.jpg|orientations<br />
</gallery></div><br />
<br />
To calibrate the accelerometers turn 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 />
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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so align the magnetometer axes along the local magnetic field vector (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to plot the values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12570ImuCalibration2012-06-10T14:08:47Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 />
Paparazzi comes with a Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under:<br />
<br />
sw/tools/calibration/calibrate.py <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 />
<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 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 log file (to ''var/logs'').<br />
* Run the Python script on it to get your calibration coefficients.<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 />
=== Calibrating the Accelerometers ===<br />
Note that front of aircraft can be found on IMU marked as X axis.<br />
<br />
[[File:Aspirin_imu_front_small.jpg]]<br />
<br />
To calibrate the accelerometers turn the IMU on all six sides of the cube:<br />
* 1: upright,<br />
* 2: inverted,<br />
* 3: on the nose,<br />
* 4: on the tail,<br />
* 5: on the right side,<br />
* 6: on the left side.<br />
<br />
[[File:Acc_cailbration.jpg]]<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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so align the magnetometer axes along the local magnetic field vector (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to plot the values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Aspirin_imu_front_small.jpg&diff=12569File:Aspirin imu front small.jpg2012-06-10T14:03:31Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Acc_cailbration.jpg&diff=12568File:Acc cailbration.jpg2012-06-10T13:54:24Z<p>P0rc0 r0ss0: uploaded a new version of "File:Acc cailbration.jpg":&#32;Reverted to version as of 13:53, 10 June 2012</p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Acc_cailbration.jpg&diff=12567File:Acc cailbration.jpg2012-06-10T13:54:12Z<p>P0rc0 r0ss0: uploaded a new version of "File:Acc cailbration.jpg":&#32;Reverted to version as of 13:44, 10 June 2012</p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Acc_cailbration.jpg&diff=12566File:Acc cailbration.jpg2012-06-10T13:53:56Z<p>P0rc0 r0ss0: uploaded a new version of "File:Acc cailbration.jpg"</p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12565ImuCalibration2012-06-10T13:47:13Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 />
Paparazzi comes with a Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under:<br />
<br />
sw/tools/calibration/calibrate.py <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 />
<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 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 log file (to ''var/logs'').<br />
* Run the Python script on it to get your calibration coefficients.<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 />
=== Calibrating the Accelerometers ===<br />
To calibrate the accelerometers turn the IMU on all six sides of the cube:<br />
* 1: upright,<br />
* 2: inverted,<br />
* 3: on the nose,<br />
* 4: on the tail,<br />
* 5: on the right side,<br />
* 6: on the left side.<br />
<br />
[[File:Acc_cailbration.jpg]]<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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so align the magnetometer axes along the local magnetic field vector (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to plot the values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Acc_cailbration.jpg&diff=12564File:Acc cailbration.jpg2012-06-10T13:44:36Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=ImuCalibration&diff=12556ImuCalibration2012-06-10T12:35:26Z<p>P0rc0 r0ss0: /* Calibrating the Accelerometers */</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 />
Paparazzi comes with a Python script to calibrate the accelerometers and magnetometer. The application can be found in the Paparazzi directory under:<br />
<br />
sw/tools/calibration/calibrate.py <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 />
<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 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 log file (to ''var/logs'') and run the Python script on it to get your calibration coefficients.<br />
<br />
(To get the ac_id, just open the *.data file - second column)<br />
<br />
=== Calibrating the Accelerometers ===<br />
To calibrate the accelerometers turn the IMU on all six sides of the cube (upright, inverted, on the nose, on the tail, on the right side, and on the left side.) 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 and run the Python script on it to get your calibration coefficients: <br />
<br />
''sw/tools/calibration/calibrate.py -i <your_ac_id> -s ACCEL <path_to_data_file var/logs/xxxxxxx.data>''<br />
<br />
/!\ Be adwise, ac_id can be found on [[Paparazzi_Center | Paparazzi Center]] upper left side. (first comes A/C name, and then id value)<br />
<br />
=== Calibrating the Magnetometer ===<br />
This is the most crucial part for the magnetometer calibration: you really need to get the min/max on each axis, so align the magnetometer axes along the local magnetic field vector (not just take the same orientations as when calibrating the accelerometer.)<br />
<br />
It is usually convenient to plot the values to see when you get the maximum on each axis.<br />
The inclination and declination of the magnetic field where you live can be looked up [http://www.ngdc.noaa.gov/geomagmodels/IGRFWMM.jsp here].<br />
<br />
''sw/tools/calibration/calibrate.py -i <your_ac_id> -s MAG <path_to_data_file var/logs/xxxxxxx.data>''<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 the Gyroscopes ===<br />
To [[ImuCalibration/Gyroscopes|calibrate the gyros]] you need a turntable....<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 />
==Body to IMU Rotation ==<br />
Provision is made within the software to physically locate supported IMUs in orientations with respect to the aircraft/rotorcraft frame which suit available mounting options. <br />
<br />
* The in-line, parallel mount example: <br />
<br />
[[Image:Quad-top.png|240px]] <br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
As noted further above, calibration and sign verification procedures are carried out relative to the IMU frame, hence defines should be left at zero until they are completed. <br />
<br />
* The positive 90 degree offset, parallel mount example:<br />
<br />
[[Image:Quad-top_IMU-90.png|240px]]<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Another variation might include turning the IMU upside-down in the parallel plane:<br />
<br />
Configured as:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="180." unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="0." unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="0." unit="deg"/><br />
</pre><br />
}} <br />
<br />
===In Flight Tuning===<br />
* Switch to AHRS telemetry mode and look for the fields that are prefixed with imu_<br />
<br />
[[Image:AHRS telemetry.png|240px]] <br />
90 degree positive offset example<br />
<br />
* Open a Real_time plotter from the paparazzi console tools tab and drag int32 body_phi and int32 body_theta into the plotter box.<br />
<br />
* Hover rotorcraft (preferably indoors) to record data.<br />
<br />
* Copy the (best fit) recorded values into the airframe BODY_TO_IMU defines:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<pre><br />
<define name="BODY_TO_IMU_PHI" value="1.5" unit="deg"/><br />
<define name="BODY_TO_IMU_THETA" value="-0.5" unit="deg"/><br />
<define name="BODY_TO_IMU_PSI" value="90." unit="deg"/><br />
</pre><br />
}} <br />
<br />
* Ignore 'on the ground' resting values as depicted in the above image. They will change once the vehicle is in flight. The aim is to get the 'in flight' values of "int32 body_phi" & "int32 body_theta" as close to zero as possible. <br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Dev/Debugging&diff=11491Dev/Debugging2012-02-12T08:57:16Z<p>P0rc0 r0ss0: /* Procedure */</p>
<hr />
<div>= Introduction =<br />
GDB can be used for debugging the code on the boards. Here are a couple of words on [[JTAG]] itself and [[DevGuide/JTAG-Debug#JTAG_debugging|debugging process]].<br />
<br />
= Procedure =<br />
# Start openocd in a new shell since this process needs to remain running.<br />
#: To program the Lisa/L board run the command<br />
#:<pre>openocd -f interface/lisa-l.cfg -f board/lisa-l.cfg</pre><br />
#:or if you are still using the old paparazzi-stm32 package and your path is not set properly <br />
#:<pre>cd /opt/paparazzi/stm32/share/openocd/scripts/; /opt/paparazzi/stm32/bin/openocd -f interface/lisa-l.cfg -f board/lisa-l.cfg</pre><br />
#: To program the Lisa/M board via JTAG change dir to "<paparazzi root>/arm-multilib/share/openocd/scripts", and run the command:<br />
#:<pre>openocd -f interface/flossjtag.cfg -f board/lisa-l.cfg</pre><br />
<br />
''NOTICE:'' For lisa/m boards file lisa-m.cfg should look like:<br />
<pre># the Lost Illusions Serendipitous Autopilot<br />
# http://paparazzi.enac.fr/wiki/Lisa<br />
# Work-area size (RAM size) = 64kB for STM32F103RB device<br />
set WORKAREASIZE 0xFA00<br />
source [find target/stm32f1x.cfg]</pre><br />
# Start GDB with an argument of the elf file created and uploaded to the board.<br />
#: If you programmed with the ap target then the command would be along the lines of<br />
#:<pre>arm-none-eabi-gdb var/<airframe>/ap/ap.elf</pre><br />
#:or (if you are using the old paparazzi-stm32 package)<br />
#:<pre>/opt/paparazzi/stm32/bin/arm-none-eabi-gdb ./var/<airframe>/ap/ap.elf</pre><br />
#: Replace <airframe> with the name of the airframe that has been built.<br />
# Now connect GDB to the board <br />
#:<pre>target remote localhost:3333</pre><br />
# Now we need to set some break points in the code.<br />
#: In this example the ap target was part of the rotorcraft and main.c contains the main program. Open rotorcraft sw/airborne/firmwares/rotorcraft/main.c and find a line at which you'd like to set a break point.<br />
#: <pre>break main.c:113</pre><br />
# Stop the currently running code<br />
#: <pre>monitor reset halt</pre><br />
# Reset the code back to the start<br />
#: <pre>monitor reset init</pre><br />
# We probably want to ignore the interrupt calls for the moment so we can step through the code as it's being called. Note that we don't always want to do this.<br />
#:<pre>monitor cortex_m3 maskisr on</pre><br />
# Now we can run the program which will stop at the break point we set.<br />
#:<pre>continue</pre><br />
<br />
== Useful commands ==<br />
* A stack trace can be printed with the command<br />
*:<pre>bt</pre><br />
* show the variable of a variable<br />
*:<pre>print i2c1.status</pre><br />
* Show (eXamine) the value of the 9 bytes hardware register at address 0x40005800 and show them in hex format:<br />
*:<pre>x/9x 0x40005800</pre><br />
<br />
[[Category:Software]] [[Category:Developer_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Main_Page&diff=11280Main Page2012-01-02T17:48:10Z<p>P0rc0 r0ss0: </p>
<hr />
<div>__NOTOC__<br />
__NOEDITSECTION__<br />
<br />
{|style="border-spacing:8px;margin:0px -8px" class="MainPageBG" style="width:100%;border:1px solid #9999bf;background-color:#f5fffa;vertical-align:top;color:#000; text-align: left;"<br />
|-<br />
|align="center" colspan="2"| <h2 style="margin:0;background-color:#82add9;font-size:150%;font-weight:bold;border:0px solid #a3bfb1;text-align:center;color:#ffffff;padding:0.2em 0.4em;">Welcome To Paparazzi</h2><br />
|-valign="top"<br />
|<br />
<h3 style="-moz-border-radius-topleft: 0em;-moz-border-radius-topright: 0.7em;<br />
background:#cedff2;margin:-2px;padding:4px;"><br />
[[Image:favicon32.png|32px]] [[General|General]] <br />
</h3><br />
<div style="padding:6px;"><br />
{{General}}<br />
</div><br />
<h3 style="-moz-border-radius-topleft: 0em;-moz-border-radius-topright: 0.7em;<br />
background:#cedff2;margin:-2px;padding:4px;"><br />
[[Image:favicon32.png|32px]] [[Hardware|Hardware]] <br />
</h3><br />
<div style="padding:6px;"><br />
{{Hardware}}<br />
</div><br />
<h3 style="-moz-border-radius-topleft: 0em;-moz-border-radius-topright: 0.7em; <br />
background:#cedff2;margin:-2px;padding:4px;"><br />
[[Image:favicon32.png|32px]] [[Software|Software]] <br />
</h3><br />
<div style="padding:6px;"><br />
{{Software}}<br />
</div><br />
<h3 style="-moz-border-radius-topleft: 0em;-moz-border-radius-topright: 0.7em;<br />
background:#cedff2;margin:-2px;padding:4px;"><br />
[[Image:favicon32.png|32px]] [[Miscellaneous|Miscellaneous]] <br />
</h3><br />
<div style="padding:6px;"><br />
{{Miscellaneous}}<br />
</div><br />
<!-- Start of right-column --><br />
| class="MainPageBG" style="width:70%;border:1px solid #cedff2;background-color:#f5faff;vertical-align:top"|<br />
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#f5fffa"<br />
|-valign="top"<br />
| <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">The Paparazzi Project</h2><br />
|-<br />
|style="color:#000"|[http://www.nongnu.org/paparazzi/ Paparazzi] is a free and open-source hardware and software project intended to create an exceptionally powerful and versatile autopilot system for fixedwing aircrafts as well as multicopters by allowing and encouraging input from the community. The project includes not only the airborne hardware and software, from voltage regulators and GPS receivers to [http://en.wikipedia.org/wiki/Kalman_filtering Kalman filtering] code, but also a powerful and ever-expanding array of ground hardware and software including modems, antennas, and a highly evolved user-friendly ground control software interface.<br />
|-<br />
|All hardware and software is open-source and freely available to anyone under the [http://www.gnu.org GNU] licencing agreement. [[Get_Hardware| Several vendors]] are currently producing and selling Paparazzi autopilots and popular accessories, making the system easy and affordable to all.<br />
|-<br />
|The key feature of the paparazzi autopilot is its unique combination of infrared thermopiles and inertial measurement for attitude sensing, providing a robust and accurate attitude estimate that requires no ground calibration and can recover from any launch attitude.<br />
|-<br />
| <h2 style="margin:0;background-color:#cef2e0;font-size:120%;font-weight:bold;border:1px solid #a3bfb1;text-align:left;color:#000;padding:0.2em 0.4em;">The Paparazzi project at ENAC</h2><br />
|-<br />
|The Paparazzi [http://en.wikipedia.org/wiki/Unmanned_Aircraft_System UAS] project is now being used and developed at [http://www.enac.fr/ ENAC University].<br />
|-<br />
|style="color:#000"|<br />
* [http://paparazzi.enac.fr/debian/ Debian repository] and [http://paparazzi.enac.fr/ubuntu/ Ubuntu repository] containing some packages not in the official distribution and required to run Paparazzi.<br />
<br />
<br />
'''Here it is proposed to discuss future paparazzi logo and style development'''<br />
[[Logo|http://paparazzi.enac.fr/wiki/Logo]]<br />
|}<br />
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#faf5ff;border:1px solid #ddcef2; text-align: justify;"<br />
| <h2 style="margin:0;background-color:#ddcef2;font-size:120%;font-weight:bold;border:1px solid #afa3bf;text-align:left;color:#000;padding:0.2em 0.4em;">News</h2><br />
<br />
|-<br />
|<h3>December 26th, 2011</h3><br />
|-<br />
|[[Image:28C3_logo.png|thumb|left|Paparazzi at 28C3]]<br />
<br />
If anyone of you is planning to come to the [http://events.ccc.de/congress/2011/wiki/Welcome 28C3] we have a table on the upper floor and will be very glad if you come by and say hi!<br />
<br />
|-<br />
|<h3>December 25th, 2011</h3><br />
|-<br />
|[[Image:Cre187-paparazzi.png|thumb|left|CRE187 - Paparazzi]]<br />
<br />
Martin Müller gave a great interview about the history and the inner workings of Paparazzi on [http://cre.fm/cre187 CRE Podcast].<br />
<br />
|-<br />
|<h3>October 5th, 2011</h3><br />
|-<br />
|[[Image:Umarim_v1-0_bottom_side.jpg|thumb|left|Umarim v1.0]]<br />
<br />
ENAC Team [http://paparazzi.enac.fr/wiki/Umarim_v10 Umarim V1.0 autopilot] is now released: LPC based, on-board IMU & barometer, narrow fuselage form factor (56x25mm) and lightweight (9gr) are its main features. Add your favorite GPS receiver and it will fit in your stupidly thin light UAV prototype. But it will also do the job for a big fat one. [http://paparazzi.enac.fr/wiki/Umarim_v10 More info here...]<br />
<br />
|-<br />
|<h3>September 18th, 2011</h3><br />
|-<br />
|[[Image:enac_imav11_1.jpg|thumb|left|IMAV 2011 Outdoor Competition ]]<br />
<br />
This year [http://www.imav2011.org/ IMAV 2011] went really well for all of the participants, we have seen lots of successful flights. ENAC Paparazzi Team took the 2nd place in general "Outdoor Challenge" and [http://paparazzi.enac.fr/wiki/Fire-Storm Fire Storm] demonstrated 105+ minutes of flight and took the "Best Outdoor Endurance Award". He was waiting this day for 2 years since the cancelation of IMAV09. <br />
As an additional information, Fire Storm flew its endurance mission with the new [http://paparazzi.enac.fr/wiki/Umarim_v10 Umarim V1.0] autopilot board which will be released soon.<br />
<br />
|-<br />
|<h3>August 31st, 2011</h3><br />
|-<br />
|[[Image:Quadshot_picture.jpg|thumb|left|The Quadshot]]<br />
<br />
Paparazzi is used in the [http://thequadshot.com Quadshot]: A blend between a quadrocopter and a flying wing. The Quadshot and Paparazzi are also featured in an [http://revision3.com/hak5/backtothestudio episode of Hak5]. You can also skip directly to the [http://www.youtube.com/watch?v=YeP7MMnP33g interview with Piotr] talking about how Paparazzi is used in the Quadshot, and briefly [http://www.youtube.com/watch?v=ANPX3UwRMnw explains the XML airframe file and the GCS].<br />
<br />
|-<br />
|<h3>February 15th, 2011</h3><br />
|-<br />
|[[Image:Finnarp.jpg|thumb|left|Paparazzi in Antarctica]]<br />
<br />
Paparazzi has flown on the southernmost continent: Antarctica. Scientists from the [http://en.ilmatieteenlaitos.fi/press-release/127535 Finnish Meteorological Institute] took three modified Funjets to the Finnish Aboa station and brought them back safely after more than 25 flights. They measured temperature, humidity, pressure, wind direction and speed in altitudes up to 1000m.<br />
<br />
|-<br />
|<h3>February 10th, 2011</h3><br />
|-<br />
|[[Image:ScreenShot.jpg|thumb|left|Paparazzi on OS X]]<br />
<br />
Paparazzi now on OS X. Thanks to the tireless efforts of Eric and Bernard we can all run [http://paparazzi.enac.fr/wiki/InstallationMacOSX Paparazzi on OS X]. Stay tuned Windows fans. Paparazzi on Windows is coming soon.<br />
<br />
|-<br />
|<h3>November 26th, 2010</h3><br />
|-<br />
|[[Image:Wingdrop.png|thumb|left|[http://www.youtube.com/watch?v=TFrognLZ2Ak wingdrop]]]<br />
<br />
There is a [http://www.youtube.com/watch?v=TFrognLZ2Ak video] available that shows how Paparazzis adaptive control loops keep a Twinstar in the air that drops 30% of its right wing with 50% of the aileron and then also switches the right engine off. Another [http://www.youtube.com/watch?v=N0H9xWckeYQ video] shows a Paparazzi quadcopter using adaptive control to stay level after dropping 50% of its total weight.<br />
<br />
|-<br />
<br />
|-<br />
|<h3>November 19th, 2010</h3><br />
|-<br />
|[[Image:Github.png|thumb|left|[[Git]]]]<br />
'''WE MOVED TO GIT!'''<br />
<br />
The paparazzi software repository now has a new happy life on github:<br />
<br />
'''https://github.com/paparazzi/paparazzi'''<br />
<br />
We believe the switch from Subversion to the fast [http://git-scm.com/ git] version control system will make development easier, faster and more fun. It also makes it easier for YOU to contribute. You can easily fork paparazzi on github, commit your bugfixes and new features and send us a pull request.<br />
<br />
More info on how to get the paparazzi code from github can be found [[Git|here]].<br />
<br />
We also want to encourage you to submit bugs or feature requests on the simple [https://github.com/paparazzi/paparazzi/issues github issue tracker].<br />
<br />
|<br />
|-<br />
<br />
<br />
|-<br />
|<h3>August, 2010</h3><br />
|-<br />
|[[Image:OrganizedCode.png|thumb|left|[[User/AirborneCodeReorg|Code Reorganization]]]]<br />
After many years of development, so many new autopilot boards and aircraft types have been added that a [http://en.wikipedia.org/wiki/Source_code sourcecode] reorganization was needed. This undertaking is started and will simplify the continuous evolution of the project.<br />
<br />
To benefit from these important changes, it only requires you to update your airframe configuration document once. After you have updated, you should not notice the significant reorganization that is going on behind the scenes. This change will benefit your aircrafts flying successfully for the years to come. The required changes are described on [[User/AirborneCodeReorg| Update Your Airframe Configuration]]. <br />
<br />
At this point several developments are blocked because of this. Therefor we kindly request you to upgrade your airframe configuration documents as soon as possible and thank you in advance for doing so.<br />
<br />
|<br />
|-<br />
<br />
<br />
|-<br />
|<h3>May 22th, 2010</h3><br />
|-<br />
|[[Image:PascalTPS.jpg|thumb|left|[[Hecto| Pascal Brisset]]]]<br />
Pascal Brisset, also known as Hecto, and the father of the Paparazzi project died in an accident while climbing in the Pyrénées mountains in the south of France.<br />
He had dedicated the last seven years of his life to the success of the project. He was taking care by himself of a huge part of the project. To name only a few : development and maintenance of the entire ground segment, navigation and flight plan algorithms, code generation and build system, distribution packaging, server infrastructure...<br />
<br />
To express your grief, you may want to [[Hecto| leave a note on his wiki page]]<br />
<br />
In respect for his commitment, the Paparazzi project must go on and volunteers wanting to take over tasks are hereby asked to do so.<br />
<br />
|<br />
|-<br />
<br />
<br />
|-<br />
<br />
|<h3>February 19th, 2010</h3><br />
|-<br />
|[[Image:Adler_c.jpg|thumb|left|[[Adler_Uni_Stuttgart| The 'Stuttgarter Adler']]]]<br />
The [http://www.irs.uni-stuttgart.de Institute of space systems] of [http://www.uni-stuttgart.de/index.en.html University of Stuttgart] is using the paparazzi system for large remote sensing aircrafts.<br> <br />
The missions include basic research and environmental monitoring. Payloads of up to 7kg are carried.<br><br><br />
More information can be found on the [[Adler_Uni_Stuttgart|Wiki page]].<br />
|<br />
|-<br />
<br />
<br />
|-<br />
<br />
<br />
|<h3>September 30th, 2009</h3><br />
|-<br />
|[[Image:picture-127.jpg|thumb|left|[[Look mAh, No Hands Aircraft]]]][[Image:picture-140.jpg|thumb|left|[[Look mAh, No Hands Team]]]]<br />
Paparazzi was a big success at the 2009 UAV Outback Challenge held at Kingaroy Airport, Queensland, Australia, Sep. 28-30.<br />
Team "Look mAh, no hands!" representing Brisbane Grammar School, won the 'Robot Airborne Delivery Challenge' placing 1st, after performing an autonomous mission phase including autonomous payload release. The team consisted of four members in their senior years of high-school, and was led by team captain Ben Paratz.<br />
Many thanks to the paparazzi community, not only for the autopilot itself but for the assistance that was enthusiastically given whenever needed.<br />
[http://www.uavoutbackchallenge.com.au Link to competition]<br />
|<br />
|-<br />
<br />
<br />
|-<br />
<br />
|<h3>September 24th, 2009</h3><br />
|-<br />
|[[Image:FireStorm.jpg|thumb|left|[[Fire-Storm]]]][[Image:SolarStorm1.jpg|thumb|left|[[Solar-Storm]]]]<br />
EMAV09 has already passed, now it is time to reveal our ([http://www.enac.fr/ ENAC]-[http://www.isae.fr/ ISAE]) new designs:<br />
* [[Fire-Storm]] a 50cm wingspan MAV.<br />
* [[Solar-Storm]] a 50cm wingspan MAV with hybrid power supply (solar and batteries).<br />
|<br />
|-<br />
<br />
<br />
|-<br />
|<h3>June 20th, 2009</h3><br />
The [http://www.engr.usu.edu/wiki/index.php/OSAM USU-OSAM] Paparazzi team won the 1st place in the 7th AUVSI (Association for Unmanned Vehicle Systems International) Student Unmanned Aircraft System Competition (18 teams total). The competition was held at Webster Field, Maryland, Jun. 17-20. The honor also goes to all the Paparazzi community, especially the developers.<br />
<br><br />
[http://www.navair.navy.mil/pma263/seafarers/default.htm Link to competition]<br />
|-<br />
<br />
|-<br />
|<h3>June 19th, 2009</h3><br />
|-<br />
|[[Image:B777-200LR_Frontview_Paris_2005.JPG|thumb|left]]<br />
The Paparazzi System has been shown at [http://www.paris-air-show.com/ Paris Le Bourget Airshow] by three companies:<br />
* [http://www.fly-n-sense.com/ Fly-n-Sense] with products [http://fly-n-sense.com/index.php?option=com_content&view=article&id=5&Itemid=5&lang=fr FNS900-Seeker and ScanCopter CB500].<br />
* [http://www.sudouest.com/gironde/actualite/rive-gauche/article/619946/mil/4659234.html AeroArt] with the [http://www.aeroart.eu/produits/page28/page28.html plume project] with the support of Fly-n-Sense.<br />
* [http://www.thalesgroup.com/Press_Releases/Thales_at_the_International_Paris_Air_Show_2009/ Thales] with the [http://newton.ee.auth.gr/aerial_space/docs/CS_4.pdf Spy'Arrow] MAV.<br />
|-<br />
|<h3>May 26th, 2009</h3><br />
|-<br />
|[[Image:QuadAstec.JPG|thumb|left|]] ENAC / Paparazzi has won the [http://www.minidrones.fr/ ONERA-DGA Challenge] with a quadrotor. Twelve teams of French Universities out of 19 were chosen by ONERA-DGA to participate to this two years contest. ENAC designed a Paparazzi equipped [http://www.asctec.de/main/index.php Asctec] quadrotor with an [[Inertial Measurement Units|IMU]] developed in its lab.<br />
|-<br />
|<h3>April 7th, 2009</h3><br />
|-<br />
| style="color:#000"| [[Image:emav09.jpg|thumb|left|]] <br />
Dear Paparazzi's, the registration for EMAV09 is now open at [http://www.emav09.org/ http://www.emav09.org/]. We look forward to meeting many paparazzi teams at this yearly event.<br />
|-<br />
<br />
|<h3>March 24, 2009</h3><br />
|-<br />
| style="color:#000"| [[Image:Adventalen.jpg|thumb|left|Funjet launch on Spitsbergen]] <br />
We were back in the Arctic flying Paparazzi aircrafts on Svalbard (N78° E15°) doing research with the Geophysical Institute of the University of Bergen/Norway. There are two teams operating near Longyearbyen, one on the apron of Longyearbyen airport (LYR) and the other at the old northern lights research station in Adventdalen. We had permission to fly up to 1500m outside the airport opening times. The Paparazzi aircrafts work perfectly...for humans it is just a little cold. Last night we flew having -32°C (-25°F) on the ground. There is a [http://www.youtube.com/watch?v=M1k_TLcQ2ic video] showing a 1500m vertical profile flight. <br />
|-<br />
<br />
|<h3>February 16th, 2009</h3><br />
|-<br />
| We have a new forum to talk about this project. Please visit and participate http://www.azoreanuav.com/forum . Please, vote in the next link to continue with the forum or not. http://www.azoreanuav.com/forum/viewtopic.php?f=2&t=7 <br />
|-<br />
<br />
|-<br />
|<h3>February 9th, 2009</h3><br />
|-<br />
| 3 ENAC students have released a Graphical control application for Paparazzi on Mobile phone using Java technoligies. Check the [[Ipodrom]] project page for more details.<br />
|-<br />
<br />
|<h3>January 19, 2009</h3><br />
|-<br />
| style="color:#000"|<br />
Paparazzi Developers,<br><br />
This is to announce a Call for Papers for the 2009 ASME/IEEE International Conference on Mechatronic and Embedded Systems and Applications (MESA09), part of ASME IDETC09. The conference is to be held August 30 - September 2, 2009 at San Diego Convention Center. This Call for Papers is specific to the Session chaired by myself, Antoine Drouin , and Anton Kochevar. This topic of this session is " Open Source UAV Autopilots: Status and Progression", part of a symposium of MESA09 called "Small Unmanned Aerial Vehicle Technologies and Applications (SUAVTA)". This Technical Session is meant to be a session that will focus on Paparazzi, the topics can include specific features developed for Paparazzi or applications using Paparazzi along with other innovative aspects or uses of Paparazzi. We hope to make this one of the largest and best conferences dealing with Paparazzi. Please help us to promote Paparazzi and bring this amazing project to even more people. Full paper deadline is Feb. 27, 2009 using the online submission system.<br />
<br />
Conference Website: https://www.asmeconferences.org/IDETC09/ (click MESA09, then, UAV Symposium, then this dedicated session) or http://iel.ucdavis.edu/mesa/MESA09/<br />
<br />
If you have any further questions please email me at<br />
daniel.morgan @ aggiemail.usu.edu (remove spaces)<br />
Research Associate, Center for Self-Organizing and Intelligent Systems at Utah State University<br />
http://www.engr.usu.edu/wiki/index.php/User:CSOIS <br />
<br><br />
|-<br />
|<h3>September 23, 2008</h3><br />
|-<br />
| style="color:#000"| [[Image:motodrone_08u.JPG|thumb|left]]<br />
A paparazzi team took part in the [http://motodrone.org/ Motodrone] event held in Finowfurt near Berlin.<br><br />
It was fun, the beer was cool and barbecues worked flawlessly. And we flew funjets...<br />
<br><br />
[http://berlinvr.info/motodrone2008.html Video]<br />
<br />
|-<br />
|<h3>June 23, 2008</h3><br />
|-<br />
| style="color:#000"| [[Image:Targets auvsi 08.JPG|thumb|left]] <br />
The [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi team took 2nd place in the Sixth Annual Student Unmanned Aerial Systems Competition! The event is sponsored by AUVSI (Association for Unmanned Vehicle Systems International) and was held at Webster Field, St. Inigoes, Maryland. It should also be noted that this was Paparazzi's and the OSAM Paparazzi team's first time at the competition.<br><br />
[http://www.navair.navy.mil/pma263/seafarers/default.htm Link to competition]<br />
<br><br />
[http://www.navair.navy.mil/pma263/seafarers/video/video08.html Highlight Video of Competition] <br />
<br />
|-<br />
|<h3>June 13, 2008</h3><br />
|-<br />
| style="color:#000"| [[Image:Twog_v1-00_top_side_3.jpg|thumb|left|'''T'''iny '''W'''ith'''O'''ut '''G'''ps]] <br />
The new baby autopilot is born.<br><br />
His name is TWOG, he weighs 8 grams and is 40.2 x 30.5mm long. He' in good health and looks a lot like his mother Tiny v2, except for the GPS receiver.<br><br />
The proud parents invite you to visit the [[Twog_v1|pictures and technical information album]]...<br />
<br />
<br />
|-<br />
|<h3>March 26, 2008</h3><br />
|-<br />
| style="color:#000"| [[Image:Heli_deck.jpg|thumb|left|Funjet on the helicopter deck]] <br />
Scientists from the [http://web.gfi.uib.no/index_e.html Geophysical Institute of the University of Bergen/Norway] flew Paparazzi controlled [[media:Funjet_spitsbergen.jpg|Funjet]] aircrafts equipped with meteorological sensors in the Arctic sea around Spitsbergen only with the help of a RC safety pilot and no Paparazzi team member nearby. They took off and landed on the helicopter deck of the Norwegian icebreaking coast guard vessel [http://www.jtashipphoto.dk/JTA-W303%20Svalbard.htm KV Svalbard] for one week and set a new Paparazzi low temperature record by flying at around -20°C and 15m/s wind in altitudes up to 1500m. For another two weeks they also collected data on Spitsbergen near Longyearbyen. See pictures in the gallery and a [http://www.youtube.com/watch?v=VWEa_4Hlm2s video].<br />
<br />
|-<br />
|<h3>March 15, 2008</h3><br />
|-<br />
| style="color:#000"| [[Image:Tiny_v2-1_3D_top.jpg|thumb|left|Tiny 2.11]]<br />
A number of vendors are now offering assembled and unassembled autopilots, sensors and accessories. The software is written, the hardware is built, what are you waiting for? Getting started has never been easier! More details on the [[Get_Hardware|Get Hardware]] page.<br />
<br />
|-<br />
|<h3>February 6, 2008</h3><br />
|-<br />
| style="color:#000"| [[Image:eeePC.jpg|thumb|left|Paparazzi running on eeePC]] <br />
Looking for a small, light and cheap ground station ? Paparazzi runs on the [http://eeepc.asus.com ASUS eeePC] out of the box (after installing the Debian Paparazzi packages). Tested on the pre-installed Xandros distribution, on a standard Ubuntu and on the preconfigured [http://wiki.eeeuser.com/ubuntu:eeexubuntu:home eeeXubuntu].<br />
<br />
|-<br />
|<h3>January 27, 2008</h3><br />
|-<br />
| style="color:#000"| [[Image:StormTV.jpg|thumb|left|Paparazzi's Storm on TV in Turkey]] [http://www.showtvnet.com/haber/playerd.asp?ptype=haber&product=/270108/ucak.wmv Storm on TV], A Paparazzi aircraft is featured on the biggest Television station in Turkey. (Sorry, the audio is only in Turkish...)<br />
<br />
|-<br />
|<h3>[[News Archives]]</h3><br />
|-<br />
| style="color:#000"|<br />
[[Image:One_Small_Step.jpg|thumb|left|[[News Archives]]]] [[News Archives|Browse the archives]] for a look back at the earlier days of Paparazzi.<br />
|-<br />
<br />
|}<br />
|}</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Logo&diff=11220Logo2011-12-26T20:17:49Z<p>P0rc0 r0ss0: </p>
<hr />
<div>This page is dedicated to Paparazzi "promotion". As soon as this project is marvelous in technical and social way, it seems logical to make it look shining. Not all of us can do electronics, or solder chips to help this project directly, but we all want/like/love to fly and every member of a project is a value.<br />
If there is a way you can help and want to, then do it and everybody will benefit.<br />
<br />
<br />
== New logo ==<br />
I wanted to propose new logo. I like the old one, but maybe this will do too, I'm no artist so it's just a sketch.<br />
[[Image:Paparazzi new logo.jpg]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Logo&diff=11219Logo2011-12-26T18:42:07Z<p>P0rc0 r0ss0: </p>
<hr />
<div>This page is dedicated to Paparazzi "promotion". As soon as this project is marvelous in technical and social way, it seems logical to make it look shining. Not all of us can do electronics, or solder chips to help this project directly, but we all want/like/love to fly and every member of a project is a value.<br />
<br />
== New logo ==<br />
I wanted to propose new logo. I like the old one, but maybe this will do too, I'm no artist so it's just a sketch.<br />
[[Image:Paparazzi new logo.jpg]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Logo&diff=11218Logo2011-12-26T18:41:50Z<p>P0rc0 r0ss0: /* New logo */</p>
<hr />
<div>= Logo =<br />
This page is dedicated to Paparazzi "promotion". As soon as this project is marvelous in technical and social way, it seems logical to make it look shining. Not all of us can do electronics, or solder chips to help this project directly, but we all want/like/love to fly and every member of a project is a value.<br />
<br />
== New logo ==<br />
I wanted to propose new logo. I like the old one, but maybe this will do too, I'm no artist so it's just a sketch.<br />
[[Image:Paparazzi new logo.jpg]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=File:Porcorosso_paparazzi_logo_proposal.jpg&diff=11217File:Porcorosso paparazzi logo proposal.jpg2011-12-26T18:41:22Z<p>P0rc0 r0ss0: </p>
<hr />
<div></div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Logo&diff=11216Logo2011-12-26T18:40:19Z<p>P0rc0 r0ss0: </p>
<hr />
<div>= Logo =<br />
This page is dedicated to Paparazzi "promotion". As soon as this project is marvelous in technical and social way, it seems logical to make it look shining. Not all of us can do electronics, or solder chips to help this project directly, but we all want/like/love to fly and every member of a project is a value.<br />
<br />
== New logo ==<br />
I wanted to propose new logo. I like the old one, but maybe this will do too, I'm no artist so it's just a sketch.<br />
[[Image:Example.jpg]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Logo&diff=11215Logo2011-12-26T18:33:30Z<p>P0rc0 r0ss0: </p>
<hr />
<div>= Logo =<br />
This page is dedicated to Paparazzi "promotion". As soon as this project is marvelous in technical and social way, it seems logical to make it look shining. Not all of us can do electronics, or solder chips to help this project directly, but we all want/like/love to fly and every member of a project is a value.</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Telemetry&diff=11124Telemetry2011-12-18T11:28:59Z<p>P0rc0 r0ss0: /* GPS_SOL */</p>
<hr />
<div>== Messages ==<br />
The set of periodic messages sent over the downlink channel by an aircraft to the ground station is configurable<br />
with the help of one XML file, located in the <tt>conf/telemetry</tt> directory. This file is called by <tt>conf/conf.xml</tt> and must follow the<br />
<tt>telemetry.dtd</tt> syntax. The <tt>default.xml</tt> is provided as an example and should be suitable for most users: (copy this file to your own file like Xbee.xml or aerocom.xml and load this in the telemetry part of the [[Paparazzi Center]] )<br />
<br />
<tt><!DOCTYPE telemetry SYSTEM "telemetry.dtd"><br />
<telemetry><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="ATTITUDE" period="0.5"/><br />
<message name="PPRZ_MODE" period="5"/><br />
<message name="SOME_MODULE_MSG" period="2" module="module_name"/><br />
...<br />
</mode><br />
<mode name="fast attitude"><br />
<message name="ATTITUDE" period="0.1"/><br />
</mode><br />
</process><br />
<process name="Fbw"><br />
<mode name="default"><br />
<message name="COMMANDS" period="1"/><br />
...<br />
</mode><br />
<mode name="debug"><br />
<message name="PPM" period="0.5"/><br />
</mode><br />
</process><br />
</telemetry></tt><br />
<br />
If a [[Modules|module]] attribute is specified for a message, it will be include in the telemetry only if the corresponding module is loaded.<br />
<br />
===Add Messages===<br />
<br />
When you want to add a new senor to Paparazzi and need the sensor data on the ground station do this: <br />
in this example we will add an airspeed message.<br />
<br />
in conf/messages.xml add an airspeed messages<br />
<br />
<message name="AIRSPEED" id="54"><br />
<field name="adc_airspeed" type="uint16"></field><br />
<field name="estimator_airspeed" type="float"></field><br />
<field name="airspeed_setpoint" type="float"></field><br />
<field name="airspeed_controlled" type="float"></field><br />
<field name="groundspeed_setpoint" type="float"></field><br />
</message><br />
<br />
id="54" has to be unique. ( in the console type in your paparazzi map ./sw/tools/find_free_msg_id.out to find a free ID. your Paparazzi source and home environment variables have to be set correctly in your shell [[Installation#Launching_the_Software]])<br />
every field is a variable from Paparazzi. The type have to be the type of the variable. (look it op in your code)<br />
<br />
now a DOWNLINK_SEND_AIRSPEED is made by the code<br />
<br />
<br />
in conf/telemetry/default.xml add your message an tel at with frequency it has to be send.<br />
<telemetry><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="ALIVE" period="5"/><br />
<message name="GPS" period="0.25"/><br />
<message name="AIRSPEED" period="1"/><br />
....<br />
<br />
now a PERIODIC_SEND_AIRSPEED is made by the code <br />
<br />
<br />
In ap_downlink.h add :<br />
<br />
#ifdef USE_AIRSPEED<br />
#define PERIODIC_SEND_AIRSPEED(_chan) DOWNLINK_SEND_AIRSPEED (_chan, &adc_airspeed_val,&estimator_airspeed,&v_ctl_auto_airspeed_setpoint,&v_ctl_auto_airspeed_controlled,&v_ctl_auto_groundspeed_setpoint)<br />
#else<br />
#define PERIODIC_SEND_AIRSPEED(_chan) {}<br />
#endif<br />
<br />
here you tell to replace all PERIODIC_SEND_AIRSPEED by DOWNLINK_SEND_AIRSPEED<br />
<br />
===Specific Messages===<br />
<br />
====GPS_SOL====<br />
Specification in telemetry file<br />
<message name="GPS_SOL" period="2.0"/><br />
Example from logfile(.data):<br />
6.742 1 GPS_SOL 232 43 198 8<br />
<br />
Meaning of tokens:<br />
Timestamp, Aircraft-Number, GPS_SOL, Pacc, Sacc, PDOP, numSV<br />
<br />
*Pacc = Position accuracy (units: CM)<br />
*Sacc = Speed accuracy (units: CM/sec ?)<br />
*PDOP = Position [http://en.wikipedia.org/wiki/Dilution_of_precision_%28GPS%29 Dilution_of_precision_(GPS)] , if this value is high the value of position will be less accurate<br />
*numSV = number of Space Vehicles (Satellites) used in Nav Solution<br />
<br />
====PPRZ_MODE====<br />
Specification in telemetry file<br />
<message name="PPRZ_MODE" period="5."/><br />
Example from logfile(.data):<br />
20.433 2 PPRZ_MODE 0 1 2 0 0 1<br />
<br />
Meaning of tokens:<br />
Timestamp, Aircraft-Number, PPRZ_MODE, ap_mode, ap_gaz, ap_horizontal, if_calib_mode, mcul_status<br />
*ap_mode = (0 = MANUAL, 1 = AUTO1, 2 = AUTO2, 3 = HOME mode (Circle Home waypoint), 4 = NO_GPS (GPS not working), 5 = NB (?)<br />
*ap_gaz = ?<br />
*ap_horizontal = ?<br />
*if_calib_mode = ?<br />
*mcul_status = ?<br />
<br />
===Configuring the Downlink Data Rate===<br />
<br />
The limited throughput of our RF modems results in a need to carefully choose which data to send, as well as the frequency at which to send it. A sophisticated set of files and parameters have been developed in order to tailor the data downlink behavior automatically, manually, temporarily, or permanently according to any desired parameter. This allows the user to create an almost unlimited possibility of downlink configurations. For example:<br />
* Tailor the data rate to work with very slow modems (9600 baud or slower)<br />
* Reduce the data rate of some messages so that others can be increased:<br />
*: Automatically send GPS data at a very high rate by sacrificing navigation data when not flying (to help GPS/RFI troubleshooting) then automatically reduce the GPS data rate and send normal navigation data when the launch is initiated.<br />
*: Automatically switch to sending only position data upon landing to conserve power and increase the chance of the operator receiving a position packet when recovering a distant aircraft.<br />
*: Manually send selected sensor data at very high speeds (60Hz) for real time tuning.<br />
* Maintain independent telemetry configurations for aircraft with different modems, sensors, or mission profiles.<br />
<br />
Any number of configuration files can be created in the <tt>conf/telemetry</tt> directory and selected from the <tt>conf/conf.xml</tt> file. The telemetry downlink is divided into two processes, '''Ap''' and '''Fbw''' each with a possible <tt>mode</tt> option. Any number of modes could be created, the default is the first in the sequence. A mode contains the list of messages to be sent as well as the period of each message in seconds. In this example, the '''ATTITUDE''' message will be sent by the '''Ap''' process at 2Hz in the default mode and at 10Hz in the '''fast attitude''' mode. The maximum allowed frequency is 60Hz (0.017s) and the maximum period is 1092s.<br />
<br />
The mode can be chosen in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant:<br />
<tt><define name="TELEMETRY_MODE_FBW" value="1"/></tt><br />
where the (default) first mode is numbered '''0'''.<br />
<br />
This mode can also be changed dynamically with a datalink [[#Settings|setting]] or with a [[Flight_Plans#set|set]] stage in the flight plan.<br />
<br />
Note that an (undocumented!) subset of the messages is required to be able to use ground station properly. So it is not advisable to completely remove messages for the '''Ap''' process listed in the default mode.<br />
<br />
== Settings ==<br />
<br />
The <tt>settings</tt> attribute in the description of the aircraft in <tt>conf.xml</tt> allows the user to specify a list of variables for which values can be changed in-flight:<br />
<tt><aircraft <br />
name="Microjet"<br />
...<br />
settings="settings/basic.xml"<br />
...<br />
/></tt><br />
<br />
with the <tt>basic.xml</tt> file located in <tt>conf/settings/</tt>. A <tt>dl_setting</tt> element in this file associates [[GCS#Settings|buttons or sliders in the GCS interface]] to autopilot variables:<br />
<tt><!DOCTYPE settings SYSTEM "settings.dtd"><br />
<settings><br />
<dl_settings><br />
<dl_settings NAME="flight params"><br />
<dl_setting MAX="1000" MIN="-50" STEP="10" VAR="altitude_shift"/><br />
</dl_settings><br />
<dl_settings NAME="mode"><br />
<dl_setting MAX="2" MIN="0" STEP="1" VAR="pprz_mode"><br />
<strip_button name="AUTO2" value="2"/><br />
</dl_setting><br />
<dl_setting MAX="1" MIN="0" STEP="1" VAR="launch"><br />
<strip_button name="Launch" value="1"/><br />
</dl_setting><br />
<dl_setting MAX="1" MIN="0" STEP="1" VAR="kill_throttle"/><br />
</dl_settings><br />
</dl_settings><br />
</settings></tt><br />
where <tt>dl_settings</tt> elements can be nested at any depth. A <tt>dl_setting</tt> element just specifies the name of the variable, the allowed range for the setting (<tt>min</tt> and <tt>max</tt> attributes) and the minimal <tt>step</tt>.<br />
<br />
A notebook page will be associated in the GUI to each <tt>dl_settings</tt> element. A slider will be associated to each <tt>dl_setting</tt> entry except if the range is small (typically less than 3) and discrete (step=1): in the latter case, a set of radio buttons will be displayed.<br />
<br />
The <tt>strip_button</tt> element adds a button to the [[GCS#Strip|GCS strip]] for commonly used tasks like "Launch" or "Circle". Multiple buttons can be used to assign different values to the same variable. If the attribute <tt>group</tt> is specified, all strip buttons of the same group will be placed vertically on top of each other.<br />
<br />
The <tt>param</tt> attribute of a <tt>dl_setting</tt> element allows to specify the corresponding parameter in the airframe file in order to save a tuned value:<br />
<tt><dl_setting max="0.3" min="-0.3" step="0.01" var="ir_roll_neutral" param="IR_ROLL_NEUTRAL_DEFAULT" unit="rad"/></tt><br />
where the <tt>unit</tt> attribute is required for the parameters which do not use the same unit than the corresponding variable (currently only for some angle parameters in degrees in the airframe file and in radians for the variable).<br />
<br />
== R/C Transmitter Data Uplink ==<br />
<br />
With the advent of small modems such as the popular Zigbee-based models, the usage of the R/C transmitter as a simple data-link is substantially less. Nevertheless, this feature may still prove useful for extremely minimal hardware configurations. Also '''very''' useful for tuning of some parameters that are best adjusted by the pilot while flying, such as IR pile neutral settings. While a laptop in the field may be the best for most part of the tuning for sometimes it is more convenient from the transmitter directly. For this it is best to have little more advanced transmitter. For example a Graupner JR MX-22 or alike. On these transmitter there are controls that are good for up and down setting <br />
<br />
[[Image:Ap_calib_sliders_via_rc.jpg|thumb|right|Use these up/down buttons for realtime tuning]]<br />
<br />
The <tt>tuning_rc.xml</tt> file is located in <tt>conf/settings</tt>.<br />
<tt><aircraft <br />
name="Microjet"<br />
...<br />
settings="settings/tuning_rc.xml"<br />
...<br />
/></tt><br />
A <tt>rc_settings</tt> element in this file associates switches and sliders of the RC to airborne variables:<br />
<tt><!DOCTYPE settings SYSTEM "settings.dtd"><br />
<!-- A conf to use to tune an A/C using only the rc --><br />
<settings><br />
<rc_settings><br />
<rc_mode NAME="AUTO1"><br />
<rc_setting VAR="ir_pitch_neutral" RANGE="2" RC="gain_1_up" TYPE="float"/><br />
<rc_setting VAR="ir_roll_neutral" RANGE="-2" RC="gain_1_down" TYPE="float"/><br />
</rc_mode><br />
<rc_mode NAME="AUTO2"><br />
<rc_setting VAR="course_pgain" RANGE="0.1" RC="gain_1_up" TYPE="float"/><br />
<rc_setting VAR="pitch_of_roll" RANGE=".2" RC="gain_1_down" TYPE="float"/><br />
</rc_mode><br />
</rc_settings><br />
</settings></tt><br />
First, settings are sorted by mode (<tt>AUTO1</tt> or <tt>AUTO2</tt>). Then a setting is composed of a <tt>var</tt>iable name, a <tt>range</tt> (corresponding to the range of the RC slider) and a <tt>RC</tt> name. The RC name prefix can be ''gain_1'' or ''gain_2'', which corresponds to the <tt>GAIN1</tt> and <tt>GAIN2</tt> channels of your RC transmitter [[Radio_Control|configuration]]. The RC name suffix can be ''up'' or ''down'', which is related to the position of the <tt>CALIB</tt> switch on the RC transmitter.<br />
<br />
== Audio-based downlink ==<br />
<br />
The audio-based downlink has been removed from current hardware designs however using the old designs it is possible to implement. With the current low prices of a simple video transmitter, data over audio may come in as a welcomed addition. Feel free to experiment and revive this classical feature.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]] [[Category:Telemetry]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Telemetry&diff=11123Telemetry2011-12-18T11:25:44Z<p>P0rc0 r0ss0: /* Add Messages */</p>
<hr />
<div>== Messages ==<br />
The set of periodic messages sent over the downlink channel by an aircraft to the ground station is configurable<br />
with the help of one XML file, located in the <tt>conf/telemetry</tt> directory. This file is called by <tt>conf/conf.xml</tt> and must follow the<br />
<tt>telemetry.dtd</tt> syntax. The <tt>default.xml</tt> is provided as an example and should be suitable for most users: (copy this file to your own file like Xbee.xml or aerocom.xml and load this in the telemetry part of the [[Paparazzi Center]] )<br />
<br />
<tt><!DOCTYPE telemetry SYSTEM "telemetry.dtd"><br />
<telemetry><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="ATTITUDE" period="0.5"/><br />
<message name="PPRZ_MODE" period="5"/><br />
<message name="SOME_MODULE_MSG" period="2" module="module_name"/><br />
...<br />
</mode><br />
<mode name="fast attitude"><br />
<message name="ATTITUDE" period="0.1"/><br />
</mode><br />
</process><br />
<process name="Fbw"><br />
<mode name="default"><br />
<message name="COMMANDS" period="1"/><br />
...<br />
</mode><br />
<mode name="debug"><br />
<message name="PPM" period="0.5"/><br />
</mode><br />
</process><br />
</telemetry></tt><br />
<br />
If a [[Modules|module]] attribute is specified for a message, it will be include in the telemetry only if the corresponding module is loaded.<br />
<br />
===Add Messages===<br />
<br />
When you want to add a new senor to Paparazzi and need the sensor data on the ground station do this: <br />
in this example we will add an airspeed message.<br />
<br />
in conf/messages.xml add an airspeed messages<br />
<br />
<message name="AIRSPEED" id="54"><br />
<field name="adc_airspeed" type="uint16"></field><br />
<field name="estimator_airspeed" type="float"></field><br />
<field name="airspeed_setpoint" type="float"></field><br />
<field name="airspeed_controlled" type="float"></field><br />
<field name="groundspeed_setpoint" type="float"></field><br />
</message><br />
<br />
id="54" has to be unique. ( in the console type in your paparazzi map ./sw/tools/find_free_msg_id.out to find a free ID. your Paparazzi source and home environment variables have to be set correctly in your shell [[Installation#Launching_the_Software]])<br />
every field is a variable from Paparazzi. The type have to be the type of the variable. (look it op in your code)<br />
<br />
now a DOWNLINK_SEND_AIRSPEED is made by the code<br />
<br />
<br />
in conf/telemetry/default.xml add your message an tel at with frequency it has to be send.<br />
<telemetry><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="ALIVE" period="5"/><br />
<message name="GPS" period="0.25"/><br />
<message name="AIRSPEED" period="1"/><br />
....<br />
<br />
now a PERIODIC_SEND_AIRSPEED is made by the code <br />
<br />
<br />
In ap_downlink.h add :<br />
<br />
#ifdef USE_AIRSPEED<br />
#define PERIODIC_SEND_AIRSPEED(_chan) DOWNLINK_SEND_AIRSPEED (_chan, &adc_airspeed_val,&estimator_airspeed,&v_ctl_auto_airspeed_setpoint,&v_ctl_auto_airspeed_controlled,&v_ctl_auto_groundspeed_setpoint)<br />
#else<br />
#define PERIODIC_SEND_AIRSPEED(_chan) {}<br />
#endif<br />
<br />
here you tell to replace all PERIODIC_SEND_AIRSPEED by DOWNLINK_SEND_AIRSPEED<br />
<br />
===Specific Messages===<br />
<br />
====GPS_SOL====<br />
Specification in telemetry file<br />
<message name="GPS_SOL" period="2.0"/><br />
Example from logfile(.data):<br />
6.742 1 GPS_SOL 232 43 198 8<br />
<br />
Meaning of tokens:<br />
Timestamp, Aircraft-Number, GPS_SOL, Pacc, Sacc, PDOP, numSV<br />
<br />
*Pacc = Position accuracy (units: CM)<br />
*Sacc = Speed accuracy (units: CM/sec ?)<br />
*PDOP = Position [http://en.wikipedia.org/wiki/Dilution_of_precision_%28GPS%29 Dilution of Precision] , if this value is high the value of position will be less accurate<br />
*numSV = number of Space Vehicles (Satellites) used in Nav Solution<br />
<br />
====PPRZ_MODE====<br />
Specification in telemetry file<br />
<message name="PPRZ_MODE" period="5."/><br />
Example from logfile(.data):<br />
20.433 2 PPRZ_MODE 0 1 2 0 0 1<br />
<br />
Meaning of tokens:<br />
Timestamp, Aircraft-Number, PPRZ_MODE, ap_mode, ap_gaz, ap_horizontal, if_calib_mode, mcul_status<br />
*ap_mode = (0 = MANUAL, 1 = AUTO1, 2 = AUTO2, 3 = HOME mode (Circle Home waypoint), 4 = NO_GPS (GPS not working), 5 = NB (?)<br />
*ap_gaz = ?<br />
*ap_horizontal = ?<br />
*if_calib_mode = ?<br />
*mcul_status = ?<br />
<br />
===Configuring the Downlink Data Rate===<br />
<br />
The limited throughput of our RF modems results in a need to carefully choose which data to send, as well as the frequency at which to send it. A sophisticated set of files and parameters have been developed in order to tailor the data downlink behavior automatically, manually, temporarily, or permanently according to any desired parameter. This allows the user to create an almost unlimited possibility of downlink configurations. For example:<br />
* Tailor the data rate to work with very slow modems (9600 baud or slower)<br />
* Reduce the data rate of some messages so that others can be increased:<br />
*: Automatically send GPS data at a very high rate by sacrificing navigation data when not flying (to help GPS/RFI troubleshooting) then automatically reduce the GPS data rate and send normal navigation data when the launch is initiated.<br />
*: Automatically switch to sending only position data upon landing to conserve power and increase the chance of the operator receiving a position packet when recovering a distant aircraft.<br />
*: Manually send selected sensor data at very high speeds (60Hz) for real time tuning.<br />
* Maintain independent telemetry configurations for aircraft with different modems, sensors, or mission profiles.<br />
<br />
Any number of configuration files can be created in the <tt>conf/telemetry</tt> directory and selected from the <tt>conf/conf.xml</tt> file. The telemetry downlink is divided into two processes, '''Ap''' and '''Fbw''' each with a possible <tt>mode</tt> option. Any number of modes could be created, the default is the first in the sequence. A mode contains the list of messages to be sent as well as the period of each message in seconds. In this example, the '''ATTITUDE''' message will be sent by the '''Ap''' process at 2Hz in the default mode and at 10Hz in the '''fast attitude''' mode. The maximum allowed frequency is 60Hz (0.017s) and the maximum period is 1092s.<br />
<br />
The mode can be chosen in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant:<br />
<tt><define name="TELEMETRY_MODE_FBW" value="1"/></tt><br />
where the (default) first mode is numbered '''0'''.<br />
<br />
This mode can also be changed dynamically with a datalink [[#Settings|setting]] or with a [[Flight_Plans#set|set]] stage in the flight plan.<br />
<br />
Note that an (undocumented!) subset of the messages is required to be able to use ground station properly. So it is not advisable to completely remove messages for the '''Ap''' process listed in the default mode.<br />
<br />
== Settings ==<br />
<br />
The <tt>settings</tt> attribute in the description of the aircraft in <tt>conf.xml</tt> allows the user to specify a list of variables for which values can be changed in-flight:<br />
<tt><aircraft <br />
name="Microjet"<br />
...<br />
settings="settings/basic.xml"<br />
...<br />
/></tt><br />
<br />
with the <tt>basic.xml</tt> file located in <tt>conf/settings/</tt>. A <tt>dl_setting</tt> element in this file associates [[GCS#Settings|buttons or sliders in the GCS interface]] to autopilot variables:<br />
<tt><!DOCTYPE settings SYSTEM "settings.dtd"><br />
<settings><br />
<dl_settings><br />
<dl_settings NAME="flight params"><br />
<dl_setting MAX="1000" MIN="-50" STEP="10" VAR="altitude_shift"/><br />
</dl_settings><br />
<dl_settings NAME="mode"><br />
<dl_setting MAX="2" MIN="0" STEP="1" VAR="pprz_mode"><br />
<strip_button name="AUTO2" value="2"/><br />
</dl_setting><br />
<dl_setting MAX="1" MIN="0" STEP="1" VAR="launch"><br />
<strip_button name="Launch" value="1"/><br />
</dl_setting><br />
<dl_setting MAX="1" MIN="0" STEP="1" VAR="kill_throttle"/><br />
</dl_settings><br />
</dl_settings><br />
</settings></tt><br />
where <tt>dl_settings</tt> elements can be nested at any depth. A <tt>dl_setting</tt> element just specifies the name of the variable, the allowed range for the setting (<tt>min</tt> and <tt>max</tt> attributes) and the minimal <tt>step</tt>.<br />
<br />
A notebook page will be associated in the GUI to each <tt>dl_settings</tt> element. A slider will be associated to each <tt>dl_setting</tt> entry except if the range is small (typically less than 3) and discrete (step=1): in the latter case, a set of radio buttons will be displayed.<br />
<br />
The <tt>strip_button</tt> element adds a button to the [[GCS#Strip|GCS strip]] for commonly used tasks like "Launch" or "Circle". Multiple buttons can be used to assign different values to the same variable. If the attribute <tt>group</tt> is specified, all strip buttons of the same group will be placed vertically on top of each other.<br />
<br />
The <tt>param</tt> attribute of a <tt>dl_setting</tt> element allows to specify the corresponding parameter in the airframe file in order to save a tuned value:<br />
<tt><dl_setting max="0.3" min="-0.3" step="0.01" var="ir_roll_neutral" param="IR_ROLL_NEUTRAL_DEFAULT" unit="rad"/></tt><br />
where the <tt>unit</tt> attribute is required for the parameters which do not use the same unit than the corresponding variable (currently only for some angle parameters in degrees in the airframe file and in radians for the variable).<br />
<br />
== R/C Transmitter Data Uplink ==<br />
<br />
With the advent of small modems such as the popular Zigbee-based models, the usage of the R/C transmitter as a simple data-link is substantially less. Nevertheless, this feature may still prove useful for extremely minimal hardware configurations. Also '''very''' useful for tuning of some parameters that are best adjusted by the pilot while flying, such as IR pile neutral settings. While a laptop in the field may be the best for most part of the tuning for sometimes it is more convenient from the transmitter directly. For this it is best to have little more advanced transmitter. For example a Graupner JR MX-22 or alike. On these transmitter there are controls that are good for up and down setting <br />
<br />
[[Image:Ap_calib_sliders_via_rc.jpg|thumb|right|Use these up/down buttons for realtime tuning]]<br />
<br />
The <tt>tuning_rc.xml</tt> file is located in <tt>conf/settings</tt>.<br />
<tt><aircraft <br />
name="Microjet"<br />
...<br />
settings="settings/tuning_rc.xml"<br />
...<br />
/></tt><br />
A <tt>rc_settings</tt> element in this file associates switches and sliders of the RC to airborne variables:<br />
<tt><!DOCTYPE settings SYSTEM "settings.dtd"><br />
<!-- A conf to use to tune an A/C using only the rc --><br />
<settings><br />
<rc_settings><br />
<rc_mode NAME="AUTO1"><br />
<rc_setting VAR="ir_pitch_neutral" RANGE="2" RC="gain_1_up" TYPE="float"/><br />
<rc_setting VAR="ir_roll_neutral" RANGE="-2" RC="gain_1_down" TYPE="float"/><br />
</rc_mode><br />
<rc_mode NAME="AUTO2"><br />
<rc_setting VAR="course_pgain" RANGE="0.1" RC="gain_1_up" TYPE="float"/><br />
<rc_setting VAR="pitch_of_roll" RANGE=".2" RC="gain_1_down" TYPE="float"/><br />
</rc_mode><br />
</rc_settings><br />
</settings></tt><br />
First, settings are sorted by mode (<tt>AUTO1</tt> or <tt>AUTO2</tt>). Then a setting is composed of a <tt>var</tt>iable name, a <tt>range</tt> (corresponding to the range of the RC slider) and a <tt>RC</tt> name. The RC name prefix can be ''gain_1'' or ''gain_2'', which corresponds to the <tt>GAIN1</tt> and <tt>GAIN2</tt> channels of your RC transmitter [[Radio_Control|configuration]]. The RC name suffix can be ''up'' or ''down'', which is related to the position of the <tt>CALIB</tt> switch on the RC transmitter.<br />
<br />
== Audio-based downlink ==<br />
<br />
The audio-based downlink has been removed from current hardware designs however using the old designs it is possible to implement. With the current low prices of a simple video transmitter, data over audio may come in as a welcomed addition. Feel free to experiment and revive this classical feature.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]] [[Category:Telemetry]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=DevGuide/Communications&diff=11122DevGuide/Communications2011-12-18T10:47:14Z<p>P0rc0 r0ss0: /* sending telemetry message */</p>
<hr />
<div>This page describes the way the communications with the aircrafts are implemented in paparazzi.<br />
<br />
[[Messages_Format]]<br />
<br />
We'll start with high level stuff such as sending your own telemetry message or datalink (uplink) message. We'll then look at the lower layers<br />
== sending telemetry message ==<br />
<br />
<br />
Describe your message in the telemetry section in <tt>conf/messages.xml</tt><br />
<br />
This should look like this <br />
<br />
<message name="MARK" id="32"><br />
<field name="ac_id" type="uint8"/><br />
<field name="lat" type="float" unit="deg"/><br />
<field name="long" type="float" unit="deg"/><br />
<field name="alt" type="uint32" unit="mm" alt_unit="m" alt_unit_coef="1000"/><br />
</message><br />
<br />
The '''id''' has to be unique. The fields can have type '''int8''', '''int16''', '''int32''', '''uint8''', '''uint16''', '''uint32''', '''float''' and arrays of those. They must be aligned on a multiple of their size (c.f. examples with ''pad'' fields).<br />
<br />
The '''alt_unit''' and '''alt_unit_coef''' will be used the [[RTPlotter|Plotter]] and the [[Messages|Messages]] agents to display human readable values.<br />
When '''alt_unit_coef''' is not specified, some basic default conversions are automatic:<br />
* deg <-> rad<br />
* deg/s <-> rad/s<br />
* m <-> cm<br />
* m/s <-> cm/s<br />
* decideg -> deg<br />
<br />
This enables all the ground system to deal with your message and generate sending code for the airborne system. The code is generated in <tt>var/include/messages.h</tt>.<br />
<br />
From the airborne code you can send the message by using this code, for example<br />
<br />
DOWNLINK_SEND_MARK(&mark_id, &mark_lat, &mark_long, &mark_alt);<br />
<br />
You can also have the autopilot send the message periodically.<br />
For doing so, in your telemetry file (for example <tt>conf/telemetry/default.xml</tt>, you can make your own and reference it in the [[Conf.xml|<tt>conf/conf.xml</tt>]] file). You can add a line like<br />
<br />
<message name="MARK" period="1"/><br />
<br />
meaning that '''MARK''' will be sent every second. You then need to specify the arguments to your message in <tt>the sw/airborne/ap_downlink.h</tt> header by providing a macro <br />
<br />
#define PERIODIC_SEND_MARK() DOWNLINK_SEND_MARK(&mark_id, &mark_lat, &mark_long, &mark_alt)<br />
<br />
You can have different telemetry modes having different rates for each message. For example you might want a verbose mode and a stealth mode.<br />
<br />
When sent by the aircraft the message will be available on the ground ivy bus. You can watch it using the '''messages''' program or with the <tt>ivyprobe</tt> command line ( <tt>ivyprobe '(.*)'</tt> ).<br />
<br />
The file <tt>sw/ground_segment/cockpit/ant_track.c</tt> shows how to receive a message in a C program.<br />
For ocaml, we have a higher level library to receive messages (<tt>sw/lib/ocaml/pprz.ml</tt>).<br />
<br />
== Adding datalink (uplink) messages ==<br />
<br />
This is similar to the above. Add your message in the <tt>datalink</tt> section of <tt>messages.xml</tt><br />
This will generate parsing code for the airborne program (<tt>var/include/dl_protocol.h</tt>).<br />
<br />
You then can add your handler in the <tt>sw/airborne/datalink.c</tt> code (a way should be found to include external code in that) or you can just rewrite your own <tt>dl_parse_msg()</tt> function, for example in a test program where you want to receive only your own messages.<br />
<br />
== The "transport" layer ==<br />
<br />
Paparazzi can use the built-in transport layer of different hardware (currently only wavecards and xbee/xtends) and also provides his own layer for hardware lacking it (showing as remote serial ports). C sourcecode (.c) and belonging header (.h) -files are:<br />
<tt>xbee.c, xbee.h</tt> <br />
and <br />
<tt>pprz_transport.c, pprz_transport.h</tt><br />
<br />
[[Category:Software]] [[Category:Developer_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Contributing&diff=11121Contributing2011-12-18T10:46:33Z<p>P0rc0 r0ss0: /* Wiki */</p>
<hr />
<div>== How to contribute ==<br />
There are of course lots of ways to contribute to Paparazzi and get involved.<br />
<br />
Help is always welcome on all aspects of the project. May this be documentation, wiki, maintenance, electronics or code contributions/fixes.<br />
<br />
=== Wiki ===<br />
Just create an account and you can start adding information, cleaning it up or just fixing some typo you just noticed :-)<br />
<br />
Also you can find reference template that will help you describe autopilot [[ap_template|here]].<br />
<br />
=== Software development ===<br />
We use the distributed version control system [http://git-scm.com/ git]. The [http://github.com/paparazzi/paparazzi/ Papaprazzi master repository is hosted on Github].<br />
<br />
Please also see the [[Git|Git wiki page]] for more details about setting up Git and cloning the sourcecode and data repository.<br />
<br />
Here is the short version if you already know git:<br />
# Create an account on [http://github.com/ github].<br />
# Fork the [http://github.com/paparazzi/paparazzi/ papaprazzi repo] on github. (After logging in press the '''fork''' button).<br />
# '''git clone git@github.com:<yourname>/paparazzi.git'''<br />
# fix/code<br />
# push your feature/bugfix branch<br />
# Send us a [http://help.github.com/pull-requests/ pull request] on github. (Or send patches to the mailing list).<br />
<br />
=== Issue/Feature Tracker ===<br />
To report bugs, issues and feature request please use either the mailing list or even better the simple [https://github.com/paparazzi/paparazzi/issues issue tracker on github]<br />
<br />
[[Category:Developer_Documentation]]</div>P0rc0 r0ss0http://wiki.paparazziuav.org/w/index.php?title=Developer_Guide&diff=11120Developer Guide2011-12-18T10:44:11Z<p>P0rc0 r0ss0: </p>
<hr />
<div>== A great resource for in-depth information. ==<br />
<br />
By the time you land on this page, you probably want to enhance the Paparazzi project, that is really good for you karma and well appriciated. You are welcomed to enhance and extend this documentation.<br />
<br />
*[[Contributing|Contributing]]<br><small>how to contribute</small><br />
*[[DevGuide/Communications|Communications]]<br><small>how telemetry and datalink is done</small><br />
*[[DevGuide/Server_GCS_com|Server-GCS communications]]<br><small>how the Server and the Ground Control Station interact with each other</small><br />
*[[DevGuide/Values|Values]]<br><small>a short walk through the system</small><br />
*[[DevGuide/USBDownload|USB Download]]<br><small>how the Paparazzi USB bootloader works</small><br />
*[[BootloaderUploadHowTo|Upload Bootloader]]<br><small>How to upload the Bootloader to the AP board</small><br />
*[[DevGuide/JTAG-Debug|JTAG-Debug]]<br><small>using JTAG debug for LPC2148</small><br />
*[[Dev/Debugging|Debug Lisa]]<br><small>using GDB to debug software on Lisa boards</small><br />
*[[DevGuide/DesignOverview|Design Overview]]<br><small>Attempt at a longer walk through the airborne code architerture</small><br />
*[[FirmwareArchitecture|Firmware Architecture]]<br><small>Attempt at brief overview of the firmware architecture with modules and subsystems</small><br />
*[[DevGuide/USB-Serial|USB-Serial]]<br><small>using the USB instead of the UART for telemetry</small><br />
*[[Install_paparazzi_and_everything_from_scratch| Toolchain]]<br><small>Install Paparazzi ARM toolchain and IVY from scratch</small><br />
*[[DevGuide/CodeEditors|Code Editing]]<br><small>How to setup an IDE for OCAML and C and C++</small><br />
*[[DevGuide/LearningToProgram|Learning to Program]]<br><small>Improve your Paparazzi code in OCAML,C,C++ and Python</small><br />
<br />
<br />
*[[AirborneCodingStyle]]<br />
*[[ControlTheory]]<br />
*[[Reference/bootloader]]<br />
*[[Altitude_definitions]]<br />
*[[Abi]]<br />
*[[DevGuide/StateInterface]]<br />
<br />
[[Category:Developer_Documentation]]</div>P0rc0 r0ss0