PaparazziUAV - User contributions [en]

Ivy

2015-07-29T00:59:30Z

Mcurrie: /* Extending Ivy Networks */

Ivy is a [https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern Publish-Subscribe (or pub/sub)] bus used in Paparazzi to link the different components of the ground network together. See [[Overview#System_Architecture|System Architecture]] and [[DevGuide/Server_GCS_com]] for a general overview of its role in the Paparazzi UAS.

Ivy is text-based (ASCII) and features [https://en.wikipedia.org/wiki/Regular_expression regular expression] based message subscription. Software applications employing Ivy announce their presence on the local network by UDP broadcast and share subscriptions. All messages are communicated thereafter via direct TCP connections. While the traffic is TCP, the use of UDP protocol for broadcast announcements requires that peers reside within the same network subnet.

Paparazzi software applications default to binding to locahost and thus unable to communicate with peers residing elsewhere on the local area network. Ivy and subsequently the paparazzi software applications can be directed to bind to a local network interface instead, thereby permitting LAN communication with peers by simply supplying a bus designation command-line argument shown below. These can be saved in a Paparazzi Center session for persistence.

Including the libivy headers and library and using a predefined set of messages, it is possible for any software component to take part in communication in a Paparazzi biotope. Ivy, the protocol itself is developed independently of the Paparazzi project and can be obtained along with examples and documentation from http://www.tls.cena.fr/products/ivy/ .

== Ivy Networks ==

=== Binding Ivy Networks ===

Ivy defaults to UDP port 2010 if a port is not specified. Port is specified by '':PORTNUMBER'' suffix on network.

Examples:

192.168.0.0/24 (192.168.0.x network) UDP/2010; The following are all valid:

program -b 192.168.0.255
program -b 192.168.0.255:2010
program -b 192.168.0
program -b 192.168.0:2010

10.0.0.0/8 (10.x.x.x or 10.255.255.255); The following are all valid:

program -b 10
program -b 10:2010
program -b 10.255.255.255
program -b 10.255.255.255:2010

=== Extending Ivy Networks ===

Ivy requires that all peers in the network reside within the same local area network (it does not support routing). This can be solved by two different approaches.

==== 1 - Virtual Private Network (VPN) ====

By employing a standard IP VPN, remote hosts may communicate within the Ivy network permitting the VPN configuration is BRIDGED and not ROUTED. Many (routed) VPN configurations provide a network subnet for VPN clients and then route the traffic to the remote network. While this is approach is inline with best practices for IT systems, it does not permit Ivy to operate.

==== 2 - Ivy Network Bridging ====

[[TCP_Aircraft_Server|TCP Aircraft Server]]

-- looking for more information

== Tools ==

=== Ivyprobe ===

Ivyprobe is a command-line tool for sending and receiving messages on the Ivy bus. This tool is useful for monitoring and troubleshooting an Ivy bus in the same way an Ivy client would behave, with custom regexp match filters.

Run it with the '''-h''' option to display the help:
$ ivyprobe -h

E.g. to simply display all messages:
$ ivyprobe '(.*)'

[[Category:Communication]]

Ivy

2015-07-29T00:47:16Z

Mcurrie:

Ivy is a [https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern Publish-Subscribe (or pub/sub)] bus used in Paparazzi to link the different components of the ground network together. See [[Overview#System_Architecture|System Architecture]] and [[DevGuide/Server_GCS_com]] for a general overview of its role in the Paparazzi UAS.

Ivy is text-based (ASCII) and features [https://en.wikipedia.org/wiki/Regular_expression regular expression] based message subscription. Software applications employing Ivy announce their presence on the local network by UDP broadcast and share subscriptions. All messages are communicated thereafter via direct TCP connections. While the traffic is TCP, the use of UDP protocol for broadcast announcements requires that peers reside within the same network subnet.

Paparazzi software applications default to binding to locahost and thus unable to communicate with peers residing elsewhere on the local area network. Ivy and subsequently the paparazzi software applications can be directed to bind to a local network interface instead, thereby permitting LAN communication with peers by simply supplying a bus designation command-line argument shown below. These can be saved in a Paparazzi Center session for persistence.

Including the libivy headers and library and using a predefined set of messages, it is possible for any software component to take part in communication in a Paparazzi biotope. Ivy, the protocol itself is developed independently of the Paparazzi project and can be obtained along with examples and documentation from http://www.tls.cena.fr/products/ivy/ .

== Ivy Networks ==

=== Binding Ivy Networks ===

Ivy defaults to UDP port 2010 if a port is not specified. Port is specified by '':PORTNUMBER'' suffix on network.

Examples:

192.168.0.0/24 (192.168.0.x network) UDP/2010; The following are all valid:

program -b 192.168.0.255
program -b 192.168.0.255:2010
program -b 192.168.0
program -b 192.168.0:2010

10.0.0.0/8 (10.x.x.x or 10.255.255.255); The following are all valid:

program -b 10
program -b 10:2010
program -b 10.255.255.255
program -b 10.255.255.255:2010

=== Extending Ivy Networks ===

Ivy requires that all peers in the network reside within the same local area network (it does not support routing). This can be solved by two different approaches.

1) Virtual Private Network (VPN)

By employing a standard IP VPN, remote hosts may communicate within the Ivy network permitting the VPN configuration is BRIDGED and not ROUTED. Many (routed) VPN configurations provide a network subnet for VPN clients and then route the traffic to the remote network. While this is approach is inline with best practices for IT systems, it does not permit Ivy to operate.

2) Ivy Bridging

-- looking for more information

== Tools ==

=== Ivyprobe ===

Ivyprobe is a command-line tool for sending and receiving messages on the Ivy bus. This tool is useful for monitoring and troubleshooting an Ivy bus in the same way an Ivy client would behave, with custom regexp match filters.

Run it with the '''-h''' option to display the help:
$ ivyprobe -h

E.g. to simply display all messages:
$ ivyprobe '(.*)'

[[Category:Communication]]

Ivy

2015-07-29T00:42:41Z

Mcurrie:

Ivy is a [https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern Publish-Subscribe (or pub/sub)] bus used in Paparazzi to link the different components of the ground network together. See [[Overview#System_Architecture System Architecture]] and [[DevGuide/Server_GCS_com]] for a general overview of its role in the Paparazzi UAS.

Ivy is text-based (ASCII) and features [https://en.wikipedia.org/wiki/Regular_expression regular expression] based message subscription. Ivy agents (software applications) announce their presence on the local network by UDP broadcast and share subscriptions. Messages are communicated thereafter via TCP sockets. While the traffic is TCP, the use of UDP broadcast requires that peers reside within the same network subnet.

Paparazzi software applications default to binding to locahost and thus will not communicate with peers residing elsewhere on the local area network. Most paparazzi components can be directed to bind to a local network interface thereby permitting LAN communication with peers by simply supplying a bus designation commandline argument shown below. These can be saved in a Paparazzi Center session for persistence.

Including the libivy headers and library and using a predefined set of messages, it is possible for any software component to take part in communication in a Paparazzi biotope. Ivy, the protocol itself is developed independently of the Paparazzi project and can be obtained along with examples and documentation from http://www.tls.cena.fr/products/ivy/ .

== Ivy Networks ==

=== Binding Ivy Networks ===

Ivy defaults to UDP port 2010 if a port is not specified. Port is specified by '':PORTNUMBER'' suffix on network.

Examples:

192.168.0.0/24 (192.168.0.x network) UDP/2010

The following are all valid:

program -b 192.168.0.255
program -b 192.168.0.255:2010
program -b 192.168.0
program -b 192.168.0:2010

10.0.0.0/8 (10.x.x.x or 10.255.255.255)

program -b 10
program -b 10:2010
program -b 10.255.255.255
program -b 10.255.255.255:2010

=== Extending Ivy Networks ===

Ivy requires that all peers in the network reside within the same local area network (it does not support routing). This can be solved by two different approaches.

1) Virtual Private Network (VPN)

By employing a standard IP VPN, remote hosts may communicate within the Ivy network permitting the VPN configuration is BRIDGED and not ROUTED. Many (routed) VPN configurations provide a network subnet for VPN clients and then route the traffic to the remote network. While this is approach is inline with best practices for IT systems, it does not permit Ivy to operate.

2) Ivy Bridging

-- looking for more information

== Tools ==

=== Ivyprobe ===

Ivyprobe is a command-line tool for sending and receiving messages on the Ivy bus. This tool is useful for monitoring and troubleshooting an Ivy bus in the same way an Ivy client would behave, with custom regexp match filters.

Run it with the '''-h''' option to display the help:
$ ivyprobe -h

E.g. to simply display all messages:
$ ivyprobe '(.*)'

[[Category:Communication]]

Sensors/GPS

2015-04-19T18:59:32Z

Mcurrie: /* Globalsat BU 353 */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Sensors</categorytree>
<div style="float:left; clear:left; margin-right:2ex; padding: 0.7ex;">__TOC__</div>

<br style="clear:both;" />

=GPS Receivers=

An overview of GPS receivers used icw paparazzi. The list is by far not complete. A lot more devices will work flawlessly with Paparazzi. If you have a GPS receiver you used with Paparazzi and is not listed here, it would be great if you could add addtional information on this page.
<br style="clear:both;" />

=Swiftnav Piksi=

A very special receiver is the OpenSource (almost all...) Swiftnav Piksi GPS receiver. How to use this device with Paparazzi is described on the a specific page
[[Image:Piksi_GPS_back.jpg|100px|thumb|left|Swiftnav Piksi]]
<br style="clear:both;" />

=LS20031 GPS Receiver=

[[Image:ls20031.jpg|100px|thumb|left|LS20031]]
Sparkfun sells the LS20031 GPS module which uses NMEA (Paparazzi support for NMEA is BETA right now.) This Locosys GPS module supports WAAS (U.S. DGPS), EGNOS (EU DGPS), and MSAS (Japanese DGPS).

More information on configuring the GPS via PMTK can be found [http://dallasmakerspace.org/wiki/LS20031_GPS here]
<br style="clear:both;" />

=Globalsat BU 353=

[[Image:BU-353_gps_receiver.jpg|thumb|left|100px|BU-353 GPS receiver]]

USB US Globalsat GPS-Mouse

Typical Uses:

* Parrot AR Drone 2.0
* Ground Station GPS (direct support with Linux / gpsd)

''Not appropriate for many airborne applications due to extra USB-serial circuitry and weight of housing and internal magnet''

Basic compatibility with Windows, Mac and Linux.<br/>
More information at the [[GPS/BU_353]] site.
<br style="clear:both;" />

=uBlox=

[[Image:U-blox_color_warm_60.gif|100px]]
[http://www.u-blox.com uBlox is a Swiss technology company] which develops and delivers very good positioning modules. It produces the recommended GPS modules for use with Paparazzi autopilots from the popular brand of receivers.

Why uBlox:
*Low cost [[Sensors/GPS#u-blox_NEO-6M|NEO6-M]])
*Small size
*Excellent performance
*Up to 10Hz update rate
*Large amount of different modules
*5V tolerant UART

The '''[[Tiny]]''' series features an onboard LEA series GPS receiver and patch antenna, while most other boards boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below.

{|align = center
|-
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-Blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]
|[[Image:UBlox_LEA-6H_Sarantel_Helix_s.jpg|200px|thumb|center|u-Blox LEA-6H GPS receiver with Sarantel Helix Antenna]]
|}

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/subsystems/gps/gps_ubx.c</tt>.

==u-Blox LEA Series Receivers==


[[Image:Lea5htiny13.jpg|thumb|left|200px|LEA-5H installed on the Tiny]]
The '''[[Lisa]]''' series, '''[[Twog_v1|TWOG]]''', '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external GPS module and antenna. The '''[[Tiny]]''' features an integrated receiver and antenna. Either type is designed for [http://www.u-blox.com/ u-blox] 4, 5 and 6 series GPS receivers and the proprietary UBX binary protocol. An external battery or capacitor is typically used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4, LEA-5 and LEA-6 series receivers can be used including the less expensive LEA-4A, 4S, 5A and 5S and similar low cost 6-series models as the special boot configuration code required for these models is already written as a [[Module/GPS_UBlox_UCenter|module]].

<source lang="xml">

<load name="gps_ubx_ucenter.xml" />
</source>

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]
*Low position noise figure

<br style="clear:both">

==Paparazzi Stand-alone uBlox GPS Receivers==

<gallery>
Image:Ppzgps13med01.jpg|Top
Image:Ppzgps13_lrg_02.jpg|Bottom
</gallery>
<p>Paparazzi source provides a design for an external GPS board. An external GPS board is required for Lisa, TWOG and Classix Autopilot board.
Programming it is similar to the Tiny2.11 GPS configuration. If you build your own you will want to upload the latest u-blox firmware before you configure. See [[Get Hardware]] for sources of assembled boards.</p>
<p>
The Paparazzi design in https://github.com/paparazzi/paparazzi-hardware/tree/master/sensors/gps/gps_13. The board is very small and light as it has only the components required. It is powered from the 5v line on the "downloads" connector of a TWOG. Also note it is a 4-layer PCB that means better noise resistance. The board has pins for USB connection but requires a different cable and a solder jumper to be move from the ground (default) to 3.3v input to enable the USB port on the module.
</p>
<p>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM.xls]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output.txt]<br>
See [[Get_Hardware|Get Hardware]] page for suppliers.
</p>

===Wiring Diagram===

{|align = none
|-
|[[Image:TWOG to GPS.jpg|200px|thumb|center|TWOG to Standalone GPS Cable Schematic]]
|[[Image:gps13v09FTDIcable.jpg|200px|thumb|center|GPS13 v0.9 Ucenter cable (ftdi)]]
|[[Image:booz gps.jpg|200px|thumb|center|BoozGPS (quadrotor gps V1.1 2009/5) Ucenter cable (ftdi)]]
|}

===uBlox to ARdrone 2===

[[Image:HowtoConnectUSBHelixGPSForParrotARDrone2.jpg|thumb|left|How to connect USB to uBlox Helix GPS for Parrot ARDrone2]]
To connect a uBlox with Helix antenna via a USB to serial cable that you can just plug into your ARdrone 2
<br style="clear:both;" />

==3rd Party u-blox Reference Design Boards==

<p>
[[Image:LEA5HExternalModulePinout.jpg|thumb|left|LEA-5H Full Board Pinout]]
The only other GPS board in use seems to be u-blox reference designs or similar to it. They have LEA-4H, LEA-5H and LEA-6H (typically) and several interfaces. Often a larger antenna as well.
</p>
<p>
The board in the photo is a [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Receiver-Boards.asp RF DESIGN] LEA-5H-SMART.
</p>
<p>
The jumpers adjacent to the TTL interface connectors need to be closed with low value resistors for paparazzi uart port use. Also a [http://nz.element14.com/jsp/search/productdetail.jsp?SKU=1514218 battery] has to be added with an appropriate charging resistor to enable RTC functionality.
</p>

<br style="clear:both;" />

==NAVILOCK NL-507ETTL==

[[Image:Navilock NL-507ETTL.jpg|thumb|left|NAVILOCK NL-507TTL]]
The NAVILOCK NL-507TTL u-blox TTL Modul 60416 features an LEA-4 series receiver and 25mm patch antenna on a 30mm x 30mm board.
* Datasheet: [http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481 http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481]
* Purchase: Available for 28€ at [http://www.amazon.de/Navilock-NL-507TTL-u-blox-TTL-Modul/dp/B0011E6VQG www.amazon.de]
<br style="clear:both;" />

==SPK GS407==

[[Image:GS407.jpg|thumb|left|SPK GS407]]
[https://www.sparkfun.com/products/11466 This] is the model Sparkfun recommends as a replacement for the old GS406. It's essentially the same, but uses the newer 6-series receiver, and is not using a ribbon cable as an interface. It uses [http://www.sarantel.com/products/sl1206 Sarantels] SL1206 active antenna.
It's recommended to buy [https://www.sparkfun.com/products/574 This extension cable] to use with it.
<br style="clear:both;"/>

==u-blox NEO-6M==

[[Image:Hk neo gps.jpg|thumb|left|Hobbyking NEO 6M back]]
This is the cheapest GPS module with antenna for ~13€ at [http://www.hobbyking.com/hobbyking/store/__31135__NEO_6M_GPS_Module.html Hobbyking].

They come with different (sized) patch antenna, mounted on a seperate PCB. The main PCB and antenna PCB are fixed with hot glue together and can be seperated by hand.
<br style="clear:both;"/>

==Navilock NL-652ETTL==

Nice module with u-blox 6 chip and without the annoying cable that the HK NEO-6m has.
[http://www.navilock.de/produkte/G_61846/merkmale.html?setLanguage=en Navilock NL-652ETTL]

==u-Blox C04-6H Reference Design==

[[Image:abavimage.jpg|thumb|left|u-blox C04-5H]]
u-Blox sells a complete module with antenna for around $200 and will also provide complete schematics, BOM, and PCB files for free if you wish to make your own. Two versions are offered, one with an 18mm patch antenna and the other with the Sarantel P2 helical antenna.
See [http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html] for more info.
<br style="clear:both;" />

==uBlox GPS configuration==

===using U-Center===

[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers.
* [http://www.u-blox.com/en/evaluation-tools-a-software/u-center/u-center.html Download u-center]

* Note 1: You must [[tunnel|install the UART tunnel firmware]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].

* Note 2: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].

* Note 3: You can run u-center on Linux by installing "Wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and set up COM1 as /dev/ttyUSB0. You need to create a symbolic link from the COM device to TTY like this:
mkdir -p ~/.wine/dosdevices
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1

or what worked in Ubuntu 9.10

ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1

This command will create the symbolic link from ttyUSB0 to COM1. See Info on Wine for "dosdevices" setup. Just download the u-setup.exe and run it with Wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.

The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===

Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]
* [[Media:Tim-LL-V5.zip|TIM-LL]]
* [[Media:Tiny_LEA-5H-v5.zip|LEA-5H (For Use w/ Firmware V5 ONLY!)]]
* [[Media:Hk_NEO-6M.zip‎| Hobbyking NEO-6M]] [http://www.hobbyking.com/hobbyking/store/__31135__neo_6m_gps_module.html this module]

===Automatic Configuration at Startup===

You can also use the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] which will take over the task of initializing the GPS for you when you power your autopilot.

===Manual Configuration===

If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:

====LEA-4P====

# Right Click on the '''NMEA''' Icon and choose '''disable child'''
# Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point
# UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

====LEA-5H====

# Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''
# Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction. <p> Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better</p>
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-Blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.

#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH.

====LEA-6H====

We use the same configuration as for version 5

# Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''
# Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction. <p> Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better </p>
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver.<p> Make sure you activate '''"2 - I2C-EEPROM"''' if using a ROM-based NEO chipset with external EEPROM (like [http://www.hobbyking.com/hobbyking/store/__31135__neo_6m_gps_module.html HK 31135])</p>

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-6H get u-center >= 6.21, revert the GPS receiver to the default configuration, get an appropriate firmaware file from u-Blox, find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.(seriously)

==uBlox Tips==

===Reset to Default Settings===

The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.

===Invalid argument===

Problem: I keep getting this error with my nice shiny Tiny v2.1 with a LEA-5H: Invalid_argument ("Latlong.of_utm")
Solution: Select the correct [[Subsystem/gps|GPS subsystem]].

===WAAS issues===

WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to first test if WAAS works well in your region.

===Antenna options for the Tiny and Paparazzi GPS units===
See [[GPS/Antenna]].

=Tips=

There is a huge amount of good information on the internet about GPS specifics that gives some good insight into GPS. This Paparazzi wiki is not intended to repeat already available information, some is added here.

==EGNOS==

EGNOS augments the GPS satellite navigation system and makes it suitable for safety critical UAS applications. EGNOS became operational on 1 October 2009. ESA claims that it can determine position to within 2 meters compared with about 20 meters for GPS alone. Note that the service is currently provided only in western Europe. For further information take a look on the [http://www.esa.int/esaNA/egnos.html ESA EGNOS website].

For the latest update about functionality of EGNOS please check the website: [http://www.gsa.europa.eu European GNSS Supervisory Authority]"

==DGPS (Differential GPS)==

Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.esa.int/esaNA/ESAF530VMOC_egnos_1.html WAAS, EGNOS, and MSAS regions]. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.

[[Category:Hardware]] [[Category:Sensors]] [[Category:User_Documentation]]

Installation/Linux

2014-10-06T23:19:55Z

Mcurrie: add instructions on manual configuration of gcc-arm-embedded for Debian hosts

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Installation</categorytree>
__TOC__

'''<span style="color:red">This page only describes the installation of the prerequisite tools and dependencies on Debian/Ubuntu needed for Paparazzi.</span>'''

'''See the general [[Installation]] page for how to [[Installation#Getting_the_Source_Code|download Paparazzi]] and [[Installation#Launching_the_Software|launching it]] after you followed the instructions here.'''

== Introduction ==

Paparazzi is very easily installed on any laptop or workstation running [http://www.ubuntu.com/ Ubuntu], [http://www.debian.org/ Debian] (or any of their derivatives).

The steps required to install the software needed to be able to let your UAS fly
<ul>
<li>[[Installation/Linux#Installation_of_dependencies|Install the basic Paparazzi dependencies]] and the [[Installation/Linux#ARM_embedded_toolchain|ARM cross compiling toolchain.]]
<li>[[Installation#Getting_the_Source_Code|Download the source code from the source repository.]]
<li>Allow access to your PC hardware connection by adding appropriate [[Udev]] rules.
<li>[[Installation#Launching_the_Software|Compile the binaries from the sources and launch the software.]]
</ul>

Users of other Linux flavors than a recent Ubuntu or Debian and anyone needing manual control of each individual package can [[Installation/Manual|install them independently]].

===For the impatient===

For Ubuntu add the [https://launchpad.net/~paparazzi-uav/+archive/ppa paparazzi-uav ppa] <tt>sudo add-apt-repository ppa:paparazzi-uav/ppa</tt> and install the <tt>paparazzi-dev</tt> package.

Since Paparazzi v5.0 the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] is recommended.
Available as of Ubuntu 14.04, on older versions it can be [[Installation/Linux#ARM_embedded_toolchain|installed via tarball]].

Or just use the [[Installation#Quickstart_on_Ubuntu_12.04|Quickstart for Ubuntu 12.04 LTS]].

== Installation video Tutorials ==

{{#ev:youtubehd|SshFJrBuku8}} {{#ev:youtubehd|eW0PCSjrP78}}

== Installation of dependencies ==

=== Ubuntu ===

Add the installation sources for the Paparazzi software packages. Run from a terminal:
sudo add-apt-repository ppa:paparazzi-uav/ppa

Then update the systems package inventory and install the main Paparazzi software dependencies. This will take some time.
sudo apt-get update
sudo apt-get install paparazzi-dev

=== Debian ===

For Debian Squeeze (6.0) and Wheezy (7.0) packages are built using the [http://openbuildservice.org/ Open Build Service (OBS)] on [https://build.opensuse.org/project/show?project=home%3Aflixr%3Apaparazzi-uav OpenSUSE Build Service project home:flixr:paparazzi-uav]

First add the key:
wget -q "http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_7.0/Release.key" -O- | apt-key add -

Add the appropriate repo, depending on your Debian version to sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_6.0/ ./" | tee -a /etc/apt/sources.list
echo "deb http://download.opensuse.org/repositories/home:/flixr:/paparazzi-uav/Debian_7.0/ ./" | tee -a /etc/apt/sources.list

Update the systems package inventory and install the main Paparazzi software dependencies.
sudo apt-get update
sudo apt-get install paparazzi-dev

== ARM embedded toolchain ==

For current Paparazzi versions (v5.0 and above) the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] is recommended, which also supports the STM32F4 with FPU (hardware floating point).

The most common way is to download and unpack the tarball and add it to your PATH:

[http://pixhawk.org/dev/toolchain_installation_lin The Pixhawk Devs have mentioned the 4.8 as buggy.]

cd ~
wget https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q2-update/+download/gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2
tar -vjxf gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2 -C /opt
rm -r gcc-arm-none-eabi-4_7-2013q2-20130614-linux.tar.bz2
exportline="PATH=$PATH:/opt/gcc-arm-none-eabi-4_7-2013q2/bin"
if grep -Fxq "$exportline" ~/.profile; then echo nothing to do ; else echo $exportline >> ~/.profile; fi
source ~/.profile

The file .profile will be sourced in every bash after logging out and in again. Until then,
source ~/.profile
can be used for every bash individually.

If you can not access your toolchain with PATH working, look a the [[Installation/Linux#Troubleshooting]].

=== gcc-arm-none-eabi as Debian/Ubuntu package ===

Note that there are actually two '''different''' toolchains available that unfortunately have the same package name!
* [https://launchpad.net/gcc-arm-embedded/ ARM gcc-arm-embedded toolchain]
** includes libstdc++ and newlib-nano
* [https://packages.debian.org/jessie/gcc-arm-none-eabi Debian gcc-arm-none-eabi toolchain]
** does not include libstdc++
** does not include newlib-nano

Both toolchains ''should'' work for most use-cases (if you don't need C++ or nano specs), although the [https://launchpad.net/gcc-arm-embedded/ ARM gcc-arm-embedded toolchain] is better tested.

==== ARM gcc-arm-embedded toolchain (from launchpad) - Debian Quick (Manual) Install Process ====

This approach is quick and low risk as it does not rely on any packages or make modifications to the system.

* Download latest gcc-arm-none-eabi-*-*-linux.tar.bz2 from [https://launchpad.net/gcc-arm-embedded/+download External Downloads] section of ARM gcc-arm-embedded project
* Create /opt/paparazzi folder if it does not exist
sudo mkdir /opt/paparazzi
* Decompress file to /opt/
sudo tar -xvf [name_of_downloaded_bz2_file] /opt/
* Create symlink so Paparazzi Makefile can find the library
sudo ln -s /opt/[gcc-arm-xxxxxxx_name_of_folder] /opt/paparazzi/arm-multilib
* Attempt to build paparazzi autopilot firmware (example, Paparazzi Center build target ap)

==== gcc-arm-embedded toolchain ====

On ''most'' Ubuntu versions (currently lucid, precise, raring, saucy and trusty) the [https://launchpad.net/gcc-arm-embedded/ gcc-arm-embedded toolchain] can be installed as a debian package from the [https://launchpad.net/~terry.guo/+archive/gcc-arm-embedded ppa]:
sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi

Note [https://bugs.launchpad.net/gcc-arm-embedded/+bug/1309060 bug1309060] on Ubuntu 14.04 you have to explicitly install the gcc-arm-embedded version.
You can list the available versions with <tt>apt-cache policy gcc-arm-none-eabi</tt>
sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
sudo apt-get install gcc-arm-none-eabi=4-8-2014q2-0trusty9

==== gcc-arm-none-eabi Debian toolchain ====

Debian testing ('''jessie''') and Ubuntu 14.04 ('''trusty''') have the gcc-arm-none-eabi package in the official repositories ('''universe'''), and can be installed with:
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi

=== Old toolchain for Paparazzi v4.x and earlier ===

'''For Paparazzi v4.x''' and earlier you need to install the <tt>paparazzi-arm-multilib</tt> package. It has support for both ARM7 (i.e. Tiny,TWOG,YAPA autopilot boards) as well as STM32F1 (i.e. LISA boards).<br>
'''This toolchain does not properly support STM32F4 based autopilots!!'''

You can install it explicitly with:
sudo apt-get install paparazzi-arm-multilib

== Optional Packages ==

The packages <b>lpc21isp</b> and <b>openocd</b> are normally '''automatically installed''' as they are recommended packages of paparazzi-dev, '''if not''' you can manually install them via:

sudo apt-get install lpc21isp openocd

<tt>lpc21isp</tt> is needed to serially flash the LPC2148 based autopilots (e.g. bootloader for tiny, twog, umarim), <tt>openocd</tt> is for flashing via JTAG (e.g. for Lisa boards) and debugging.

== Installing and running Paparazzi ==

Please see [[Installation#Getting_the_Source_Code|Getting the Source Code on the general Installation page]] for details on downloading the Paparazzi source code, compiling and running it.

== Udev rules ==

Add the appropriate [[Udev]] rule (available in fhe file ''50-paparazzi.rules'') to the USB handler. Simply copy as root <tt>conf/system/udev/rules/50-paparazzi.rules</tt> to <tt>/etc/udev/rules.d/</tt>, e.g in a terminal:

cd <your paparazzi directory>
sudo cp conf/system/udev/rules/50-paparazzi.rules /etc/udev/rules.d/

See the [[Udev]] page for more details.

== Troubleshooting ==

=== No access rights for USB devices ===

Some Linux distributions, don't allow standard (non admin) users to directly access the USB bus by default. On recent Ubuntu/Debian versions the first/main user is already a member of the ''plugdev'' group which should be sufficient for most cases.<br>
If you have problems, make yourself a member of the ''plugdev'' and ''dialout'' groups:

sudo adduser <your login> plugdev
sudo adduser <your login> dialout

Logout and login again.

=== arm-none-eabi-gcc: Command not found ===
Appeared on Debian Wheezy 7 (gcc-arm-none-eabi-4_8-2013q4 installed via tarball)<br/>
If this error occurs, maybe the [https://packages.debian.org/de/wheezy/ia32-libs ia32-libs] are missing.

Enable multiarch and install ia32-libs:
dpkg --add-architecture i386
apt-get update
apt-get install ia32-libs

===arm-none-eabi-gdb: error with libncurses.so.5===
Appeared on Xubuntu 14.04 LTS (gcc-arm-none-eabi-4_8-2013q4 installed via tarball)<br/>
Terminal output: arm-none-eabi-gdb: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

If this error occours, maybe [http://packages.ubuntu.com/search?keywords=lib32ncurses5 lib32ncurses5] is missing. <br/>
Found on [https://answers.launchpad.net/gcc-arm-embedded/+question/226680 launchpad q&a]

=== FTDI serial adapter not working on old Ubuntu version ===

On older Linux distributions (not needed for lucid and later), the Braille TTY driver interferes with FTDI USB Serial adapters. If somehow your FTDI serial adapter does not work, remove the package via:

sudo apt-get remove brltty

=== Code not starting on autopilot after changing gcc ===

If you changed the toolchain (e.g. installed a new one for having FPU-Support for the F4), you need to run

make clean && make

in sw/ext in order to rebuild the libs. Otherwise the embedded code can behave strange (most likely not start)

[[Category:Software]] [[Category:User_Documentation]] [[Category:Installation]]

Talk:OSAMTuning

2013-08-19T20:08:20Z

Mcurrie: moved Talk:OSAMTuning to Talk:OSAM Tuning Procedure

#REDIRECT [[Talk:OSAM Tuning Procedure]]

Talk:OSAM Tuning Procedure

2013-08-19T20:08:20Z

Mcurrie: moved Talk:OSAMTuning to Talk:OSAM Tuning Procedure

Placed a copy of this OSAMTuning guide on our wiki so I could re-structure the formatting to get it to work with our booklet creator ~ Matthew Currie 19 Aug 2013

OSAMTuning

2013-08-19T20:08:20Z

Mcurrie: moved OSAMTuning to OSAM Tuning Procedure

#REDIRECT [[OSAM Tuning Procedure]]

OSAM Tuning Procedure

2013-08-19T20:08:20Z

Mcurrie: moved OSAMTuning to OSAM Tuning Procedure

__NOTOC__

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NEUTRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Tuning Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step 2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.

Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.

Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.

The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T20:08:08Z

Mcurrie:

OSAM Tuning Procedure

2013-08-19T20:06:55Z

Mcurrie: /* Step2 */

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NEUTRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step 2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.

Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.

Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.

The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

Talk:OSAM Tuning Procedure

2013-08-19T20:06:37Z

Mcurrie: Created page with "Placed a copy of this OSAMTuning guide on our wiki so I could re-structure the formatting to get it to work with our booklet creator ~ Matthew Currie 19 Aug 2013"

Placed a copy of this OSAMTuning guide on our wiki so I could re-structure the formatting to get it to work with our booklet creator ~ Matthew Currie 19 Aug 2013

OSAM Tuning Procedure

2013-08-19T20:05:29Z

Mcurrie: /* Step3 */

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NEUTRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.

Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.

Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.

The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T20:05:11Z

Mcurrie: /* Step2 */

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NEUTRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.

Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.

Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T20:04:48Z

Mcurrie: /* ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT */

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NEUTRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.<br>
Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.
<br>Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T20:04:36Z

Mcurrie: /* HORIZ_SENSOR_TILTED */

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NEUTRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum<br>or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.<br>
Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.
<br>Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T20:00:12Z

Mcurrie: /* PITCH_NEUTRAL_DEFAULT & ROLL_NUETRAL_DEFAULT */

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is<br>facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NEUTRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum<br>or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.<br>
Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.
<br>Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T19:59:58Z

Mcurrie: /* Variable Explanation */

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is<br>facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.
Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NEUTRAL & ADC_PITCH_NEUTRAL & ADC_TOP_NEUTRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference across each pair of sensors.

===PITCH_NEUTRAL_DEFAULT & ROLL_NUETRAL_DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum<br>or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2 mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.<br>
Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.
<br>Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T19:58:38Z

Mcurrie:

=Airframe Tuning Procedure=

==Variable Explanation==

===HORIZ_SENSOR_TILTED===

This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is<br>facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and<br>west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

===IR_360_Lateral_Correction & IR_360_ Longitudinal_Correction===

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.<br>Longitudinal is the pitch and Lateral is the roll.

===ADC_ROLL_NUETRAL & ADC_PITCH_NUETRAL & ADC_TOP_NUETRAL===

These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference<br>across each pair of sensors.

===PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT===

The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the<br>plane fly flat and straight.

===ROLL_PGAIN & PITCH_PGAIN===

This is the proportional variable in the pitch and roll control loops.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum<br>or minimum angle.

===ALTITIUDE_PGAIN & COURSE_PGAIN===

These are the proportional control variables of the altitude and course loops.

===MAX_ROLL & MAX_PITCH===

These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by<br>default in radians.

===ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT===

These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2<br>mode.. These are by default in radians.

==Procedure==

===Step 1===

Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.

===Step2===

First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary
electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.<br>
Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.
<br>Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

===Step3===

Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

===Step 4===

The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T19:53:41Z

Mcurrie:

<div style="padding:6px;">{{OSAMHeader}}</div>
<h1>Airframe Tuning Procedure</h1>
<h2>Variable Explanation</h2>
<h3>HORIZ_SENSOR_TILTED</h3>
----
This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is<br>facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and<br>west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

'''IR_360_Lateral_Correction & IR_360_ Longitudinal_Correction'''

Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.<br>Longitudinal is the pitch and Lateral is the roll.

<h3>ADC_ROLL_NUETRAL & ADC_PITCH_NUETRAL & ADC_TOP_NUETRAL</h3>
----
These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference<br>across each pair of sensors.

<h3>PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT</h3>
----
The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the<br>plane fly flat and straight.

<h3>ROLL_PGAIN & PITCH_PGAIN</h3>
----
This is the proportional variable in the pitch and roll control loops.

<h3>ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT</h3>
----
These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum<br>or minimum angle.

<h3>ALTITIUDE_PGAIN & COURSE_PGAIN</h3>
----
These are the proportional control variables of the altitude and course loops.

<h3>MAX_ROLL & MAX_PITCH</h3>
----
These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by<br>default in radians.

<h3>ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT</h3>
----
These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2<br>mode.. These are by default in radians.

<h2>Step 1</h2>
Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.
<h2> Step2</h2>First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.<br>
Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.
<br>Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

<h2>Step3</h2>
Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

<h2>Step 4</h2>The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

OSAM Tuning Procedure

2013-08-19T19:49:31Z

Mcurrie: Created page with "<div style="padding:6px;">{{OSAMHeader}}</div> <h1>Airframe Tuning Procedure</h1> <h2>Variable Explanation</h2> <h3>HORIZ_SENSOR_TILTED</h3> ---- This Describes whether the IR s…"

<div style="padding:6px;">{{OSAMHeader}}</div>
<h1>Airframe Tuning Procedure</h1>
<h2>Variable Explanation</h2>
<h3>HORIZ_SENSOR_TILTED</h3>
----
This Describes whether the IR sensor is titled at a 90 degree angle or 45 degree angle. This meaning if the nose of the plane is<br>facing north when the sensor is at 45 degrees (equals a 1 in the airframe config) the thermopile's do not point north south east and<br>west but rather at a 45 degree offset from those directions. This is the recommended way to configure the IR sensors.

<h3>IR_360_Lateral_Correction & IR_360_ Longitudinal_Correction</h3>
----
Coefficient that corrects the outputs of the IR sensor and is proportional meaning that it is simply multiplied by the sensor reading.<br>Longitudinal is the pitch and Lateral is the roll.

<h3>ADC_ROLL_NUETRAL & ADC_PITCH_NUETRAL & ADC_TOP_NUETRAL</h3>
----
These are the readings from the sensor when it is in a neutral state. This is also characterized by having no temperature difference<br>across each pair of sensors.

<h3>PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT</h3>
----
The angles which are output when the plane is in the “flat” position. This flat is also known as the angles necessary to make the<br>plane fly flat and straight.

<h3>ROLL_PGAIN & PITCH_PGAIN</h3>
----
This is the proportional variable in the pitch and roll control loops.

<h3>ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT</h3>
----
These set the maximum and minimum of the roll and pitch. This means that the plane will not be able to roll or pitch past the maximum<br>or minimum angle.

<h3>ALTITIUDE_PGAIN & COURSE_PGAIN</h3>
----
These are the proportional control variables of the altitude and course loops.

<h3>MAX_ROLL & MAX_PITCH</h3>
----
These are set in the AUTO1 section of the airframe file and are the maximum allowed pitch and roll in auto1 mode.. These are by<br>default in radians.

<h3>ROLL_MAX_SETPOINT & PITCH_MAX_SETPOINT & PITCH_MIN_SETPOINT</h3>
----
These are set in the HORIZONTAL CONTROL section of the airframe file and are the maximum and minimum allowed pitch and roll in auto2<br>mode.. These are by default in radians.

<h2>Step 1</h2>
Align measured and real angles from the IR sensors. The first step is to take the IR sensors and the fully encase them in foam. Then you must change the ADC neutrals to zero in the airframe file. Once this has been done the user must flash the board then get a connection to the ground station computer and the GUI. Once this has been completed launch the messages agent and view the tab called IR, record the raw sensor values shown. After that disconnect the board and power it down. Finally change the ADC neutrals in the airframe file to the recorded values and re-flash the board.
<h2> Step2</h2>First you must set the ROLL and PITCH neutrals to zero in the airframe file and then flash the board. Next take the airframe outside with all the necessary electronics inside that are needed to fly autonomously. The area which should be used to tune is one without any buildings or large man made objects within 500-1000 ft. This will make the variables far more accurate and save time due to lack of tuning needed in the air. Now place the plane “flat” on a surface so that all the sensors have clear views (aka no man made objects), the vertical sensors should be able to see both the ground and sky. Next connect the plane to the ground station GUI and record the attitude values, once these have been found power down and add the values recorded into the ROLL and PITCH neutrals in the airframe file.<br>
Next, place the pane at an angle of the users choosing and measure the real angle. Remember the IR sensors must have unobstructed views. Now connect the airplane to the GUI and look to see if the reported angle in the messages agent matches the recorded real angle. If these do no match the user must change the 360_Lateral and Longitudinal variables as well as the neutral values, remember the neutral values can only shift the readings so use those for asymmetrical errors. The user must changes these variables until the angles match, it should be noted however that these variables are independent of each other so they should be adjusted one at a time. In addition make sure that the D gain of the Pitch loop is set to zero.
<br>Once the users has done this on ground stuff a couple times it may be possible to use their eye to judge angles in the sky and do all the tuning that way. Remember all of the variables can be changed in real time by utilizing the tuning.xml for the settings of the aircraft

<h2>Step3</h2>
Once the plane is at a safe height and in sight turn on the AUTO1 mode. Next look for oscillations in the roll. If there are oscillations in the roll lower the ROLL_PGAIN coefficient until these no longer exist. If there are no oscillations start to raise to coefficients until the point right before oscillations. The point of this process is to maximize the coefficient value to the point right before oscillations occur. This is the same process that is used to tune the pitch loop except for the coefficient changed is PITCH_PGAIN. However it should be noted that the pitch is far more damped than the roll so it may harder to spot oscillations. The PITCH_PGAIN value is expressed in negative terms so a -10,000 would “higher” than a -6000 variable.
<br>The next step is to test your roll and pitch neutrals. To do this the user must turn on auto1 mode and set the throttle to the nominal throttle value in the airframe file after this is set let go of all sticks and watch to see if the plane flies flat and straight. If this is the case then all is well but if not the user must once again tune the PITCH_ NUETRAL _DEFAULT & ROLL_ NUETRAL _DEFAULT values until the plane flys straight and flat. Next the user must test the maximum and minimum set points of the pitch and roll. This is done by testing in AUTO1, the user must make the plane pitch and roll to maximum and minimum amount that the RC controller allows, this is done by pushing the right stick to its maximum's. These angles however can only be recorded by looking at the plane in the air and guessing. This is not very exact but should give a good value to compare with the user written set points. The IR_360 variables will probably have to be retuned in air during this last part due to bad sensor data on the ground.

<h2>Step 4</h2>The final step is to put the plane into auto2 mode and determine if the plane is flying its desired course and altitude correctly. If this is not the case the PGAIN variables of each must be changed to take out oscillations and maximize to right before oscillations. Remember to check your max angle set points to make sure your plane will not over pitch or roll causing instability.

Autopilots

2011-12-17T19:29:10Z

Mcurrie:

__NOTOC__
__NOEDITSECTION__

{|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;"
|-valign="top"
|
<h3 style="-moz-border-radius-topright: 0.7em;
background:#cedff2;margin:-2px;padding:4px;">
[[Image:favicon32.png|32px]] Autopilots
</h3>
<div style="padding:6px;">
{{Autopilots}}
</div>

| class="MainPageBG" style="width:70%;border:1px solid #cedff2;background-color:#f5fffa;vertical-align:top"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top;background-color:#f5fffa"
|-valign="top"
| <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;">Paparazzi Autopilots</h2>
|-
|Hardware support for Autopilot versions currently in use.
|-
|[[Image:tiny13_family_top_sm.jpg|center|400px|Tiny 1.1 autopilots on the "assembly line"]]
|-
|<h2>When will the Schematics, CAD files, Gerber files, BOM be released?</h2>
|-
|<h3>The hardware development and release process.</h3>

<P>8 June 2011 13:25:47 Antoine Drouin wrote on the mailing list:</P>

Schematics will be released ASAP, CAD files will come later. When ? I don't know.... Worst case would be when Joby Robotics releases a new version of the board, but I hope it will be sooner than that.

Lisa/L CAD files have been released (http://svn.savannah.nongnu.org/viewvc/paparazzi-hardware/trunk/lisa/v1.1/?root=paparazzi ) 3 month ago. (...)

I've started this project together with Pascal 8 years ago and since then I have dedicated my time to try and make it successful. I'm utterly convinced of the benefits of open source, but observing how Paparazzi grew over time, I came to the conclusion that hardware is a bit different than software... "gcc tiny.brd" is not going to make a board magically appear on your desktop.

I'll list here some of my arguments in favor of releasing CAD files after the board is mature.
# Unlike software, where an unskilled user can type make and get a piece of complex software to successfully build, assembling hardware requires tools and skills. Providing gerbers and BOM have lured a bunch of new users into believing otherwise and has created tons of frustration. I've myself fixed a number of badly assembled boards and I even recall that while helping debugging a board (so after assembly), discovering that the person had manufactured two layers PCBs instead of four layers. As the technology of the autopilot increases, this problem becomes more and more important.
# The success of the project depends on the availability of affordable hardware. The price of hardware is directly and exponentially dependent on the number of manufactured units. If ten persons manufacture 10 boards each, the cost will be much higher than if one person manufactures 100.
# Last and not least, the quality of assembly also depends very much on the number of manufactured units. Good quality can only be achieved through the use of automated placing and soldering, and those processes can only be used if the number of units reach a certain amount.

|}
|}

[[Category:Hardware]] [[Category:User_Documentation]]

Sensors/GPS

2010-03-02T19:04:16Z

Mcurrie: /* u-Blox LEA Series Receivers */

{| align=right
|-
| __TOC__
|}

==Overview==
[[Image:U-blox_color_warm_60.gif|100px]]

Paparazzi autopilots are designed around the popular [http://www.u-blox.com u-blox] brand of receivers.

*Features:
**Small size
**Excellent performance
**4Hz position update rate

The '''[[Tiny]]''' features an onboard LEA series GPS receiver and patch antenna, while '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below. Both modules have proven reliable and robust.

{|align = center
|-
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]
|}

'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/gps_ubx.c</tt>. Other GPS brands would require a similar parsing file to be written for NMEA or other proprietary protocols.

==GPS Receivers==

===u-Blox LEA Series Receivers===
[[Image:Lea big.jpg|100px|thumb|right|u-blox LEA]]
The '''[[TWOG_v1|TWOG]]''', '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external GPS module and antenna. The '''[[Tiny]]''' features an integrated receiver and antenna. Either type is designed for [http://www.u-blox.com/ u-blox] 4 and 5 series GPS receivers and the proprietary UBX binary protocol. An external battery or capacitor is typically used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4 and LEA-5 series receivers can be used including the less expensive LEA-4A, 4S, 5A and 5S models as the special boot configuration code required for these models is already written.

*4Hz Position update rate
*Supports active or passive antennas
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]
*Low position [http://paparazzi.enac.fr/wiki_images/Gps_rx_noise.pdf noise] figure
[[Image:TINY_1.3_MCU_BOTTOM.JPG|thumb|center|250px|LEA-4P installed on the Tiny]]
<br style="clear:both">

===Paparazzi Stand-alone GPS Receivers===
[[Image:Ppzgps13_800.jpg|100px|thumb|right|Paparazzi GPS13]]
<p>Paparazzi CVS provides a design for an external GPS board (required for TWOG and Classix Autopilots).
Programming it is similar to the Tiny2.11 GPS configuration. If you build your own you will want to upload the latest u-blox firmware before you configure. See "Getting Hardware" for sources of assembled boards.</p>
<p>
The Paparazzi design in http://cvs.savannah.gnu.org/viewcvs/paparazzi/paparazzi3/hw/sensors/gps_13.brd is based on a u-blox LEA-4P however an LEA-5H seems to work just fine as well. The board is very small and light as it has only the components required. It is powered from the 5v line on the "downloads" connector of a TWOG. Also note it is a 4-layer PCB that means better noise resistance. The board has pins for USB connection but requires a different cable and a solder jumper to be move from the ground (default) to 3.3v input to enable the USB port on the module.
</p>
<p>
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM.xls]<br>
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output.txt]<br>
See [[Get_Hardware|Get Hardware]] page for suppliers.
</p>
==== Wiring Diagram ====
[[Image:TWOG to GPS.jpg|thumb|left]]
<br><br><br><br><br><br><br><br><br><br><br><br>

----

===3rd Party u-blox reference design boards:===
<p>
[[Image:LEA5HExternalModulePinout.jpg|100px|thumb|right|LEA-5H Full Board Pinout]]
The only other GPS board in use seems to be u-blox reference designs or similar to it. They have either LEA-4P or LEA-5H (typically) and several interfaces. Often a larger antenna as well.
</p>

If this needs fixing don't be shy, fix away.

<br style="clear:both;" />

===NAVILOCK NL-507ETTL===
[[Image:Navilock NL-507ETTL.jpg|thumb|left|NAVILOCK NL-507TTL]]
The NAVILOCK NL-507TTL u-blox TTL Modul 60416 features an LEA-4 series receiver and 25mm patch antenna on a 30mm x 30mm board.
* Datasheet: [http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481 http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481]
* Purchase: Available for 28€ at [http://www.amazon.de/Navilock-NL-507TTL-u-blox-TTL-Modul/dp/B0011E6VQG www.amazon.de]
<br style="clear:both;" />

===SPK GS406===
[[Image:GS406.jpg|thumb|left|SPK GS406 with LEA-5]]
[http://www.sparkfun.com/commerce/product_info.php?products_id=8889 Sparkfun] sells a nice small module featuring the newer 5-series receiver and the highly rated Sarantel antenna for about $90. The design is based around the active version of the Sarantel instead of the more appropriate passive model and there's some potentially tricky soldering involved to get around the ribbon cable but the price is great for this hardware.

[http://store.diydrones.com/ProductDetails.asp?ProductCode=BR-0008-01 DIYDrones] has build a adapter board for this GPS module. It looks like a great solution to use this GPS module with Paparazzi.

[http://ppzuav.com/osc/catalog/product_info.php?cPath=13_8&products_id=95 PPZUAV ] Also has the newer Active Sarantel Antenna model ready to connect to the TWOG (and programmed for Paparazzi).
<br style="clear:both;"/>

===u-Blox C04-5H Reference Design===
[[Image:abavimage.jpg|100px|thumb|left|u-blox C04-5H]]
u-Blox sells a complete module with antenna for around $200 and will also provide complete schematics, BOM, and PCB files for free if you wish to make your own. Two versions are offered, one with an 18mm patch antenna and the other with the Sarantel P2 helical antenna.
See [http://www.u-blox.com/products/c04_5h.html http://www.u-blox.com/products/c04_5h.html] for more info.
<br style="clear:both;" />

====Connecting external receivers to Classix, 1.2.1, Lite, and RoboStix boards====

The u-blox receivers require 3.3v power and all current models have 5V tolerant data lines. The best way to connect to the SAM-LS is to remove the bottom case and solder the 4 wires directly to the TIM-LL module (GND (pin 1) ,VCC (pin 2),TX (Pin 5),RX (pin 4)) check the TIM-LL datasheet for pinout diagrams.[http://www.u-blox.com/products/Data_Sheets/TIM-LL_Data_Sheet(GPS.G3-MS3-04035).pdf] The Classix and Lite boards feature a 3.3V regulator to power the GPS.
To open the casing on a SAM-LS, remove the bottom of the casing by pulling gently, then work around popping off the solder joints (they are fairly weak) by pressing a small screwdriver against each tab in turn until it pops off. You should then be able to access the GPS chip directly.

===Sourcing from u-blox===

u-blox keeps tight control over the distribution of their products. They must be obtained DIRECTLY from their own reseller offices. These offices may not be available in your area, for example Canada does not have a reseller. Sample quantities can be obtained from uBlox but overnight or 2 day shipping is required which drives the cost up considerably. While it is a large hassle obtaining these devices, it is undoubtedly worth it.

Talking with ublox sale for two years, Confirmed, that Order is possiable Directly from ublox, by knowing what project it was for & how was it to be use. After long reply waiting time, the answer was: - YES, but at least 2K-3K in volume, otherwise they're not interested. Like to share the order ? It is 500pcs/Roll.

===Other potential source of u-blox GPS===

There seems to be a few alternative source of u-blox GPS out there. They are considerably cheaper then the samples u-blox offers (at least in america). We didn't buy from these sources yet. Do not take this as a recommandation, we do not know the level of service they offer, etc.

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error )
*http://www.expedienttech.com/product.htm ( Singapore )

==GPS configuration using U-Center==

[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers.
* [http://www.u-blox.com/en/evaluation-tools-a-software/u-center/u-center.html Download u-center]

* Note 1: You must [[Compiling#USB_flashing|install the UART tunnel]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].

* Note 2: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].

* Note 3: You can run u-center on Linux by installing "Wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and set up COM1 as /dev/ttyUSB0. You need to create a symbolic link from the COM device to TTY like this:
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1
This command will create the symbolic link from ttyUSB0 to COM1. See Info on Wine for "dosdevices" setup. Just download the u-setup.exe and run it with Wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.

The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.

* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.

Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]
<br style="clear:both">

===Uploading the Configuration File===
Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]
* [[Media:Tim-LL-V5.zip|TIM-LL]]
* [http://paparazzi.enac.fr/wiki_images/Tiny_LEA-5H-v5.zip LEA-5H (For Use w/ Firmware V5 ONLY!)]

===Manual Configuration===
If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:

====LEA-4P====

1. Right Click on the '''NMEA''' Icon and choose '''disable child'''
2. Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)
6. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)
7. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
8. UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
9. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

====LEA-5H====

1. Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''
2. Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction.
Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better
3. UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]])
4. Change the baudrate of U-Center to 38400bps if the connection is lost at this point
5. UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.
6. UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)
7. UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black
(add the flag -DGPS_USE_LATLONG in your [[Airframe_Configuration#Hardware_definitions_-_Makefile|Airframe file]]) also make sure you set tiny_2_1_1.h if you have the latest boards Tiny/TinyWOG)
8. UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver

* Cycle the power and verify that the new configuration was saved
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.

#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH. Additionally, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file.

===Reset to Default Settings===
The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.

===DGPS (Differential GPS)===
Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.esa.int/esaNA/ESAF530VMOC_egnos_1.html WAAS, EGNOS, and MSAS regions] though only WAAS and EGNOS are officially operational. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.

====WAAS issues====
WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to completely disable WAAS.

====EGNOS issues====
EGNOS officially became operational on 1 October 2009. ESA claims that it can determine position to within 2 metres compared with about 20 metres for GPS alone. Note that the service is currently provided only in western Europe. For further information see [http://www.esa.int/esaNA/egnos.html ESA EGNOS website].

According to the [http://ec.europa.eu/transport/egnos/programme/doc/2009_egnos_sdd_os_v1.pdf EC] the EGNOS transmission will keep the "Do not use" type0/2 flag until it is certified for safety of life operations in (hopfefully) mid 2010. So you will have to enable the "Allow test mode use (Msg 0)" switch in the u-center under UBX-CFG-SBAS together with the correction to try EGNOS.

The [http://www.u-blox.com/en/faq.html u-blox FAQ] states the following:
* "Do you see issues with EGNOS?"
*:"Yes. The data transmitted by EGNOS in the past were usually good and valuable although sometimes unreliable, e.g. when system tests were performed. u-blox does not guarantee performance and status of EGNOS system. For the latest update about functionality of EGNOS please check the website: [http://www.gsa.europa.eu European GNSS Supervisory Authority]"

===Troubleshooting===

Problem: I keep getting this error with my nice shiny Tiny v2.1 with a LEA-5H:
Invalid_argument("Latlong.of_utm")

Solution: Add the flag -DGPS_USE_LATLONG to your airframe file.

===Further Reading===

The u-blox [http://www.u-blox.com/customersupport/antaris4_doc.html System Integration Manual] covers a lot of GPS theory as well as product specific topics.

== Antenna options for the Tiny and Paparazzi GPS units ==

The '''[[Tiny|Tiny 1.1]]''' features a 28mm square ground plane intended to be centered below the [[#Sangshin_13mm_Patch|Sangshin 13mm patch antenna]]. Much better performance has been seen with the 18mm antennas and an augmented ground plane. The ground plane is a critical part of the antenna affecting not only the gain and polarization characteristics but also the center frequency of the system. Users are advised to expand the ground plane to approximately 36mm square, centered on the ceramic portion of the antenna (not the pin). This can be done with copper foil soldered to the vias of the existing ground plane.
[[image:gps_antenna_comparison.jpg|thumb|500px|left|SAM-LS 25mm / Emtac 20mm / Emtac 18mm / Sangshin 18mm / Sangshin 13mm / Sarantel P2]]
<br style="clear:both">

=== Sangshin 18mm Patch ===
[[image:Sangshin_18mm.jpg|thumb|Sangshin 18mm x 4mm 1580Mhz]]
The Sangshin KSA-ST1580MS18 antenna has proven to offer the best performance of the currently available options. These are available from any Sanshin distributor such as [http://www.rfmw.com rfmw] ([http://www.rfmw.com/PortalProductDetail.aspx?ProdId=232436&fmt=1 here]) and cost approximately $6.50/ea. in small quantities.

<br style="clear:both">

=== EMTAC 18mm Patch ===
[[image:Emtac_18mm.jpg|thumb|Emtac 18mm x 4mm 1580Mhz]]
Offering identical performance to the Sangshin in a less attractive package is the Emtac 18mm antenna. The part number for the standard 1580MHz 18x18x4mm is ANA1580T18D40 and is not listed on their website. Other frequencies are available on a special order basis and the 1584Mhz has proven to outperform all other frequencies when used with a 36mm ground plane and no radome. The use of a radome (any material covering the antenna) or a larger ground plane should theoretically favor even higher frequencies.

'''Availability'''

* [http://www.transplantgps.com/modules.html TransplantGPS] in MN, USA. The 1580Mhz models are usually available at a cost of $3.55ea but there may be a minimum order requirement of ~$50 USD.

=== Sangshin 13mm Patch ===

[[image:Sangshin_13mm_onboard.jpg|thumb|Sangshin 13mm x 4mm 1580Mhz]]
Part of interest: '''[http://www.sangshinec.com/eng/patch_spec.htm KSA-ST1580MS13]'''

The Tiny 0.99 (not 0.9) and 1.1 were designed around this antenna but users are advised to install 18mm units for better performance.

Size: 13 x 13 mm<br/>
Center Frequency: 1580 MHz<br/>
Bandwidth: 5 MHz<br/>
@Fo: -15 dB<br/>
GAIN (dBi): 0 dBi<br/>
Ground Plane: 50 x 50 mm<br/>

'''Available From'''

[http://www.systroninc.com/ Systronic INC.] - Alberta, Canada
<br style="clear:both">

=== Emtac 20mm Patch ===

[[image:Salvaged_20mm_onboard.jpg|thumb|Emtac 20mm x 4mm]]
The Tiny 0.9 was designed around this 1583Mhz antenna and performed extremely well. Emtac has replaced this with an 18mm model that they claim offers even better performance.

* Obsolete
<br style="clear:both">

=== Spectrum Control Patch ===

[[image:PDC_Tiny21_S1.jpg|thumb|Spectrum Control 25mm]]
25mm patch testing on Tiny v2.1. Manufacturer Part Number [http://www.specemc.com/docs/antenna_catalog.pdf PA251575008SALF]. These are available from Mouser for about $3: [http://www.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMukjKvgqb7HxzmcutVCLrkxFUj/3HCdKwE%3d 657-PA251575008SALF]

<br style="clear:both">

=== Sarantel GeoHelix-P2 ===

[[image:Geohelix-p2.jpg|thumb|Sarantel Geohelix P-2 1575Mhz]]

This antenna is popular among UAV designers due to it's natural rejection of other radio frequencies such as those originating from the modem or video system as well as it's improved rejection of signals reflected from the ground. U-blox recommends this antenna and features it in their [http://www.u-blox.com/news/sarantel.html reference design]. Frequency and polarization are not dependent upon ground plane geometry so this antenna is sold only in the true GPS frequency of 1575Mhz.
The geometry makes this antenna very inconvenient to mount, especially in an airplane. Some very non-scientific testing has been done with one of these antennas connected to a Tiny with a short length of 50 Ohm coax above a 120mm square of ungrounded aluminum foil and performance was adequate. The helical design should theoretically outperform a patch in the air, but not on the ground, so any organized comparison will be difficult. Possibly the most important aspect of this antenna is it's natural RFI filtering, which should be evaluated further.

* [http://www.sarantel.com/products/geohelix-p2 GeoHelix-P2] Passive GPS Antenna [[http://www.sarantel.com/downloads/specifications/geohelix-p2.pdf datasheet]]

'''Availability'''

* Sarantel @ cost of approx $18 USD each (active versions available for ~$40)
<br style="clear:both">

User:Mcurrie

2009-10-11T21:51:09Z

Mcurrie: /* WIKI Contributions */

User:Mcurrie

2009-10-11T21:49:42Z

Mcurrie: /* TODO / PROGRESS */

== Matthew Currie ==

* IRC Nick: dc3<br/>
* Location: Nanaimo, British Columbia, Canada
* Member Since: November 2006

Built 13+ Tiny 13 v1.1 autopilot boards in-house. Distributed boards into the group to break-even.

=Setup=

==Airframe and Powerplant==

* Multiplex Funjet
* AXI 2212/26 Brushless "outrunner" Motor
* LiPower Lites 3S1P 2100mAh 18C LiPo Batteries x 2
* APC 9x6E Propeller (checked to draw ~ 11.5A)

==Electronics==

* Castle Creations Phoenix 35 Brushless Speed Control
* Castle Creations USB Programming Harness
* Berg 4L Receiver modified for PPM stream
* 2x Hitec HS-55 Servos
* Maxstream (now digi) XBee 2.4GHz Pro modems + devkit
* Modified FMA CoPilot XY and Z IR Sensor Boards
* Hitec Eclipse 7 Radio with Spectra PLL Module (btw the Spectra module is HORRIBLE)

==Production and Tooling==

* Hot Air Reflow Rework Station
* SMT Soldering Station
* Molex PicoBlade Crimpers
* Molex Micro-Fit 3.0 Crimpers
* 10-20 of each of every PicoBlade and MicroFit connectors
* Various Alpha 26 AWG Teflon Hook-up Wire

==Field==

* 110Ah Marine Deep Cycle Battery
* Folding Picnic Table (yes, exactly the same as poines!)
* Great Planes Triton multi-chemistry charger
* Custom waterproof data modem enclosure with type-N connector and 25 foot RS232 cable
* Various Pelican transport cases

==Current Progress==

* Airframe / Ground Station Complete
* Basic AUTO1 tuning, not satisfactory, will continue

==ToDo==

* Order 12 dBi yagi

=== WIKI Contributions ===

this is just a scratch pad of notes, etc.. might as well put them on the wiki so other can drop in on them..

Tiny13 1.1 draws 34mAh from the main supply when powered by 18V.

'''Q:''' [Tiny 1.1] I get error accessing USB when trying to load code to the Autopilot

'''A:''' You need to copy a USB rules file following the instructions below '''update: this did not appear to solve the problem. not sure why I figured it did.'''

# cd ''[paparazzi3 folder]''
# cp conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

'''Q:''' [Tiny 0.9-1.1] What is the command to compile the ARM7 code?

A: the two relevant commands are below. Replace [AIRCRAFT] with the name of your aircraft.

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.compile

to download code that has already been compiled

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.upload

'''Q:''' How do I get GCS to talk to the AP with straight serial and not a modem?

'''A:''' Here is an example of a section of my paparazzi3/conf/control_panel.xml

<session name="4 Matt Flight">
<program name="link">
<arg flag="-d" constant="/dev/ttyUSB0"/>
<arg flag="-transport" constant="pprz"/>
<arg flag="-uplink" constant=""/>
</program>
<program name="server"/>
<program name="gcs"/>
</session>

'''Q:''' How do I load the USB Bootloader onto the Tiny?

'''A:''' Start by wiring up 3.3V RS232 from the PC to the Tiny.

The serial lines on the ARM7 micro are 5V tolerant so if it helps cut down on complexity/parts you could use 5V RS232 for this. ''Optional: You could also form a basic resistor voltage divider on the PC TX -> AP RX''

*PC SERIAL_TX -> LPC_RXD_0 (SERIAL_1-7)
*PC SERIAL_RX -> LPC_TXD_0 (SERIAL_1-8)
*PC SERIAL_GND -> GND (SERIAL_1-1)
*LPC_P0.14 (SERIAL_1-5) must be asserted low (held to ground) while the Tiny powers up in order to enter the Serial Boot Loader. (You could also wire this to a pushbutton which ties it to ground, holding this button briefly while you power up the AP. This pin does not need to stay low during the programming or any time afterwards)

once these connections have been made, execute this command in a console

# make PROC=GENERIC upload_bl

[[Category:Members]]

FunJet

2009-10-03T19:51:24Z

Mcurrie: /* Misc Notes */

[http://www.recherche.enac.fr/paparazzi/wiki/index.php/Airframes <<] Back to Airframes

{|
|-valign="top"
|[[Image:Funjet_flight_dawnron1.jpg|thumb|left|Multiplex FunJet]]
|
The MultiPlex FunJet is an electric pusher-prop jet made of very durable Elapor Particle Foam Construction. It offers plenty of room internally for avionics in an attractive package.
|}

== Features ==

* Suggested Retail Price of $65 USD
* Elapor Particle Foam construction
* Assembles in minutes with only Medium CA glue
* Fiberglass Wing Spar
* Moderately priced
* Detachable canopy for access to internals
* Plastic Motor Mount
* Wide flight speed envelope (slow without stalling, through fast)

== Specifications ==

* Wingspan: 31.29" (795mm)
* Wing Area: 232 sq in (15 sq dm)
* Weight: 21oz (620g) _all up_
* Weight w/o powerplant (for estimation): 330g
* Bare weight: 165g
* Length: 29.52" (750mm)
* Airfoils: Airfoil: Semi-symmetrical, mid wing at the fuselage sides

=== Payload Area ===

* Fuselage is 1.60" (40.6mm) wide x 20" long

== Recommended Setups ==

=== Manufacturer Recommendation ===

Remember this is a hot sport plane so the manufacturers recommendation reflects typical desired performance and may not be the best match for UAV operations.

* Motor: Himax HB2815-3000 Brushless Motor
* Battery: 3S1P 2100-3200mah LiPo
* Servos: 2 Nano sized (HS-55)

=== Group Member Setups ===

'''Martin'''

* Motor: AXI 2212/26
* Battery: 3S1P 2100mAh LiPo
* Prop: 9x6

'''Matthew Currie'''

{|
|[[Image:FJ_MC_ANGLE.jpg|thumb|left|Multiplex FunJet]]
|[[Image:FJ_MC_SIDE.jpg|thumb|left|Multiplex FunJet]]
|[[Image:FJ_UNDERSIDE.JPG|thumb|left|Multiplex FunJet]]
|}

* Motor: AXI 2212/26
* Battery: LiPower Lites 3S1P 2100mAh 18C LiPo
* Prop: APC 9x6E (checked to draw ~ 11.5A)
* Receiver: Berg 4L
* Servos: 2x Hitec HS-55

=== Servos ===

Multiplex calls for 2 Hitec HS-55 or 2 HS-65 servos

=== Hitec HS-55 ===

* MSRP: $13 USD
* Torque: 13/16 oz/in @ 4.8/6.0v
* Speed: 0.09/0.08 seconds/ 60deg @ 4.8/6.0v
* Weight: 0.29 oz (7.8g)
* Size: 0.9 x 0.46 x 0.95"

=== Hitec HS-65HB ===

* MSRP:
* Motor Type: 3 Pole Ferrite
* Bearing Type: Top Ball Bearing
* Torque 4.8/6.0v: 22 / 26 oz (1.6 / 1.9 kg.)
* Speed 4.8/6.0v: 0.16 / 0.13 second
* Size: 0.9"x 0.5"x 0.9" (24 x 12 x 24m)
* Weigh : 0.39oz. 11.2 g.

== Recommended Motors ==
'''Himax HB2815-3000 Brushless Motor'''

[http://www.maxxprod.com/pdf/HB2815-xx00.pdf PDF Datasheet]

* MSRP $69.95 USD
* Dimensions: 27mm x 38mm
* Weight: 86g
* KV: 3000
* Max Amps: 30A
* Max Watts: 275W

'''AXI 2212/26'''

http://www.modelmotors.cz/index.php?page=61&product=2212&serie=26&line=GOLD

MSRP $69.95 USD
* Dimensions: 1-3/32" diameter, 1-3/16" case length, 3.17mm (1/8") shaft
* Weight: 57 g
* KV: 920
* Max Amps: 12A
* Max Watts: 275W
* Prop's:
9x6, 24.5 ounce thrust, 14:12 full throttle.

8x6, 19.5 ounce thrust, 19:38 full throttle.

== Funjet Back Plate Construction ==
{|
|[[Image:Funjet_Back_Plate_Components.jpg|thumb|left|Funjet back plate construction components]]
|}

* A suitable precursor for the back plate is 5mmx75mmx75mm balsa sandwiched by 1mmx75mmx75mm plywood. The laminating adhesive used was PVA glue. The sandwich was left to dry overnight clamped by similar size wooden plates in a vice.

* An outline of The 7mm elapor profile, cut from the back of the Funjet canopy, is drawn in a CAD/CAM program.
:*download ''[[Media:Funjet_Back_Plate_CADopia.pdf|Funjet back plate CADopia drawing (pdf)]]''

* A laser cutting firm transferred this outline to CorelDraw and cut an acrylic (Perspex) template.
:*download ''[[Media:Funjet_Back_Plate_CorelDraw .pdf|Funjet back plate CorelDraw drawing (pdf)]]''

* The balsa/plywood sandwich was attached by double sided tape to the acrylic template and the correct outline achieved by routing around the acrylic border.

{|
|[[Image:Funjet_Back_Plate_Fitted.jpg|thumb|left|Funjet back plate fitted]]
|[[Image:Tiny_v2_1_Funjet.jpg|thumb|left|Tiny v2.1 in a Funjet]]
|}
* The fitted plate looks remarkably similar to that displayed in the image on the right found on the main page of the wiki.

== Online Discussion on FunJet topics ==

* [http://www.rcgroups.com/forums/showpost.php?p=7257031&postcount=2856 Modifying the motor cowling to increase airflow]
* [http://www.rcgroups.com/forums/showthread.php?p=7593625#post7593625 Adding prop spacers to move prop further back]
* [http://www.rcgroups.com/forums/showpost.php?p=7081811&postcount=2582 Mounting a MicroDan 2505 Brushless Outrunner]

== Photos ==

{|
|-
|[[Image:Jet-motor-mount.jpg|thumb|Included Motor Mount]]
|[[Image:Funjet_highvis1_rycomm.jpg|thumb|Example of high visibility paint job]]
|[[Image:Funjet tipprotector sharkbyte.jpg|thumb|Idea for wing tip skid]]
|}

== Misc Notes ==

* [http://www.recherche.enac.fr/paparazzi/wiki_images/FunJet_Manual_English.pdf Multiplex FunJet Instruction Manual - English]
* [http://www.recherche.enac.fr/paparazzi/wiki_images/FunJet_Manual_Multilanguage.pdf Multiplex FunJet Instruction Manual - Original Multilanguage]
* Painting Elapor should be primed [http://www.phillsmodels.com/acatalog/index.html?http%3A//www.phillsmodels.com/acatalog/Online_Catalogue_Paint_882.html&CatalogBody primer]
* Fiberglass wing spar: 22.5" (571mm) x .25" (6.35mm)
* Motor Screws (to hold plastic motor plate to plastic motor cowl) are slot head and appear to be 3.0mm x 0.5mm (thread) x 16mm long
* Screws for AXI "outrunner" motor are 3.0mm Diameter x 0.5mm Thread x 6 mm Length

FunJet

2009-10-03T19:50:50Z

Mcurrie: /* Misc Notes */

[http://www.recherche.enac.fr/paparazzi/wiki/index.php/Airframes <<] Back to Airframes

{|
|-valign="top"
|[[Image:Funjet_flight_dawnron1.jpg|thumb|left|Multiplex FunJet]]
|
The MultiPlex FunJet is an electric pusher-prop jet made of very durable Elapor Particle Foam Construction. It offers plenty of room internally for avionics in an attractive package.
|}

== Features ==

* Suggested Retail Price of $65 USD
* Elapor Particle Foam construction
* Assembles in minutes with only Medium CA glue
* Fiberglass Wing Spar
* Moderately priced
* Detachable canopy for access to internals
* Plastic Motor Mount
* Wide flight speed envelope (slow without stalling, through fast)

== Specifications ==

* Wingspan: 31.29" (795mm)
* Wing Area: 232 sq in (15 sq dm)
* Weight: 21oz (620g) _all up_
* Weight w/o powerplant (for estimation): 330g
* Bare weight: 165g
* Length: 29.52" (750mm)
* Airfoils: Airfoil: Semi-symmetrical, mid wing at the fuselage sides

=== Payload Area ===

* Fuselage is 1.60" (40.6mm) wide x 20" long

== Recommended Setups ==

=== Manufacturer Recommendation ===

Remember this is a hot sport plane so the manufacturers recommendation reflects typical desired performance and may not be the best match for UAV operations.

* Motor: Himax HB2815-3000 Brushless Motor
* Battery: 3S1P 2100-3200mah LiPo
* Servos: 2 Nano sized (HS-55)

=== Group Member Setups ===

'''Martin'''

* Motor: AXI 2212/26
* Battery: 3S1P 2100mAh LiPo
* Prop: 9x6

'''Matthew Currie'''

{|
|[[Image:FJ_MC_ANGLE.jpg|thumb|left|Multiplex FunJet]]
|[[Image:FJ_MC_SIDE.jpg|thumb|left|Multiplex FunJet]]
|[[Image:FJ_UNDERSIDE.JPG|thumb|left|Multiplex FunJet]]
|}

* Motor: AXI 2212/26
* Battery: LiPower Lites 3S1P 2100mAh 18C LiPo
* Prop: APC 9x6E (checked to draw ~ 11.5A)
* Receiver: Berg 4L
* Servos: 2x Hitec HS-55

=== Servos ===

Multiplex calls for 2 Hitec HS-55 or 2 HS-65 servos

=== Hitec HS-55 ===

* MSRP: $13 USD
* Torque: 13/16 oz/in @ 4.8/6.0v
* Speed: 0.09/0.08 seconds/ 60deg @ 4.8/6.0v
* Weight: 0.29 oz (7.8g)
* Size: 0.9 x 0.46 x 0.95"

=== Hitec HS-65HB ===

* MSRP:
* Motor Type: 3 Pole Ferrite
* Bearing Type: Top Ball Bearing
* Torque 4.8/6.0v: 22 / 26 oz (1.6 / 1.9 kg.)
* Speed 4.8/6.0v: 0.16 / 0.13 second
* Size: 0.9"x 0.5"x 0.9" (24 x 12 x 24m)
* Weigh : 0.39oz. 11.2 g.

== Recommended Motors ==
'''Himax HB2815-3000 Brushless Motor'''

[http://www.maxxprod.com/pdf/HB2815-xx00.pdf PDF Datasheet]

* MSRP $69.95 USD
* Dimensions: 27mm x 38mm
* Weight: 86g
* KV: 3000
* Max Amps: 30A
* Max Watts: 275W

'''AXI 2212/26'''

http://www.modelmotors.cz/index.php?page=61&product=2212&serie=26&line=GOLD

MSRP $69.95 USD
* Dimensions: 1-3/32" diameter, 1-3/16" case length, 3.17mm (1/8") shaft
* Weight: 57 g
* KV: 920
* Max Amps: 12A
* Max Watts: 275W
* Prop's:
9x6, 24.5 ounce thrust, 14:12 full throttle.

8x6, 19.5 ounce thrust, 19:38 full throttle.

== Funjet Back Plate Construction ==
{|
|[[Image:Funjet_Back_Plate_Components.jpg|thumb|left|Funjet back plate construction components]]
|}

* A suitable precursor for the back plate is 5mmx75mmx75mm balsa sandwiched by 1mmx75mmx75mm plywood. The laminating adhesive used was PVA glue. The sandwich was left to dry overnight clamped by similar size wooden plates in a vice.

* An outline of The 7mm elapor profile, cut from the back of the Funjet canopy, is drawn in a CAD/CAM program.
:*download ''[[Media:Funjet_Back_Plate_CADopia.pdf|Funjet back plate CADopia drawing (pdf)]]''

* A laser cutting firm transferred this outline to CorelDraw and cut an acrylic (Perspex) template.
:*download ''[[Media:Funjet_Back_Plate_CorelDraw .pdf|Funjet back plate CorelDraw drawing (pdf)]]''

* The balsa/plywood sandwich was attached by double sided tape to the acrylic template and the correct outline achieved by routing around the acrylic border.

{|
|[[Image:Funjet_Back_Plate_Fitted.jpg|thumb|left|Funjet back plate fitted]]
|[[Image:Tiny_v2_1_Funjet.jpg|thumb|left|Tiny v2.1 in a Funjet]]
|}
* The fitted plate looks remarkably similar to that displayed in the image on the right found on the main page of the wiki.

== Online Discussion on FunJet topics ==

* [http://www.rcgroups.com/forums/showpost.php?p=7257031&postcount=2856 Modifying the motor cowling to increase airflow]
* [http://www.rcgroups.com/forums/showthread.php?p=7593625#post7593625 Adding prop spacers to move prop further back]
* [http://www.rcgroups.com/forums/showpost.php?p=7081811&postcount=2582 Mounting a MicroDan 2505 Brushless Outrunner]

== Photos ==

{|
|-
|[[Image:Jet-motor-mount.jpg|thumb|Included Motor Mount]]
|[[Image:Funjet_highvis1_rycomm.jpg|thumb|Example of high visibility paint job]]
|[[Image:Funjet tipprotector sharkbyte.jpg|thumb|Idea for wing tip skid]]
|}

== Misc Notes ==

* [http://www.recherche.enac.fr/paparazzi/wiki_images/FunJet_Manual_English.pdf Multiplex FunJet Instruction Manual - English]
* [http://www.recherche.enac.fr/paparazzi/wiki_images/FunJet_Manual_Multilanguage.pdf Multiplex FunJet Instruction Manual - Original Multilanguage]
* Painting Elapor should be primed [http://www.phillsmodels.com/acatalog/index.html?http%3A//www.phillsmodels.com/acatalog/Online_Catalogue_Paint_882.html&CatalogBody primer]

* Fiberglass wing spar: 22.5" (571mm) x .25" (6.35mm)
* Motor Screws (to hold plastic motor plate to plastic motor cowl) are slot head and appear to be 3.0mm x 0.5mm (thread) x 16mm long
* Screws for AXI "outrunner" motor are 3.0mm Diameter x 0.5mm Thread x 6 mm Length

Users

2009-09-19T04:41:35Z

Mcurrie: /* North America */

Please add yourself to this list if you wish to share who you are and what you are doing with Paparazzi

==Need help adding your information?==
To have your information added by another paparazzi user, please send me an [http://www.rcgroups.com/forums/showpost.php?p=6575288&postcount=1 EMAIL] at with the
following:

*Name
*Email
*Location
*Hardware
*Join date
*Current activities / project status

== Wiki pages ==
add a link to your users wiki page.

[http://paparazzi.enac.fr/wiki/User:Dconger Dconger]

[http://paparazzi.enac.fr/wiki/User:MarcusWolschon MarcusWolschon]

[http://paparazzi.enac.fr/wiki/User:Alfamyke Alfamyke]

[http://paparazzi.enac.fr/wiki/User:Danstah Danstah]

[http://paparazzi.enac.fr/wiki/User:Martinmm Martinmm]

[http://paparazzi.enac.fr/wiki/User:John_Burt John Burt]

[http://paparazzi.enac.fr/wiki/User:SilaS SilaS]

[http://paparazzi.enac.fr/wiki/User:Mecevans Mecevans]

[http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU-FCUAV]

[http://paparazzi.enac.fr/wiki/User:GPH Pierre-Selim]

[http://paparazzi.enac.fr/wiki/User:Martinpi martinpi]

[http://paparazzi.enac.fr/wiki/User:VAMK VAMK]

[http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison]

==Asia==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ Asia
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:mnwxiaobao@gmail.com MNW]|| China || Tiny2.11 ||| 2009 || Just starting,having troubles with parts.
|- style="background:bisque; color:black"
| [mailto:shubhamearly@gmail.com Shubham]|| India || Tiny2.11 ||| 2009 || Writing the configuration code for airframe
|- style="background:bisque; color:black"
| [mailto:mundhra@gmail.com M Mundhra] || India || Tiny 1.3 ||| 2007 || Gain tuning on a flying wing configuration airframe
|- style="background:bisque; color:black"
| [mailto:ngkiangloong_at_hopetechnik.com Jianlun]|| Singapore || TWOG V1 ||| 2008 || trying to get TWOG onto an EasyStar. very much a newbie!
|- style="background:bisque; color:black"
| [mailto:praxmail@gmail.com prashanth] || India || Tiny 2.11 ||| 2008 || 6 autonomous flights till now, currently build a new wing like funjet
|- style="background:bisque; color:black"
| [mailto:spencerpangborn@gmail.com spencer] || Taipei, Taiwan || none ||| 2009 || research for now, hope to take aerial photos of Taipei City soon
|}

==Europe==
{| class="wikitable" style="text-align:center;background:black; color:blue"

! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:silas_at_silas.hu SilaS] || Budapest || Tiny 1.3 ||| 2007 || Applied tiny to GWS Estarter, finished long travels in AUTO2. Now transfert it to a Twinstar and working on pairing tiny with FPV.

|- style="background:bisque; color:black"
| [mailto:st.jr_at_gmx.at TomS] || Graz, Austria || Tiny 2.11 ||| 2008 || Starting to complete the wiring for the tiny and then trying to apply it to my TwinStar II.

|- style="background:bisque; color:black"
| [mailto:markggriffin_at_gmail.com MarkG] || Geneva, Switzerland || Modified Tiny 2.11, EeePC as GCS, Multiplex FunJet ||| 2008 || Many successful flights.

|- style="background:bisque; color:black"
| [mailto:x-microdrones@2007.polytechnique.org X-MicroDrones] || Paris, France || Tiny 2.11, Quad-Tilt-Rotor VTOL ||| 2008 || Wiring completed, first flights soon... We're trying to adapt Paparazzi to a Quad-Tilt-Rotor VTOL able to perform both airplane-like and helicopter-like flights. Working on inertial measurement units implementation.

|- style="background:bisque; color:black"
| [[User:MarcusWolschon|Marcus Wolschon]] || Freiburg, Germany || Gumstix, Paraplane ||| 2008 || Porting Paparazzi to Linux-Userland with UDP-communication using mesh-networking.
UDP-Downlink working, GPS via GPSD working, Pararazzi in Linux working, Hardware still RC-only due to sensor-soldering-issues

|- style="background:bisque; color:black"
| [mailto:spam1_at_marzer.com CedricM] || Geneva, Switzerland || Tiny 2.11, Multiplex FunJet with video camera ||| 2008 || Many successful flights working on an osd module and weather probes.

|- style="background:bisque; color:black"
| [[ email = hendrix at vivodinet dot gr| Chris Efstathiou]] || Piraeus Hellas || tiny 2.11 on a Mpx EasyGlider, TWOG 1.3 on a Boomerang turbine jet ||| 2008 || The Easyglider is fully operational, still working on the jet which had his first flight with the TWOG at 25/1/2009

|- style="background:bisque; color:black"
| [[User:Flixr|FelixR]] || Edinburgh, Scotland || Booz2 quadrotor ||| 2008 || remote controlled flight, working on Kalman Filter

|- style="background:bisque; color:black"
| [mailto:azoreanuav_at_gmail.com Rui Costa] || Azores, Portugal || Outrunner Twinstar II with Tiny 2.11, Aerocomm datalink, 1W video tx ||| 2008 || Only ground test and software configuration.

|- style="background:bisque; color:black"
| [mailto:et@onyxnet.co.uk Alan K] || Middlesbrough, England || Tiny 2.11 & MaxStream ||| 2008 || Just starting.

|- style="background:bisque; color:black"
| [[User:G R|Gareth R]] || Sheffield, UK || Tiny 2.11, video, bunch of helicopters, Multiplex Mentor, Multiplex Funjet, Multiplex Fox, GWS Formosa ||| 2008 || Several AUTO2 flights, currently debugging

|- style="background:bisque; color:black"
| [mailto:sanarlab@yandex.ru Andrew Saenko] || Russia, St-Petersburg || Tiny 1.13, Tiny 2.11, 2.5 kg motorised glider, 800 g plane ||| 2007 || Automatic flight, adding own code.

|- style="background:bisque; color:black"
| [mailto:chebuzz_at_gmail.com David "Buzz" Carlson] || Cyprus || Tiny 2.11, Lynx EDF & GWS SloStick, 9XTend datalink ||| 2008 || Quite a few AUTO2 flights. Plane currently grounded due to a TX run-in with a 1 year-old. Currently working on getting new TX and completing CBP store setup.

|- style="background:bisque; color:black"
| [mailto:muralha_at_gmail.com Nuno Guedes] || Lamego, Portugal || Tiny 2.11 || 2008 || Starting

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Martinpi Martin Piehslinger] || Vienna, Austria || Tiny 2.11 || 2008 || just starting

|- style="background:bisque; color:black"
| [mailto:kostalexis@ece.upatras.gr AneMos-Group] || Patras, Greece || Tiny 2.11, Quadrotor VTOL ||| 2008 || Working on IMU, Trying to implement Constrained Control for the quadrotor trajectory flight

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:VAMK Allan Ojala (VAMK)] || Vaasa, Finland || TWOG, with AC4790 radio and LEA-5H GPS ||| 2009 || Just constructed my own first RC airplane SIG KADET.

|- style="background:bisque; color:black"
| [mailto:maik.hoepfel_at_web.de Maik Hoepfel] || Berlin, Germany || TWOG, Graupner Elektro Trainer S, Futaba 9C 35 Mhz ||| August 2009 || Getting started, planning to eventually use Paparazzi for a powered parachute

|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

==North America==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Mcurrie Matthew Currie] || Nanaimo, BC Canada || Tiny 13 v1.1 (Self-built) ||| November 2006 || Funjet + XBee

|- style="background:bisque; color:black"
| [mailto:pauldanielcox_at_gmail_dot_com Paul Cox]
|Vancouver, WA [http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=98663&sll=37.0625,-95.677068&sspn=64.664844,101.953125&ie=UTF8&ll=45.606112,-122.643471&spn=0.222411,0.398254&z=12 <span title="Google Map of 98663">98663</span>]
| Tiny v2.11 || Nov. 2008 || GWS Slow Stick flying in AUTO2 reliably. Starting on stabilized video and payload drops Skype: pauldanielcox Gtalk: [use email]

|- style="background:bisque; color:black"
| [mailto:quill_at_u.washington.edu John Burt] [http://paparazzi.enac.fr/wiki/User:John_Burt wiki page]|| Portland, Oregon || Tiny v2.11 + LEA-4H (PPZUAV), Multiplex Cularis/Easystar, 9Xtend modem, T7CAP TX, ground station: EEE PC701 and/or Nokia N810 ||| Jan 2009 || Initial flight tests w/ Easystar in AUTO1 & AUTO2.

|- style="background:bisque; color:black"
| [mailto:ogar0007@umn.edu Pat O'Gara] || St. Paul, MN || Tiny 2.11 and TWOG (PPZUAV) |||Oct. 2008 || Completed and flown FunJet and Minimag in Auto 2. Currently rebuilding MiniMag as an improved development platform.

|- style="background:bisque; color:black"
| [mailto:kochesj@gvsu.edu John Koches] || Muskegon, Michigan || Tiny 2.11 (PPZUAV) ||| 2007 || currently flying a 48 inch zagi, 80 inch under construction.

|- style="background:bisque; color:black"
| [mailto:Stdeguir@gmail.com Steve Deguir] || New York,New York || Tiny2.11+LEA-5H (PPZUAV), XbeePro 2.4, Berg4L, JR FMA ||| Feb 2009 ||

|- style="background:bisque; color:black"
| [mailto:bmw330i@me.com David Conger] || San Diego (Ramona), California || Tiny1.3 (PPZUAV) ||| Sept 2007 || Flying Wing MAV with onboard video. Test platform for the new 900mhz XBPro 900 RF modems.

|- style="background:bisque; color:black"
| [mailto:mecevans@gmail.com Michael Evans] || Seaside(Monterey Bay), California || Tiny2.11 (PPZUAV) ||| Feb 2009 ||http://www.rcgroups.com/forums/showthread.php?t=1000937.

|- style="background:bisque; color:black"
| USU AggieAir Remote Sensing || Logan, UT || TWOG (PPZUAV) ||| January 2009 || Building 72" Flying Wings which will be used for remote sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://www.engr.usu.edu/wiki/index.php/OSAM USU OSAM-UAV] || Logan, UT || TWOG (PPZUAV) ||| June 2007 || 2x72" 5x48" 1x60" Flying Wings. Research backyard for AggieAir Remote Sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU Fuel Cell UAV] || Fort Collins, Co || Tiny 2.11 + LEA-5H (PPZUAV), 2.4Ghz XBPro ||| Mar 2009 || Maiden flight complete Feb 28. New Airframe in development.

|- style="background:bisque; color:black"
| [mailto:armz12@gmail.com Armen Gharibans] || La Jolla, California || Tiny2.11 (PPZUAV) ||| March 2009 || UCSD Project with Multiplex Mentor. Completed August 2, 2009. Several Successful Auto2 Flights. A LOT of help from David Conger.

|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

==Central America==

{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:joschau@comcast.net Joekadet] || David Panama' || Tiny v2.11/LEA-4P, RF Modems XBee Pro 2.4 GHz (PPZUAV). Multiplex Mentor ||| 2008 || Seven flights now. Flights 6 & 7 in Auto2. Now only a matter of fine tuning.
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

==Australia==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:todd_soaring@yahoo.com.au Todd Sandercock] || Adelaide, SA || Tiny v2.11, Multiplex Twinjet, 9Xtend modems ||| Jan 2008 || Completed successful flight testing. Now designing new airframe.
|- style="background:bisque; color:black"
| [mailto:reubenb87@gmail.com Reuben Brown]|| Gawler, SA || Tiny v2.11 ||| May 2009 || Getting the autopilot set up
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison] || Neutral Bay, NSW || Tiny v2.11, Vertical + Horizontal IR sensors, XBee PRO modems, Futaba T6EXAP TX, Futaba R136F RX, Funjet, MacBook laptop ||| August 2008 || Configuring before first flight.
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rufus Chris Gough] || Canberra || TWOG v2.11, EZ* || September 09 || not yet airborn
|}

==Africa==

{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:w1_th@yahoo.com W1th] || South Africa KZN || TWOG V1 ,LEA-5H GPS , RF Modems XBee Pro 868 (CheBuzz) ||| July 2009 || New to this , Got TWOG,GPS etc interfacing with Laptop and working ..Made a website [http://www.best-bargains.co.za/scarf/paparazzi.html SCARF] of my struggle ...
|- style="background:bisque; color:black"
|}

Links

2009-09-19T04:40:14Z

Mcurrie: /* The IRC Chat Channel */

== The Project Page ==

The Paparazzi project is hosted at http://www.nongnu.org/paparazzi/ where the CVS repository is available.

== The IRC Chat Channel ==

Network: Freenode
Network Host: irc.freenode.net
Channel: #paparazzi

* Web Based: You can use a [http://embed.mibbit.com/?server=irc.freenode.net&channel=%23paparazzi&noServerNotices=true web-based IRC portal] that makes it easy for people to jump in from any computer. Simply enter a unique ''nickname'', and '''say hello''' to the team!
* Client Software: Download one of the many freeware/shareware IRC clients and put [irc://irc.freenode.net/#paparazzi #paparazzi] at the top of your favorites list!
*: [http://www.mirc.com mIRC] (Windows)
*: [http://www.xchat.org Xchat]

== Paparazzi Users Forum ==

These forums should not attempt to replace the wiki, but rather compliment it. Sometimes information is buried in this wiki and hard to find, this could help people know where to find it. Standard policy is to answer peoples questions by pointing them to the place on the wiki. '''If it doesn't exist, answer and then put it on the wiki'''. This way you have double the exposure to the info and it becomes easier for people to find.

http://www.azoreanuav.com/forum

http://groups.yahoo.com/group/paparazzi-autopilot/

== Paparazzi Youtube and Other Video Site Links ==

http://www.youtube.com/user/USUOSAM

== Paparazzi teams/users/contributors ==

http://www.caughey.com/uavblog/news.php?id=1

http://www.miraterre.com/index.html

http://mecano.gme.usherb.ca/~vamudes/

http://pfump.org

http://www.ismo.hs-bremen.de/dokuwiki/doku.php?id=elem:projekte:intro#semesterprojekte (German)

http://www.engr.usu.edu/wiki/index.php/OSAM

http://www.techhopups.com/

http://pixhawk.ethz.ch

http://www.rcgroups.com/forums/showthread.php?t=851820

http://www.rcgroups.com/forums/showthread.php?t=1000937

http://www.mannberg.co.uk/paparazzi/

== WikiNode ==

Related wiki are, as always, listed on the [[WikiNode]].

Links

2009-09-19T04:35:10Z

Mcurrie:

== The Project Page ==

The Paparazzi project is hosted at http://www.nongnu.org/paparazzi/ where the CVS repository is available.

== The IRC Chat Channel ==

Network: Freenode
Network Host: irc.freenode.net
Channel: #paparazzi

* Web Based: You can use a [http://embed.mibbit.com/?server=irc.freenode.net&channel=%23paparazzi&noServerNotices=true web-based IRC portal] that makes it easy for people to jump in from any computer. Simply enter a unique ''nickname'', and '''say hello''' to the team!
* Client Software: Download one of the many freeware/shareware IRC clients and put [irc://irc.freenode.net/#paparazzi #paparazzi] at the top of your favorites list!
*: [http://www.mirc.com mIRC]
*: [http://www.xchat.org Xchat]

== Paparazzi Users Forum ==

These forums should not attempt to replace the wiki, but rather compliment it. Sometimes information is buried in this wiki and hard to find, this could help people know where to find it. Standard policy is to answer peoples questions by pointing them to the place on the wiki. '''If it doesn't exist, answer and then put it on the wiki'''. This way you have double the exposure to the info and it becomes easier for people to find.

http://www.azoreanuav.com/forum

http://groups.yahoo.com/group/paparazzi-autopilot/

== Paparazzi Youtube and Other Video Site Links ==

http://www.youtube.com/user/USUOSAM

== Paparazzi teams/users/contributors ==

http://www.caughey.com/uavblog/news.php?id=1

http://www.miraterre.com/index.html

http://mecano.gme.usherb.ca/~vamudes/

http://pfump.org

http://www.ismo.hs-bremen.de/dokuwiki/doku.php?id=elem:projekte:intro#semesterprojekte (German)

http://www.engr.usu.edu/wiki/index.php/OSAM

http://www.techhopups.com/

http://pixhawk.ethz.ch

http://www.rcgroups.com/forums/showthread.php?t=851820

http://www.rcgroups.com/forums/showthread.php?t=1000937

http://www.mannberg.co.uk/paparazzi/

== WikiNode ==

Related wiki are, as always, listed on the [[WikiNode]].

User:Mcurrie

2009-09-15T07:02:37Z

Mcurrie: /* Production and Tooling */

== Matthew Currie ==

* IRC Nick: dc3<br/>
* Location: Nanaimo, British Columbia, Canada
* Member Since: November 2006

Built 13+ Tiny 13 v1.1 autopilot boards in-house. Distributed boards into the group to break-even.

=Setup=

==Airframe and Powerplant==

* Multiplex Funjet
* AXI 2212/26 Brushless "outrunner" Motor
* LiPower Lites 3S1P 2100mAh 18C LiPo Batteries x 2
* APC 9x6E Propeller (checked to draw ~ 11.5A)

==Electronics==

* Castle Creations Phoenix 35 Brushless Speed Control
* Castle Creations USB Programming Harness
* Berg 4L Receiver modified for PPM stream
* 2x Hitec HS-55 Servos
* Maxstream (now digi) XBee 2.4GHz Pro modems + devkit
* Modified FMA CoPilot XY and Z IR Sensor Boards
* Hitec Eclipse 7 Radio with Spectra PLL Module (btw the Spectra module is HORRIBLE)

==Production and Tooling==

* Hot Air Reflow Rework Station
* SMT Soldering Station
* Molex PicoBlade Crimpers
* Molex Micro-Fit 3.0 Crimpers
* 10-20 of each of every PicoBlade and MicroFit connectors
* Various Alpha 26 AWG Teflon Hook-up Wire

==Field==

* 110Ah Marine Deep Cycle Battery
* Folding Picnic Table (yes, exactly the same as poines!)
* Great Planes Triton multi-chemistry charger
* Custom waterproof data modem enclosure with type-N connector and 25 foot RS232 cable
* Various Pelican transport cases

==TODO / PROGRESS==

* Develop basic airframe file
* Complete airborne wiring harness
* Mount IR Sensors
* Order 12 dBi radome enclosed yagi
* Fly

=== WIKI Contributions ===

this is just a scratch pad of notes, etc.. might as well put them on the wiki so other can drop in on them..

Tiny13 1.1 draws 34mAh from the main supply when powered by 18V.

'''Q:''' [Tiny 1.1] I get error accessing USB when trying to load code to the Autopilot

'''A:''' You need to copy a USB rules file following the instructions below '''update: this did not appear to solve the problem. not sure why I figured it did.'''

# cd ''[paparazzi3 folder]''
# cp conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

'''Q:''' [Tiny 0.9-1.1] What is the command to compile the ARM7 code?

A: the two relevant commands are below. Replace [AIRCRAFT] with the name of your aircraft.

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.compile

to download code that has already been compiled

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.upload

'''Q:''' How do I get GCS to talk to the AP with straight serial and not a modem?

'''A:''' Here is an example of a section of my paparazzi3/conf/control_panel.xml

<session name="4 Matt Flight">
<program name="link">
<arg flag="-d" constant="/dev/ttyUSB0"/>
<arg flag="-transport" constant="pprz"/>
<arg flag="-uplink" constant=""/>
</program>
<program name="server"/>
<program name="gcs"/>
</session>

'''Q:''' How do I load the USB Bootloader onto the Tiny?

'''A:''' Start by wiring up 3.3V RS232 from the PC to the Tiny.

The serial lines on the ARM7 micro are 5V tolerant so if it helps cut down on complexity/parts you could use 5V RS232 for this. ''Optional: You could also form a basic resistor voltage divider on the PC TX -> AP RX''

*PC SERIAL_TX -> LPC_RXD_0 (SERIAL_1-7)
*PC SERIAL_RX -> LPC_TXD_0 (SERIAL_1-8)
*PC SERIAL_GND -> GND (SERIAL_1-1)
*LPC_P0.14 (SERIAL_1-5) must be asserted low (held to ground) while the Tiny powers up in order to enter the Serial Boot Loader. (You could also wire this to a pushbutton which ties it to ground, holding this button briefly while you power up the AP. This pin does not need to stay low during the programming or any time afterwards)

once these connections have been made, execute this command in a console

# make PROC=GENERIC upload_bl

[[Category:Members]]

User:Mcurrie

2009-09-15T07:01:55Z

Mcurrie: /* Matthew Currie */

== Matthew Currie ==

* IRC Nick: dc3<br/>
* Location: Nanaimo, British Columbia, Canada
* Member Since: November 2006

Built 13+ Tiny 13 v1.1 autopilot boards in-house. Distributed boards into the group to break-even.

=Setup=

==Airframe and Powerplant==

* Multiplex Funjet
* AXI 2212/26 Brushless "outrunner" Motor
* LiPower Lites 3S1P 2100mAh 18C LiPo Batteries x 2
* APC 9x6E Propeller (checked to draw ~ 11.5A)

==Electronics==

* Castle Creations Phoenix 35 Brushless Speed Control
* Castle Creations USB Programming Harness
* Berg 4L Receiver modified for PPM stream
* 2x Hitec HS-55 Servos
* Maxstream (now digi) XBee 2.4GHz Pro modems + devkit
* Modified FMA CoPilot XY and Z IR Sensor Boards
* Hitec Eclipse 7 Radio with Spectra PLL Module (btw the Spectra module is HORRIBLE)

==Production and Tooling==

* Hot Air Reflow Rework Station
* SMT Soldering Station
* Molex PicoBlade Crimpers
* Molex Micro-Fit 3.0 Crimpers
* Various Alpha 26 AWG Teflon Hook-up Wire

==Field==

* 110Ah Marine Deep Cycle Battery
* Folding Picnic Table (yes, exactly the same as poines!)
* Great Planes Triton multi-chemistry charger
* Custom waterproof data modem enclosure with type-N connector and 25 foot RS232 cable
* Various Pelican transport cases

==TODO / PROGRESS==

* Develop basic airframe file
* Complete airborne wiring harness
* Mount IR Sensors
* Order 12 dBi radome enclosed yagi
* Fly

=== WIKI Contributions ===

this is just a scratch pad of notes, etc.. might as well put them on the wiki so other can drop in on them..

Tiny13 1.1 draws 34mAh from the main supply when powered by 18V.

'''Q:''' [Tiny 1.1] I get error accessing USB when trying to load code to the Autopilot

'''A:''' You need to copy a USB rules file following the instructions below '''update: this did not appear to solve the problem. not sure why I figured it did.'''

# cd ''[paparazzi3 folder]''
# cp conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

'''Q:''' [Tiny 0.9-1.1] What is the command to compile the ARM7 code?

A: the two relevant commands are below. Replace [AIRCRAFT] with the name of your aircraft.

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.compile

to download code that has already been compiled

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.upload

'''Q:''' How do I get GCS to talk to the AP with straight serial and not a modem?

'''A:''' Here is an example of a section of my paparazzi3/conf/control_panel.xml

<session name="4 Matt Flight">
<program name="link">
<arg flag="-d" constant="/dev/ttyUSB0"/>
<arg flag="-transport" constant="pprz"/>
<arg flag="-uplink" constant=""/>
</program>
<program name="server"/>
<program name="gcs"/>
</session>

'''Q:''' How do I load the USB Bootloader onto the Tiny?

'''A:''' Start by wiring up 3.3V RS232 from the PC to the Tiny.

The serial lines on the ARM7 micro are 5V tolerant so if it helps cut down on complexity/parts you could use 5V RS232 for this. ''Optional: You could also form a basic resistor voltage divider on the PC TX -> AP RX''

*PC SERIAL_TX -> LPC_RXD_0 (SERIAL_1-7)
*PC SERIAL_RX -> LPC_TXD_0 (SERIAL_1-8)
*PC SERIAL_GND -> GND (SERIAL_1-1)
*LPC_P0.14 (SERIAL_1-5) must be asserted low (held to ground) while the Tiny powers up in order to enter the Serial Boot Loader. (You could also wire this to a pushbutton which ties it to ground, holding this button briefly while you power up the AP. This pin does not need to stay low during the programming or any time afterwards)

once these connections have been made, execute this command in a console

# make PROC=GENERIC upload_bl

[[Category:Members]]

Users

2009-09-15T06:48:31Z

Mcurrie: /* North America */

Please add yourself to this list if you wish to share who you are and what you are doing with Paparazzi

==Need help adding your information?==
To have your information added by another paparazzi user, please send me an [http://www.rcgroups.com/forums/showpost.php?p=6575288&postcount=1 EMAIL] at with the
following:

*Name
*Email
*Location
*Hardware
*Join date
*Current activities / project status

== Wiki pages ==
add a link to your users wiki page.

[http://paparazzi.enac.fr/wiki/User:Dconger Dconger]

[http://paparazzi.enac.fr/wiki/User:MarcusWolschon MarcusWolschon]

[http://paparazzi.enac.fr/wiki/User:Alfamyke Alfamyke]

[http://paparazzi.enac.fr/wiki/User:Danstah Danstah]

[http://paparazzi.enac.fr/wiki/User:Martinmm Martinmm]

[http://paparazzi.enac.fr/wiki/User:John_Burt John Burt]

[http://paparazzi.enac.fr/wiki/User:SilaS SilaS]

[http://paparazzi.enac.fr/wiki/User:Mecevans Mecevans]

[http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU-FCUAV]

[http://paparazzi.enac.fr/wiki/User:GPH Pierre-Selim]

[http://paparazzi.enac.fr/wiki/User:Martinpi martinpi]

[http://paparazzi.enac.fr/wiki/User:VAMK VAMK]

[http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison]

==Asia==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|+ Asia
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:mnwxiaobao@gmail.com MNW]|| China || Tiny2.11 ||| 2009 || Just starting,having troubles with parts.
|- style="background:bisque; color:black"
| [mailto:shubhamearly@gmail.com Shubham]|| India || Tiny2.11 ||| 2009 || Writing the configuration code for airframe
|- style="background:bisque; color:black"
| [mailto:mundhra@gmail.com M Mundhra] || India || Tiny 1.3 ||| 2007 || Gain tuning on a flying wing configuration airframe
|- style="background:bisque; color:black"
| [mailto:ngkiangloong_at_hopetechnik.com Jianlun]|| Singapore || TWOG V1 ||| 2008 || trying to get TWOG onto an EasyStar. very much a newbie!
|- style="background:bisque; color:black"
| [mailto:praxmail@gmail.com prashanth] || India || Tiny 2.11 ||| 2008 || 6 autonomous flights till now, currently build a new wing like funjet
|- style="background:bisque; color:black"
| [mailto:spencerpangborn@gmail.com spencer] || Taipei, Taiwan || none ||| 2009 || research for now, hope to take aerial photos of Taipei City soon
|}

==Europe==
{| class="wikitable" style="text-align:center;background:black; color:blue"

! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:silas_at_silas.hu SilaS] || Budapest || Tiny 1.3 ||| 2007 || Applied tiny to GWS Estarter, finished long travels in AUTO2. Now transfert it to a Twinstar and working on pairing tiny with FPV.

|- style="background:bisque; color:black"
| [mailto:st.jr_at_gmx.at TomS] || Graz, Austria || Tiny 2.11 ||| 2008 || Starting to complete the wiring for the tiny and then trying to apply it to my TwinStar II.

|- style="background:bisque; color:black"
| [mailto:markggriffin_at_gmail.com MarkG] || Geneva, Switzerland || Modified Tiny 2.11, EeePC as GCS, Multiplex FunJet ||| 2008 || Many successful flights.

|- style="background:bisque; color:black"
| [mailto:x-microdrones@2007.polytechnique.org X-MicroDrones] || Paris, France || Tiny 2.11, Quad-Tilt-Rotor VTOL ||| 2008 || Wiring completed, first flights soon... We're trying to adapt Paparazzi to a Quad-Tilt-Rotor VTOL able to perform both airplane-like and helicopter-like flights. Working on inertial measurement units implementation.

|- style="background:bisque; color:black"
| [[User:MarcusWolschon|Marcus Wolschon]] || Freiburg, Germany || Gumstix, Paraplane ||| 2008 || Porting Paparazzi to Linux-Userland with UDP-communication using mesh-networking.
UDP-Downlink working, GPS via GPSD working, Pararazzi in Linux working, Hardware still RC-only due to sensor-soldering-issues

|- style="background:bisque; color:black"
| [mailto:spam1_at_marzer.com CedricM] || Geneva, Switzerland || Tiny 2.11, Multiplex FunJet with video camera ||| 2008 || Many successful flights working on an osd module and weather probes.

|- style="background:bisque; color:black"
| [[ email = hendrix at vivodinet dot gr| Chris Efstathiou]] || Piraeus Hellas || tiny 2.11 on a Mpx EasyGlider, TWOG 1.3 on a Boomerang turbine jet ||| 2008 || The Easyglider is fully operational, still working on the jet which had his first flight with the TWOG at 25/1/2009

|- style="background:bisque; color:black"
| [[User:Flixr|FelixR]] || Edinburgh, Scotland || Booz2 quadrotor ||| 2008 || remote controlled flight, working on Kalman Filter

|- style="background:bisque; color:black"
| [mailto:azoreanuav_at_gmail.com Rui Costa] || Azores, Portugal || Outrunner Twinstar II with Tiny 2.11, Aerocomm datalink, 1W video tx ||| 2008 || Only ground test and software configuration.

|- style="background:bisque; color:black"
| [mailto:et@onyxnet.co.uk Alan K] || Middlesbrough, England || Tiny 2.11 & MaxStream ||| 2008 || Just starting.

|- style="background:bisque; color:black"
| [[User:G R|Gareth R]] || Sheffield, UK || Tiny 2.11, video, bunch of helicopters, Multiplex Mentor, Multiplex Funjet, Multiplex Fox, GWS Formosa ||| 2008 || Several AUTO2 flights, currently debugging

|- style="background:bisque; color:black"
| [mailto:sanarlab@yandex.ru Andrew Saenko] || Russia, St-Petersburg || Tiny 1.13, Tiny 2.11, 2.5 kg motorised glider, 800 g plane ||| 2007 || Automatic flight, adding own code.

|- style="background:bisque; color:black"
| [mailto:chebuzz_at_gmail.com David "Buzz" Carlson] || Cyprus || Tiny 2.11, Lynx EDF & GWS SloStick, 9XTend datalink ||| 2008 || Quite a few AUTO2 flights. Plane currently grounded due to a TX run-in with a 1 year-old. Currently working on getting new TX and completing CBP store setup.

|- style="background:bisque; color:black"
| [mailto:muralha_at_gmail.com Nuno Guedes] || Lamego, Portugal || Tiny 2.11 || 2008 || Starting

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Martinpi Martin Piehslinger] || Vienna, Austria || Tiny 2.11 || 2008 || just starting

|- style="background:bisque; color:black"
| [mailto:kostalexis@ece.upatras.gr AneMos-Group] || Patras, Greece || Tiny 2.11, Quadrotor VTOL ||| 2008 || Working on IMU, Trying to implement Constrained Control for the quadrotor trajectory flight

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:VAMK Allan Ojala (VAMK)] || Vaasa, Finland || TWOG, with AC4790 radio and LEA-5H GPS ||| 2009 || Just constructed my own first RC airplane SIG KADET.

|- style="background:bisque; color:black"
| [mailto:maik.hoepfel_at_web.de Maik Hoepfel] || Berlin, Germany || TWOG, Graupner Elektro Trainer S, Futaba 9C 35 Mhz ||| August 2009 || Getting started, planning to eventually use Paparazzi for a powered parachute

|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

==North America==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Mcurrie Matthew Currie] || Nanaimo, BC Canada || Tiny 13 v1.1 (Self-built) ||| November 2006 || Funjet + XBee
|

|- style="background:bisque; color:black"
| [mailto:pauldanielcox_at_gmail_dot_com Paul Cox]
|Vancouver, WA [http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=98663&sll=37.0625,-95.677068&sspn=64.664844,101.953125&ie=UTF8&ll=45.606112,-122.643471&spn=0.222411,0.398254&z=12 <span title="Google Map of 98663">98663</span>]
| Tiny v2.11 || Nov. 2008 || GWS Slow Stick flying in AUTO2 reliably. Starting on stabilized video and payload drops Skype: pauldanielcox Gtalk: [use email]

|- style="background:bisque; color:black"
| [mailto:quill_at_u.washington.edu John Burt] [http://paparazzi.enac.fr/wiki/User:John_Burt wiki page]|| Portland, Oregon || Tiny v2.11 + LEA-4H (PPZUAV), Multiplex Cularis/Easystar, 9Xtend modem, T7CAP TX, ground station: EEE PC701 and/or Nokia N810 ||| Jan 2009 || Initial flight tests w/ Easystar in AUTO1 & AUTO2.

|- style="background:bisque; color:black"
| [mailto:ogar0007@umn.edu Pat O'Gara] || St. Paul, MN || Tiny 2.11 and TWOG (PPZUAV) |||Oct. 2008 || Completed and flown FunJet and Minimag in Auto 2. Currently rebuilding MiniMag as an improved development platform.

|- style="background:bisque; color:black"
| [mailto:kochesj@gvsu.edu John Koches] || Muskegon, Michigan || Tiny 2.11 (PPZUAV) ||| 2007 || currently flying a 48 inch zagi, 80 inch under construction.

|- style="background:bisque; color:black"
| [mailto:Stdeguir@gmail.com Steve Deguir] || New York,New York || Tiny2.11+LEA-5H (PPZUAV), XbeePro 2.4, Berg4L, JR FMA ||| Feb 2009 ||

|- style="background:bisque; color:black"
| [mailto:bmw330i@me.com David Conger] || San Diego (Ramona), California || Tiny1.3 (PPZUAV) ||| Sept 2007 || Flying Wing MAV with onboard video. Test platform for the new 900mhz XBPro 900 RF modems.

|- style="background:bisque; color:black"
| [mailto:mecevans@gmail.com Michael Evans] || Seaside(Monterey Bay), California || Tiny2.11 (PPZUAV) ||| Feb 2009 ||http://www.rcgroups.com/forums/showthread.php?t=1000937.

|- style="background:bisque; color:black"
| USU AggieAir Remote Sensing || Logan, UT || TWOG (PPZUAV) ||| January 2009 || Building 72" Flying Wings which will be used for remote sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://www.engr.usu.edu/wiki/index.php/OSAM USU OSAM-UAV] || Logan, UT || TWOG (PPZUAV) ||| June 2007 || 2x72" 5x48" 1x60" Flying Wings. Research backyard for AggieAir Remote Sensing. Routine autonomous flight.

|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU Fuel Cell UAV] || Fort Collins, Co || Tiny 2.11 + LEA-5H (PPZUAV), 2.4Ghz XBPro ||| Mar 2009 || Maiden flight complete Feb 28. New Airframe in development.

|- style="background:bisque; color:black"
| [mailto:armz12@gmail.com Armen Gharibans] || La Jolla, California || Tiny2.11 (PPZUAV) ||| March 2009 || UCSD Project with Multiplex Mentor. Completed August 2, 2009. Several Successful Auto2 Flights. A LOT of help from David Conger.

|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

==Central America==

{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:joschau@comcast.net Joekadet] || David Panama' || Tiny v2.11/LEA-4P, RF Modems XBee Pro 2.4 GHz (PPZUAV). Multiplex Mentor ||| 2008 || Seven flights now. Flights 6 & 7 in Auto2. Now only a matter of fine tuning.
|- style="background:bisque; color:black"
| New User || 1 || 2 ||| 3 || 4
|}

==Australia==

{| class="wikitable" style="text-align:center;background:black; color:blue"
|-
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:todd_soaring@yahoo.com.au Todd Sandercock] || Adelaide, SA || Tiny v2.11, Multiplex Twinjet, 9Xtend modems ||| Jan 2008 || Completed successful flight testing. Now designing new airframe.
|- style="background:bisque; color:black"
| [mailto:reubenb87@gmail.com Reuben Brown]|| Gawler, SA || Tiny v2.11 ||| May 2009 || Getting the autopilot set up
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison] || Neutral Bay, NSW || Tiny v2.11, Vertical + Horizontal IR sensors, XBee PRO modems, Futaba T6EXAP TX, Futaba R136F RX, Funjet, MacBook laptop ||| August 2008 || Configuring before first flight.
|- style="background:bisque; color:black"
| [http://paparazzi.enac.fr/wiki/User:Rufus Chris Gough] || Canberra || TWOG v2.11, EZ* || September 09 || not yet airborn
|}

==Africa==

{| class="wikitable" style="text-align:center;background:black; color:blue"
! Name !! Location !! Hardware !! Joined !! Current activities / project status
|- style="background:bisque; color:black"
| [mailto:w1_th@yahoo.com W1th] || South Africa KZN || TWOG V1 ,LEA-5H GPS , RF Modems XBee Pro 868 (CheBuzz) ||| July 2009 || New to this , Got TWOG,GPS etc interfacing with Laptop and working ..Made a website [http://www.best-bargains.co.za/scarf/paparazzi.html SCARF] of my struggle ...
|- style="background:bisque; color:black"
|}

User:Mcurrie

2009-09-11T07:01:30Z

Mcurrie:

== Matthew Currie ==

[[image:Matt.currie thumb.jpg]]

=== Bio ===

IRC Nick: dc3<br/>
Location: Nanaimo, British Columbia, Canada

Currently building Tiny 1.1 boards in-house for a few group members, including myself.

=== TODO / PROGRESS ===

'''COMPLETE'''

* Assembled a number of Tiny 13 v1.1 boards
* Configured laptop with latest paparazzi3 source
* Installed bootloader on Tiny and downloaded user code
* Purchased Molex PicoBlade crimper and built various harnesses airborne and field
* Constructed Funjet airframe, test flew a dozen times
* Built waterproof ground radio box with 20 foot RS232 cable for pole mount

'''TODO'''

* Develop basic airframe file
* Complete airborne wiring harness
* Mount IR Sensors
* Order 12 dBi radome enclosed yagi
* Fly

=== WIKI Contributions ===

this is just a scratch pad of notes, etc.. might as well put them on the wiki so other can drop in on them..

Tiny13 1.1 draws 34mAh from the main supply when powered by 18V.

'''Q:''' [Tiny 1.1] I get error accessing USB when trying to load code to the Autopilot

'''A:''' You need to copy a USB rules file following the instructions below '''update: this did not appear to solve the problem. not sure why I figured it did.'''

# cd ''[paparazzi3 folder]''
# cp conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

'''Q:''' [Tiny 0.9-1.1] What is the command to compile the ARM7 code?

A: the two relevant commands are below. Replace [AIRCRAFT] with the name of your aircraft.

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.compile

to download code that has already been compiled

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.upload

'''Q:''' How do I get GCS to talk to the AP with straight serial and not a modem?

'''A:''' Here is an example of a section of my paparazzi3/conf/control_panel.xml

<session name="4 Matt Flight">
<program name="link">
<arg flag="-d" constant="/dev/ttyUSB0"/>
<arg flag="-transport" constant="pprz"/>
<arg flag="-uplink" constant=""/>
</program>
<program name="server"/>
<program name="gcs"/>
</session>

'''Q:''' How do I load the USB Bootloader onto the Tiny?

'''A:''' Start by wiring up 3.3V RS232 from the PC to the Tiny.

The serial lines on the ARM7 micro are 5V tolerant so if it helps cut down on complexity/parts you could use 5V RS232 for this. ''Optional: You could also form a basic resistor voltage divider on the PC TX -> AP RX''

*PC SERIAL_TX -> LPC_RXD_0 (SERIAL_1-7)
*PC SERIAL_RX -> LPC_TXD_0 (SERIAL_1-8)
*PC SERIAL_GND -> GND (SERIAL_1-1)
*LPC_P0.14 (SERIAL_1-5) must be asserted low (held to ground) while the Tiny powers up in order to enter the Serial Boot Loader. (You could also wire this to a pushbutton which ties it to ground, holding this button briefly while you power up the AP. This pin does not need to stay low during the programming or any time afterwards)

once these connections have been made, execute this command in a console

# make PROC=GENERIC upload_bl

[[Category:Members]]

User:Mcurrie

2009-09-11T07:01:13Z

Mcurrie: /* Bio */

User:Mcurrie

2009-09-11T07:00:59Z

Mcurrie: /* TODO / PROGRESS */

== Matthew Currie ==

[[image:Matt.currie thumb.jpg]]

=== Bio ===

IRC Nick: dc3aes<br/>
Location: Nanaimo, British Columbia, Canada

Currently building Tiny 1.1 boards in-house for a few group members, including myself.

=== TODO / PROGRESS ===

'''COMPLETE'''

* Assembled a number of Tiny 13 v1.1 boards
* Configured laptop with latest paparazzi3 source
* Installed bootloader on Tiny and downloaded user code
* Purchased Molex PicoBlade crimper and built various harnesses airborne and field
* Constructed Funjet airframe, test flew a dozen times
* Built waterproof ground radio box with 20 foot RS232 cable for pole mount

'''TODO'''

* Develop basic airframe file
* Complete airborne wiring harness
* Mount IR Sensors
* Order 12 dBi radome enclosed yagi
* Fly

=== WIKI Contributions ===

this is just a scratch pad of notes, etc.. might as well put them on the wiki so other can drop in on them..

Tiny13 1.1 draws 34mAh from the main supply when powered by 18V.

'''Q:''' [Tiny 1.1] I get error accessing USB when trying to load code to the Autopilot

'''A:''' You need to copy a USB rules file following the instructions below '''update: this did not appear to solve the problem. not sure why I figured it did.'''

# cd ''[paparazzi3 folder]''
# cp conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/

'''Q:''' [Tiny 0.9-1.1] What is the command to compile the ARM7 code?

A: the two relevant commands are below. Replace [AIRCRAFT] with the name of your aircraft.

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.compile

to download code that has already been compiled

# cd ''[parazzi3 folder]'''
# make AIRCRAFT=[AIRCRAFT] ap.upload

'''Q:''' How do I get GCS to talk to the AP with straight serial and not a modem?

'''A:''' Here is an example of a section of my paparazzi3/conf/control_panel.xml

<session name="4 Matt Flight">
<program name="link">
<arg flag="-d" constant="/dev/ttyUSB0"/>
<arg flag="-transport" constant="pprz"/>
<arg flag="-uplink" constant=""/>
</program>
<program name="server"/>
<program name="gcs"/>
</session>

'''Q:''' How do I load the USB Bootloader onto the Tiny?

'''A:''' Start by wiring up 3.3V RS232 from the PC to the Tiny.

The serial lines on the ARM7 micro are 5V tolerant so if it helps cut down on complexity/parts you could use 5V RS232 for this. ''Optional: You could also form a basic resistor voltage divider on the PC TX -> AP RX''

*PC SERIAL_TX -> LPC_RXD_0 (SERIAL_1-7)
*PC SERIAL_RX -> LPC_TXD_0 (SERIAL_1-8)
*PC SERIAL_GND -> GND (SERIAL_1-1)
*LPC_P0.14 (SERIAL_1-5) must be asserted low (held to ground) while the Tiny powers up in order to enter the Serial Boot Loader. (You could also wire this to a pushbutton which ties it to ground, holding this button briefly while you power up the AP. This pin does not need to stay low during the programming or any time afterwards)

once these connections have been made, execute this command in a console

# make PROC=GENERIC upload_bl

Airframe Configuration

2009-09-11T06:52:49Z

Mcurrie: /* Configuring The Serial Protocol */

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. This is an [http://en.wikipedia.org/wiki/Xml XML] document containing some [http://en.wikipedia.org/wiki/Makefile Makefile] code at the bottom. All gains, trims, and behavior settings are defined with standard XML elements. The hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile raw section.

== Selecting the Airframe File ==
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:
<?xml version="1.0"?>
<conf>
<aircraft
name="Twin1"
ac_id="1"
airframe="airframes/twinstar1.xml"
radio="radios/mc3030.xml"
flight_plan="flight_plans/mav05_cw.xml"
telemetry="telemetry/default.xml"
gui_color="blue"
/>
<aircraft
name="Plaster"
ac_id="2"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
telemetry="telemetry/default.xml"
flight_plan="flight_plans/dummy.xml"
/>
.
.
.
</conf>
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply select the appropriate A/C and target in the [[Paparazzi_Center|Paparazzi Center]] or specify your airframe name in the flash command typed from the prompt:
make AIRCRAFT=<b>Twin1</b> ap.upload
More information can be found on the [[Conf.xml|conf.xml]] page

== XML Parameters ==
=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600]. Note that these commands do not necessarily match the servo actuators. For example, the ROLL command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute travel limits can be increased or reduced with the min/max values. The <tt>"THROTTLE"</tt> servo typically has the same value for the <b><tt>neutral</tt></b> and <b><tt>min</tt></b>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/>
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/>
</command_laws></tt>
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]
where the third line is the simplest: the throttle servo value equals throttle command value. The other lines define and control the pitch/roll mixing. Ailevon values are computed with a combination of two commands, '''ROLL''' and '''PITCH'''. This ''mixer'' is defined with two intermediate variables '''aileron''' and '''elevator''' introduced with the <b><tt>let</tt></b> element. The '''@''' symbol is used to reference a command value in the <b><tt>value</tt></b> attribute of the <b><tt>set</tt></b> and <b><tt>let</tt></b> elements. In the above example, the servos are limited to +/- 70% of their full travel for pitch and 30% for roll, only in combination can the servos reach 100% deflection. Note that these numbers ''should add up 100% or more, never less''. For example, you may want 100% travel available for pitch - this means if a roll is commanded along with maximum pitch only one servo will respond to the roll command as the other has already reached its mechanical limit. If you find after tuning that these numbers add to less than 100% consider reducing the surface travel mechanically.

Note that the signs used in the description follow the standard convention.

=== Manual ===
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:

<rc_commands>
<set command="THROTTLE" value="@THROTTLE"/>
<set command="ROLL" value="@ROLL"/>
<set command="PITCH" value="@PITCH"/>
</rc_commands>

This example looks trivial since the channel values have the same name than the commands.

=== Autopilot Only Commands ===
For certain missions it might be required to control servos (payload) from the autopilot (gcs) at all times (even during manual flight). These commands should not be in the <rc_commands> block but in the special <ap_only_commands> block. This allows for instance the pantilt operator to keep working when in manual flight, or safety logic to automatically close cameras below a certain altitude during manual landings.

<ap_only_commands>
<copy command="PAN"/>
<copy command="TILT"/>
<copy command="SHOOT"/>
</ap_only_commands>

=== Auto1 ===
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.
<tt>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="RadOfDeg(35)"/>
<define name="MAX_PITCH" value="RadOfDeg(35)"/>
</section>
</tt>
<br>

=== ADC ===
In the "adc" section, you will find the conformity between arguments and their assigned pins on the autopilot board.
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_1"/>
<define name="IR2" value="ADC_2"/>
<define name="IR_TOP" value="ADC_0"/>
</section>
'''Important note''': To ''activate'' an ADC entry, a flag must be defined in the <tt>makefile</tt> section. For the previous example, we would have to write:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2
ap.srcs += $(SRC_ARCH)/adc_hw.c

==== ADC Generic ====

In addition, if you want to receive the value of some ADC channel, you can use the "ADC Generic" service. When activated, the aircraft sends 2 values corresponding to the selected ADC channels. They can be read from the "Messages" application.
ap.CFLAGS += -DUSE_ADC_GENERIC -DUSE_ADC_3 -DADC_CHANNEL_GENERIC1=ADC_3 -DUSE_ADC_4 -DADC_CHANNEL_GENERIC2=ADC_4
ap.srcs += adc_generic.c
In this example, the ADC channels 3 and 4 are read and sent by telemetry at 4Hz:
<message name="ADC_GENERIC" ID="18">
<field name="val1" type="uint16"/>
<field name="val2" type="uint16"/>
</message>
Only two channels can be defined. If only one is activated, 0 will send for the second value.

=== Infrared ===
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors.

The first definitions are relative to the electronic neutral of the sensors (a sensor here is a '''pair''' of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.

<section name="INFRARED" prefix="IR_">
<define name="ADC_IR1_NEUTRAL" value="512"/>
<define name="ADC_IR2_NEUTRAL" value="512"/>
<define name="ADC_TOP_NEUTRAL" value="512"/>

These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.

The next lines define the installation of the horizontal and vertical sensors. The vertical sensor must give a positive value when the temperature under the aircraft is higher than the temperature above. The two channels of the horizontal sensor must give positive values when it is warmer on the right side and the rear side. To adjust these signs, use the following declarations:

<define name="IR1_SIGN" value="-1"/>
<define name="IR2_SIGN" value="-1"/>
<define name="TOP_SIGN" value="-1"/>

Then, define how the horizontal sensor is connected to the airframe, orientation '''aligned''' or '''tilted'''. In the aligned case, ir'''1''' is along the lateral axis (The axis that passes through the plane from wingtip to wingtip) and ir'''2''' along the longitudinal one. In the '''tilted''' case, the sensors are tilted by 45 degrees; ir'''1''' is along rear-left -- front-right, and ir'''2''' along rear-right -- front-left. The parameter "value" has no effect! If the airframe construction allows choose an aligned sensor orientation since this gives the best stabilization response results.

For help with orientation of '''Previous Versions of Infrared Sensor Boards''' try here : http://paparazzi.enac.fr/wiki/Previous_Infrared_Sensors

<define name="HORIZ_SENSOR_ALIGNED" value="1"/>
or
<define name="HORIZ_SENSOR_TILTED" value="1"/>

The three axis must give similar values for similar contrasts. The following factors can be used to scale these values. For example with an horizontal tilted sensor, the following ratios are usually needed:

<define name="LATERAL_CORRECTION" value="0.7"/>
<define name="LONGITUDINAL_CORRECTION" value="0.7"/>
<define name="VERTICAL_CORRECTION" value="1."/>
Default values are 1.

It may be hard to align the horizontal sensor with the aircraft. A tuning in flight will be needed to adjust the following neutrals. Adjust the roll neutral to fly straight. Adjust the pitch neutral to fly level with the desired throttle.
<define name="ROLL_NEUTRAL_DEFAULT" value="-2.5" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT" value="6" unit="deg"/>

Finally, an asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.

The old way to define the parameters is still possible, but must not be mixed with the new one describe above.

=== Gyro ===
Defines the type of gyro installed, each axis neutral, and any required temperature compensation. If the gyro has two axes, the pitch neutral is defined as well. Many gyros output their internal temperature and require a temperature-dependent linear correction be made to the neutral value. No correction is done for the temperature in this example.(<b><tt>ADC_TEMP_SLOPE=0</tt></b>).

<tt>
<section name="GYRO" prefix="GYRO_"
<define name="ADC_ROLL_COEFF" value="1"/>
<define name="ROLL_NEUTRAL" value="500"/>
<define name="ADC_TEMP_NEUTRAL" value="476"/>
<define name="ADC_TEMP_SLOPE" value="0"/>
</section>
</tt>

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no current sensor is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. At 50% throttle it is likely to use about 5 Amps so the autopilot can have a better idea how much energy is remaining. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the battery has only 2000 mAh capacity, you could reduce the MILLIAMP_AT_FULL_THROTTLE value by 20% to match your in-flight current consumption.

The <b><tt>CATASTROPHIC_BAT_LEVEL</tt></b> (was previously <b><tt>LOW_BATTERY</tt></b>) value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode (kill_throttle mode). This value is also used by the ground server to issue a '''CATASTROPHIC''' alarm message on the bus (this message will be displayed in the console of the GCS). <b><tt>CRITIC</tt></b> and <b><tt>LOW</tt></b> values will also used as threshold for '''CRITIC''' and '''WARNING''' alarms. They are optional and the respective defaults are 10.0 and 10.5V.

The <b><tt>MAX_BAT_LEVEL</tt></b> may be specified to improve the display of the battery gauge in the strip. This definition is optional with a default value of 12.5V.

<tt>
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</tt>

A description how to get a current sensor working is here: [[Current_sensor|Current sensor]]

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_ATTITUDE_GAIN" value="-7500."/>
<define name="ROLL_RATE_GAIN" value="-1500"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

The outer loop acts on the route. It will produce a roll command from a course setpoint and a course measurement. The COURSE_PGAIN parameter is the factor multiplied by the course error (in radian) to get a roll setpoint (in radian). So if the plane is expected to go north (course=0) and is actually flying to 57 degrees (course=1 radian, i.e. ENE), with a gain of '''-0.4''', a roll of -0.4 (23 degrees) will be set for the lower control loop.

The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.

===Vertical Control===

<section name="VERTICAL CONTROL" prefix="V_CTL_">

<define name="ALTITUDE_PGAIN" value="-0.1" unit="(m/s)/m"/>

<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/>
These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.008" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/>

These lines are associated with vertical rate control loops contained in ./sw/airborne/fw_v_ctl.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.

<define name="AUTO_PITCH_PGAIN" value="-0.1"/>
<define name="AUTO_PITCH_IGAIN" value="0.025"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.5"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.5"/>

These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.

<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/>
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.

=== Misc ===
<tt>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s">
<define name="CARROT" value="5." unit="s"/>
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value"60" unit="Hz"/>
</section>
</tt>

* The "NOMINAL_AIRSPEED" is mainly used in the simulator.
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).

=== Modules ===
The [[Modules|modules]] allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.

<tt>
<modules main_freq="60">
<load name="demo_module.xml"/>
</modules>
</tt>

* The main_freq parameter (in Hz) allows to specify the frequency of the main loop. Default is 60 Hz

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
<nowiki>ap.CFLAGS += -DFBW -DAP -DBOARD_CONFIG=\"tiny.h\" -DLED -DTIME_LED=1"</nowiki>
.
.
.
</makefile>
}}
Please note that -DCONFIG was changed to -DBOARD_CONFIG on 18 July 2009.

Below this are the definintions and configuration of the peripherals and interfaces.

=== Radio Control ===
The Paparazzi autpilot can interface directly with the PWM signal from any standard hobby R/C receiver. Signal decoding configuration settings for this are stored in the [[Radio_Control|Radio Control]] file.

If you have a Tiny v1.1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4015_MAT_hw.h\" -DSERVOS_4015_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4015_MAT_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you have a Tiny v2 or TWOG v1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4017_hw.h\" -DSERVOS_4017</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4017_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you want to output standard PPM to a R/C receiver:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_ppm_hw.h\" -DSERVOS_PPM_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_ppm_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
This is used in the case where you want to directly drive a receiver which has a microcontroller to do the decoding and driving of the servos (not a 4015 or 4017 decoder chip). The PPM is output on the SERV_CLK pin. The PPM frame rate, pulse width, and number of channels can be adjusted in the "servos_ppm_hw.h" file to suit your particular receiver.

If you have a Classix Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM. "RC_FUTABA" is for the Futaba or compatible brands, and "RC_JR" for JR (a.k.a Graupner outside of the USA) or compatible brands.

For the Classix, you must specify which pins to use for PWM by adding "-DPWM_SERVO_0, etc." to the line fbw.CFLAGS. This activate the PWM channel.
<tt>wiring on classix PWM connector
connector LPC shared port
PWM1 PWM5 AD1_6 CAP1_3 P0.21
PWM2 PWM3 RXD0 EINT0 P0.1
PWM3 PWM1 TXD0 P0.0
PWM4 PWM6 RXD1 EINT3 P0.9
PWM5 PWM4 TXD1 AD1_1 P0.8
PWM6 PWM2 SSEL0 EINT2 P0.7</tt>
PWM1 and PWM6 should be safe. PWM4 and PWM5 should be OK if you're not using UART1 on the FBW processor - same for PWM2 and PWM3 if you're not using UART0 (disable FBW telemetry for that ).

=== Modem ===
The modem protocol and baud rate must be set in both the airframe file and ground station. Any standard baud rate can be used, with 9600 being adequate and 57600 recommended for most users to allow high speed telemetry for more detailed flight data analysis. The actual data rate is determined by the number of messages being sent and the period of each message as defined in <tt>conf/telemetry/default.xml</tt>. Those wishing to experiment with "alternative" modems can reduce the number and period of each telemetry message to fit within most any bandwidth constraint.

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAV there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="PPRZ"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
The above example tells the autopilot to send and recieve data in standard serial form.

{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|
# Serial modem
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DPPRZ_UART=Uart0 -DDATALINK=PPRZ -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the serial transport protocol (pprz_transport.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br>
Note:
* Remember Tiny 13 v1.1 uses UART0 for serial modem while Tiny 2 uses UART1. Make the appropriate changes.
* The autopilot and modem serial port baud rates must match at all times and also must match the ground modem rate, check your modem documentation to find the default baud rate and configure a different rate as needed.

<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>

<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

==== Configuring The Maxstream API Protocol ====
The optional API protocol enables hardware addressing so that multiple aircraft can be managed from a single ground modem, or multiple aircraft and multiple ground stations can work simultaneously without interference from one another. API mode is enabled by sending an escape sequence (+++) followed by AT commands, this can be done automatically at each boot or can be permanently configured with the "ATWR" command for greater reliability.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/>
...
</section></nowiki>
}}
The above example will program the Maxstream to API mode, 100mW power (ATPL2), 57600 baud (ATBD6), and permanently store the changes (ATWR). After flashing allow 30 seconds for the modem to store the changes, then disable the init string by adding the line <tt><define name="NO_XBEE_API_INIT" value="TRUE"/></tt> (the parameter "value" has no effect), update the baud rate as needed, and re-flash the autopilot. The modem and autopilot serial port baud rates must match eachother at all times.
<br>
Notes:
* Maxtream modems are factory configured for 9600 baud, in order to change baud rates, first configure the autopilot serial port to match the modem (DUART0_BAUD=B9600), boot the system so that the baud rate change command is sent to the modem (ATBD6) and permanently saved (ATWR), allow 30 seconds for the modem configuration to complete, then reprogram the autopilot with the new baud rate (DUART0_BAUD=B57600) and disabled modem configuration string <tt><define name="NO_XBEE_API_INIT" value="TRUE"/> </tt>.
* The ac_id defined in <tt>conf/conf.xml</tt> is permanently programmed into the modem so this procedure would need to be re-run if the modem is moved to another plane.
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string.
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.

<br style="clear:both>

{{Box Code|confAgain/airframes/myplane.xml - makefile section at the bottom|
<nowiki># Maxstream API protocol</nowiki>
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=XBeeTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DXBEE_UART=Uart0 -DDATALINK=XBEE -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the Maxstream transport protocol (xbee.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>
<arg flag="-transport" constant="xbee"/>
<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]
=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\""/>

...
</section></nowiki>
}}
Also use this
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
And Finally use this in the makefile section
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1 -DDATALINK=XBEE -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
</nowiki>
}}
By reading all the information above you should be able to infer what the above does.

Now keep in mind that the ground modem baud rate and airplanes modem baud rates do not have to match. The only things that need to match are the the modem on the planes baud rate and the rate defined in the airframe file. For example this planes modem is set to 9600 and this could be used with the ground modem configured above using 57600...
Also for multiple UAV's a good way to configure them is to use 9600 for the ap and use a ground modem configured to 57600 and its not a bad idea to use minimal telemetry.

=== GPS ===
The serial port settings must match that of the GPS and are configured here along with the necessary files to interpret the u-blox UBX binary protocol:

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''Note:'''
* Tiny 13 v1.1 uses UART1 while Tiny 2 uses UART0 for GPS
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly thru the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center Configured with|u-center]]

If using the u-blox LEA-5H, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file in the gps section. This flag must be inserted above "ap.srcs += gps_ubx.c gps.c" for proper operation.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400 -DGPS_USE_LATLONG
ap.srcs += gps_ubx.c gps.c</nowiki>
}}

=== Sensors ===

=== Control loops ===

The control loops can be divided in two largely independent groups : the vertical ones and the horizontal ones (files sw/airborne/fw_h_ctl.c and sw/airborne/fw_v_ctl.c ). Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.

First the horizontal loop:
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM
ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
</nowiki>
}}

Airframe Configuration

2009-09-11T06:51:37Z

Mcurrie: /* GPS */

The airframe configuration file is located in <tt>conf/airframes</tt> and contains
all the hardware and software settings for an aircraft. This is an [http://en.wikipedia.org/wiki/Xml XML] document containing some [http://en.wikipedia.org/wiki/Makefile Makefile] code at the bottom. All gains, trims, and behavior settings are defined with standard XML elements. The hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile raw section.

== Selecting the Airframe File ==
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:
<?xml version="1.0"?>
<conf>
<aircraft
name="Twin1"
ac_id="1"
airframe="airframes/twinstar1.xml"
radio="radios/mc3030.xml"
flight_plan="flight_plans/mav05_cw.xml"
telemetry="telemetry/default.xml"
gui_color="blue"
/>
<aircraft
name="Plaster"
ac_id="2"
airframe="airframes/plaster1.xml"
radio="radios/cockpitMM.xml"
telemetry="telemetry/default.xml"
flight_plan="flight_plans/dummy.xml"
/>
.
.
.
</conf>
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply select the appropriate A/C and target in the [[Paparazzi_Center|Paparazzi Center]] or specify your airframe name in the flash command typed from the prompt:
make AIRCRAFT=<b>Twin1</b> ap.upload
More information can be found on the [[Conf.xml|conf.xml]] page

== XML Parameters ==
=== Commands ===

The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In our example, we have only three:
<tt>
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands></tt>
Each command is associated with a failsafe value which will be used if no controller is active (during initialization for example). The range of these values is [-9600:9600]. Note that these commands do not necessarily match the servo actuators. For example, the ROLL command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <b><tt>servos</tt></b> here. In this example we use two ailevons (surfaces used for both pitch and roll as on a flying wing) and a motor. These are listed in the <b><tt>servos</tt></b> section:
<tt>
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/>
</servos></tt>
where names are associated to the corresponding servo channel number on the autopilot and the neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds and the direction of travel can be reversed by exchanging min with max (as in <tt>"AILEVON_LEFT"</tt>, above). The ''standard'' travel for a hobby servo is 1000ms - 2000ms with a 1500ms neutral. Trim can be added by changing this neutral value, and absolute travel limits can be increased or reduced with the min/max values. The <tt>"THROTTLE"</tt> servo typically has the same value for the <b><tt>neutral</tt></b> and <b><tt>min</tt></b>. Note the following tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000ms range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.

The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:
<tt>
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/>
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/>
</command_laws></tt>
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]
where the third line is the simplest: the throttle servo value equals throttle command value. The other lines define and control the pitch/roll mixing. Ailevon values are computed with a combination of two commands, '''ROLL''' and '''PITCH'''. This ''mixer'' is defined with two intermediate variables '''aileron''' and '''elevator''' introduced with the <b><tt>let</tt></b> element. The '''@''' symbol is used to reference a command value in the <b><tt>value</tt></b> attribute of the <b><tt>set</tt></b> and <b><tt>let</tt></b> elements. In the above example, the servos are limited to +/- 70% of their full travel for pitch and 30% for roll, only in combination can the servos reach 100% deflection. Note that these numbers ''should add up 100% or more, never less''. For example, you may want 100% travel available for pitch - this means if a roll is commanded along with maximum pitch only one servo will respond to the roll command as the other has already reached its mechanical limit. If you find after tuning that these numbers add to less than 100% consider reducing the surface travel mechanically.

Note that the signs used in the description follow the standard convention.

=== Manual ===
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:

<rc_commands>
<set command="THROTTLE" value="@THROTTLE"/>
<set command="ROLL" value="@ROLL"/>
<set command="PITCH" value="@PITCH"/>
</rc_commands>

This example looks trivial since the channel values have the same name than the commands.

=== Autopilot Only Commands ===
For certain missions it might be required to control servos (payload) from the autopilot (gcs) at all times (even during manual flight). These commands should not be in the <rc_commands> block but in the special <ap_only_commands> block. This allows for instance the pantilt operator to keep working when in manual flight, or safety logic to automatically close cameras below a certain altitude during manual landings.

<ap_only_commands>
<copy command="PAN"/>
<copy command="TILT"/>
<copy command="SHOOT"/>
</ap_only_commands>

=== Auto1 ===
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.
<tt>
<section name="AUTO1" prefix="AUTO1_">
<define name="MAX_ROLL" value="RadOfDeg(35)"/>
<define name="MAX_PITCH" value="RadOfDeg(35)"/>
</section>
</tt>
<br>

=== ADC ===
In the "adc" section, you will find the conformity between arguments and their assigned pins on the autopilot board.
<section name="adc" prefix="ADC_CHANNEL_">
<define name="IR1" value="ADC_1"/>
<define name="IR2" value="ADC_2"/>
<define name="IR_TOP" value="ADC_0"/>
</section>
'''Important note''': To ''activate'' an ADC entry, a flag must be defined in the <tt>makefile</tt> section. For the previous example, we would have to write:

ap.CFLAGS += -DADC -DUSE_ADC_0 -DUSE_ADC_1 -DUSE_ADC_2
ap.srcs += $(SRC_ARCH)/adc_hw.c

==== ADC Generic ====

In addition, if you want to receive the value of some ADC channel, you can use the "ADC Generic" service. When activated, the aircraft sends 2 values corresponding to the selected ADC channels. They can be read from the "Messages" application.
ap.CFLAGS += -DUSE_ADC_GENERIC -DUSE_ADC_3 -DADC_CHANNEL_GENERIC1=ADC_3 -DUSE_ADC_4 -DADC_CHANNEL_GENERIC2=ADC_4
ap.srcs += adc_generic.c
In this example, the ADC channels 3 and 4 are read and sent by telemetry at 4Hz:
<message name="ADC_GENERIC" ID="18">
<field name="val1" type="uint16"/>
<field name="val2" type="uint16"/>
</message>
Only two channels can be defined. If only one is activated, 0 will send for the second value.

=== Infrared ===
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors.

The first definitions are relative to the electronic neutral of the sensors (a sensor here is a '''pair''' of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.

<section name="INFRARED" prefix="IR_">
<define name="ADC_IR1_NEUTRAL" value="512"/>
<define name="ADC_IR2_NEUTRAL" value="512"/>
<define name="ADC_TOP_NEUTRAL" value="512"/>

These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.

The next lines define the installation of the horizontal and vertical sensors. The vertical sensor must give a positive value when the temperature under the aircraft is higher than the temperature above. The two channels of the horizontal sensor must give positive values when it is warmer on the right side and the rear side. To adjust these signs, use the following declarations:

<define name="IR1_SIGN" value="-1"/>
<define name="IR2_SIGN" value="-1"/>
<define name="TOP_SIGN" value="-1"/>

Then, define how the horizontal sensor is connected to the airframe, orientation '''aligned''' or '''tilted'''. In the aligned case, ir'''1''' is along the lateral axis (The axis that passes through the plane from wingtip to wingtip) and ir'''2''' along the longitudinal one. In the '''tilted''' case, the sensors are tilted by 45 degrees; ir'''1''' is along rear-left -- front-right, and ir'''2''' along rear-right -- front-left. The parameter "value" has no effect! If the airframe construction allows choose an aligned sensor orientation since this gives the best stabilization response results.

For help with orientation of '''Previous Versions of Infrared Sensor Boards''' try here : http://paparazzi.enac.fr/wiki/Previous_Infrared_Sensors

<define name="HORIZ_SENSOR_ALIGNED" value="1"/>
or
<define name="HORIZ_SENSOR_TILTED" value="1"/>

The three axis must give similar values for similar contrasts. The following factors can be used to scale these values. For example with an horizontal tilted sensor, the following ratios are usually needed:

<define name="LATERAL_CORRECTION" value="0.7"/>
<define name="LONGITUDINAL_CORRECTION" value="0.7"/>
<define name="VERTICAL_CORRECTION" value="1."/>
Default values are 1.

It may be hard to align the horizontal sensor with the aircraft. A tuning in flight will be needed to adjust the following neutrals. Adjust the roll neutral to fly straight. Adjust the pitch neutral to fly level with the desired throttle.
<define name="ROLL_NEUTRAL_DEFAULT" value="-2.5" unit="deg"/>
<define name="PITCH_NEUTRAL_DEFAULT" value="6" unit="deg"/>

Finally, an asymmetric (left/right, front/rear) correction can be added with a last set of factors.
<define name="CORRECTION_UP" value="1."/>
<define name="CORRECTION_DOWN" value="1."/>
<define name="CORRECTION_LEFT" value="1."/>
<define name="CORRECTION_RIGHT" value="1."/>
</section>
These corrections are set on the angles.

The old way to define the parameters is still possible, but must not be mixed with the new one describe above.

=== Gyro ===
Defines the type of gyro installed, each axis neutral, and any required temperature compensation. If the gyro has two axes, the pitch neutral is defined as well. Many gyros output their internal temperature and require a temperature-dependent linear correction be made to the neutral value. No correction is done for the temperature in this example.(<b><tt>ADC_TEMP_SLOPE=0</tt></b>).

<tt>
<section name="GYRO" prefix="GYRO_"
<define name="ADC_ROLL_COEFF" value="1"/>
<define name="ROLL_NEUTRAL" value="500"/>
<define name="ADC_TEMP_NEUTRAL" value="476"/>
<define name="ADC_TEMP_SLOPE" value="0"/>
</section>
</tt>

=== Bat ===
This section give characteristics for the monitoring of the main power battery. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. It is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no current sensor is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. At 50% throttle it is likely to use about 5 Amps so the autopilot can have a better idea how much energy is remaining. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the battery has only 2000 mAh capacity, you could reduce the MILLIAMP_AT_FULL_THROTTLE value by 20% to match your in-flight current consumption.

The <b><tt>CATASTROPHIC_BAT_LEVEL</tt></b> (was previously <b><tt>LOW_BATTERY</tt></b>) value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode (kill_throttle mode). This value is also used by the ground server to issue a '''CATASTROPHIC''' alarm message on the bus (this message will be displayed in the console of the GCS). <b><tt>CRITIC</tt></b> and <b><tt>LOW</tt></b> values will also used as threshold for '''CRITIC''' and '''WARNING''' alarms. They are optional and the respective defaults are 10.0 and 10.5V.

The <b><tt>MAX_BAT_LEVEL</tt></b> may be specified to improve the display of the battery gauge in the strip. This definition is optional with a default value of 12.5V.

<tt>
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="VOLTAGE_ADC_A" value="0.0177531"/>
<define name="VOLTAGE_ADC_B" value="0.173626"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</tt>

A description how to get a current sensor working is here: [[Current_sensor|Current sensor]]

=== Horizontal Control ===
<tt>
<section name="HORIZONTAL CONTROL" prefix="H_CTL_">
<define name="COURSE_PGAIN" value="-0.4"/>
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/>
<define name="ROLL_ATTITUDE_GAIN" value="-7500."/>
<define name="ROLL_RATE_GAIN" value="-1500"/>
<define name="PITCH_PGAIN" value="-8000."/>
<define name="ELEVATOR_OF_ROLL" value="1250"/>
</section>
</tt>

The outer loop acts on the route. It will produce a roll command from a course setpoint and a course measurement. The COURSE_PGAIN parameter is the factor multiplied by the course error (in radian) to get a roll setpoint (in radian). So if the plane is expected to go north (course=0) and is actually flying to 57 degrees (course=1 radian, i.e. ENE), with a gain of '''-0.4''', a roll of -0.4 (23 degrees) will be set for the lower control loop.

The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.

===Vertical Control===

<section name="VERTICAL CONTROL" prefix="V_CTL_">

<define name="ALTITUDE_PGAIN" value="-0.1" unit="(m/s)/m"/>

<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/>
These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/>
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/>
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/>
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/>
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/>
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_PGAIN" value="-0.008" unit="%/(m/s)"/>
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/>
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/>

These lines are associated with vertical rate control loops contained in ./sw/airborne/fw_v_ctl.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.

<define name="AUTO_PITCH_PGAIN" value="-0.1"/>
<define name="AUTO_PITCH_IGAIN" value="0.025"/>
<define name="AUTO_PITCH_MAX_PITCH" value="0.5"/>
<define name="AUTO_PITCH_MIN_PITCH" value="-0.5"/>

These lines are associated with vertical control loops contained in ./sw/airborne/fw_v_ctl.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.

<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/>
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.

=== Misc ===
<tt>
<section name="MISC">
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s">
<define name="CARROT" value="5." unit="s"/>
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/>
<define name="CONTROL_RATE" value"60" unit="Hz"/>
</section>
</tt>

* The "NOMINAL_AIRSPEED" is mainly used in the simulator.
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).

=== Modules ===
The [[Modules|modules]] allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.

<tt>
<modules main_freq="60">
<load name="demo_module.xml"/>
</modules>
</tt>

* The main_freq parameter (in Hz) allows to specify the frequency of the main loop. Default is 60 Hz

== Hardware definitions - Makefile ==

The airframe file must include the description of the controller board and it's low-level settings. This is done in one <b><tt>makefile</tt></b> section starting with the autopilot model and flashing mode:
{{Box Code|conf/airframes/myplane.xml|
<makefile>
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile
<nowiki>FLASH_MODE=IAP</nowiki>
<nowiki>ap.CFLAGS += -DFBW -DAP -DBOARD_CONFIG=\"tiny.h\" -DLED -DTIME_LED=1"</nowiki>
.
.
.
</makefile>
}}
Please note that -DCONFIG was changed to -DBOARD_CONFIG on 18 July 2009.

Below this are the definintions and configuration of the peripherals and interfaces.

=== Radio Control ===
The Paparazzi autpilot can interface directly with the PWM signal from any standard hobby R/C receiver. Signal decoding configuration settings for this are stored in the [[Radio_Control|Radio Control]] file.

If you have a Tiny v1.1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4015_MAT_hw.h\" -DSERVOS_4015_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4015_MAT_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you have a Tiny v2 or TWOG v1 Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_4017_hw.h\" -DSERVOS_4017</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_4017_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
If you want to output standard PPM to a R/C receiver:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_ppm_hw.h\" -DSERVOS_PPM_MAT</nowiki>
<nowiki>ap.srcs += $(SRC_ARCH)/servos_ppm_hw.c actuators.c</nowiki>
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.srcs += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
}}
This is used in the case where you want to directly drive a receiver which has a microcontroller to do the decoding and driving of the servos (not a 4015 or 4017 decoder chip). The PPM is output on the SERV_CLK pin. The PPM frame rate, pulse width, and number of channels can be adjusted in the "servos_ppm_hw.h" file to suit your particular receiver.

If you have a Classix Autopilot:
{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki>
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki>
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki>
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki>
}}

You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM. "RC_FUTABA" is for the Futaba or compatible brands, and "RC_JR" for JR (a.k.a Graupner outside of the USA) or compatible brands.

For the Classix, you must specify which pins to use for PWM by adding "-DPWM_SERVO_0, etc." to the line fbw.CFLAGS. This activate the PWM channel.
<tt>wiring on classix PWM connector
connector LPC shared port
PWM1 PWM5 AD1_6 CAP1_3 P0.21
PWM2 PWM3 RXD0 EINT0 P0.1
PWM3 PWM1 TXD0 P0.0
PWM4 PWM6 RXD1 EINT3 P0.9
PWM5 PWM4 TXD1 AD1_1 P0.8
PWM6 PWM2 SSEL0 EINT2 P0.7</tt>
PWM1 and PWM6 should be safe. PWM4 and PWM5 should be OK if you're not using UART1 on the FBW processor - same for PWM2 and PWM3 if you're not using UART0 (disable FBW telemetry for that ).

=== Modem ===
The modem protocol and baud rate must be set in both the airframe file and ground station. Any standard baud rate can be used, with 9600 being adequate and 57600 recommended for most users to allow high speed telemetry for more detailed flight data analysis. The actual data rate is determined by the number of messages being sent and the period of each message as defined in <tt>conf/telemetry/default.xml</tt>. Those wishing to experiment with "alternative" modems can reduce the number and period of each telemetry message to fit within most any bandwidth constraint.

Paparazzi supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:
==== Configuring The Serial Protocol ====
New users are advised to start with the standard serial protocol before attempting to setup an addressed API link. There are no real reasons for the novice user to use the xbee protocol over the standard PPRZTransport. Even if you are using a Maxstream modem you should still start out with the standard. Lastly it should be pointed out that using a single UAV there is no disadvantage and that the [http://www.engr.usu.edu/wiki/index.php/OSAM OSAM] Paparazzi Team at UAS 2008 took second place using the STANDARD protocol. The serial protocol works with virtually any modem as well as direct cable connections. The baud rates of the airborne modem, autopilot, ground modem, and PC must be configured correctly. The PC and autopilot serial ports do not need to be set to the same baud rate, i.e. when running multiple aircraft from a single ground modem, the ground modem may require a higher baud rate than any of the airborne modems in order to stream the data from multiple simultaneous sources.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="PPRZ"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
The above example tells the autopilot to send and recieve data in standard serial form.

{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|
# Serial modem
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=PprzTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DPPRZ_UART=Uart0 -DDATALINK=PPRZ -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the serial transport protocol (pprz_transport.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br>
Note:
* The autopilot and modem serial port baud rates must match at all times and also must match the ground modem rate, check your modem documentation to find the default baud rate and configure a different rate as needed.

<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>

<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]

==== Configuring The Maxstream API Protocol ====
The optional API protocol enables hardware addressing so that multiple aircraft can be managed from a single ground modem, or multiple aircraft and multiple ground stations can work simultaneously without interference from one another. API mode is enabled by sending an escape sequence (+++) followed by AT commands, this can be done automatically at each boot or can be permanently configured with the "ATWR" command for greater reliability.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/>
...
</section></nowiki>
}}
The above example will program the Maxstream to API mode, 100mW power (ATPL2), 57600 baud (ATBD6), and permanently store the changes (ATWR). After flashing allow 30 seconds for the modem to store the changes, then disable the init string by adding the line <tt><define name="NO_XBEE_API_INIT" value="TRUE"/></tt> (the parameter "value" has no effect), update the baud rate as needed, and re-flash the autopilot. The modem and autopilot serial port baud rates must match eachother at all times.
<br>
Notes:
* Maxtream modems are factory configured for 9600 baud, in order to change baud rates, first configure the autopilot serial port to match the modem (DUART0_BAUD=B9600), boot the system so that the baud rate change command is sent to the modem (ATBD6) and permanently saved (ATWR), allow 30 seconds for the modem configuration to complete, then reprogram the autopilot with the new baud rate (DUART0_BAUD=B57600) and disabled modem configuration string <tt><define name="NO_XBEE_API_INIT" value="TRUE"/> </tt>.
* The ac_id defined in <tt>conf/conf.xml</tt> is permanently programmed into the modem so this procedure would need to be re-run if the modem is moved to another plane.
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string.
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.

<br style="clear:both>

{{Box Code|confAgain/airframes/myplane.xml - makefile section at the bottom|
<nowiki># Maxstream API protocol</nowiki>
<nowiki>ap.CFLAGS += -DDOWNLINK -DUSE_UART0 -DDOWNLINK_TRANSPORT=XBeeTransport -DDOWNLINK_FBW_DEVICE=Uart0 -DDOWNLINK_AP_DEVICE=Uart0 -DXBEE_UART=Uart0 -DDATALINK=XBEE -DUART0_BAUD=B57600</nowiki>
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki>
}}
The above example configures the autopilot serial port (Uart0) to 57,600 baud and calls the Maxstream transport protocol (xbee.c). Use the "#" symbol to comment lines in this section of the airframe file.
<br style="clear:both>

Ensure that the ground station is using the same protocol and an equal or higher baud rate:
{{Box Code|conf/control_panel.xml|
<nowiki>
<session name="USB">
<program name="link">
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/>
<arg flag="-transport" constant="xbee"/>
<arg flag="-uplink" constant=""/>
<arg flag="-s" constant="57600"/>
</program>
...
</session>
</nowiki>
}}
Use this constant /dev/paparazzi/ttyUSB0 when using either the ftdi cable or a Maxstream USB ground modem.. Otherwise use /dev/ttyUSB0 (the ttyUSB0 being the device that you are using. Note: it might not always be ttyUSB0). This paparazzi directory in the dev folder is created when setting the udev rules. [http://paparazzi.enac.fr/wiki/index.php/Installation#Setting_access_rights_for_USB_download Setting Udev rules]
=====Alternate Method=====
This is the way it is done in funjet1.xml and has been tested to work by Danstah

{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
<section name="MISC">
...
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\""/>

...
</section></nowiki>
}}
Also use this
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>

<section name="DATALINK" prefix="DATALINK_">
<define name="DEVICE_TYPE" value="XBEE"/>
<define name="DEVICE_ADDRESS" value="...."/>
</section>
</nowiki>
}}
And Finally use this in the makefile section
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>
ap.CFLAGS += -DDOWNLINK -DUSE_UART1 -DDOWNLINK_TRANSPORT=XBeeTransport -DXBEE_UART=Uart1 -DDATALINK=XBEE -DUART1_BAUD=B9600
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c
</nowiki>
}}
By reading all the information above you should be able to infer what the above does.

Now keep in mind that the ground modem baud rate and airplanes modem baud rates do not have to match. The only things that need to match are the the modem on the planes baud rate and the rate defined in the airframe file. For example this planes modem is set to 9600 and this could be used with the ground modem configured above using 57600...
Also for multiple UAV's a good way to configure them is to use 9600 for the ap and use a ground modem configured to 57600 and its not a bad idea to use minimal telemetry.

=== GPS ===
The serial port settings must match that of the GPS and are configured here along with the necessary files to interpret the u-blox UBX binary protocol:

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki>
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki>
}}
'''Note:'''
* Tiny 13 v1.1 uses UART1 while Tiny 2 uses UART0 for GPS
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly thru the [[Compiling#USB_flashing|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center Configured with|u-center]]

If using the u-blox LEA-5H, add the flag -DGPS_USE_LATLONG in the makefile section of the airframe xml file in the gps section. This flag must be inserted above "ap.srcs += gps_ubx.c gps.c" for proper operation.

{{Box Code|conf/airframes/myplane.xml|
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400 -DGPS_USE_LATLONG
ap.srcs += gps_ubx.c gps.c</nowiki>
}}

=== Sensors ===

=== Control loops ===

The control loops can be divided in two largely independent groups : the vertical ones and the horizontal ones (files sw/airborne/fw_h_ctl.c and sw/airborne/fw_v_ctl.c ). Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.

First the horizontal loop:
{{Box Code|conf/airframes/funjet1.xml|
<nowiki>ap.CFLAGS += -DNAV -DAGR_CLIMB -DLOITER_TRIM
ap.srcs += nav.c fw_h_ctl.c fw_v_ctl.c
</nowiki>
}}

FunJet

2009-09-08T00:07:06Z

Mcurrie: /* Misc Notes */

[http://www.recherche.enac.fr/paparazzi/wiki/index.php/Airframes <<] Back to Airframes

{|
|-valign="top"
|[[Image:Funjet_flight_dawnron1.jpg|thumb|left|Multiplex FunJet]]
|
The MultiPlex FunJet is an electric pusher-prop jet made of very durable Elapor Particle Foam Construction. It offers plenty of room internally for avionics in an attractive package.
|}

== Features ==

* Suggested Retail Price of $65 USD
* Elapor Particle Foam construction
* Assembles in minutes with only Medium CA glue
* Fiberglass Wing Spar
* Moderately priced
* Detachable canopy for access to internals
* Plastic Motor Mount
* Wide flight speed envelope (slow without stalling, through fast)

== Specifications ==

* Wingspan: 31.29" (795mm)
* Wing Area: 232 sq in (15 sq dm)
* Weight: 21oz (620g) _all up_
* Weight w/o powerplant (for estimation): 330g
* Bare weight: 165g
* Length: 29.52" (750mm)
* Airfoils: Airfoil: Semi-symmetrical, mid wing at the fuselage sides

=== Payload Area ===

* Fuselage is 1.60" (40.6mm) wide x 20" long

== Recommended Setups ==

=== Manufacturer Recommendation ===

Remember this is a hot sport plane so the manufacturers recommendation reflects typical desired performance and may not be the best match for UAV operations.

* Motor: Himax HB2815-3000 Brushless Motor
* Battery: 3S1P 2100-3200mah LiPo
* Servos: 2 Nano sized (HS-55)

=== Group Member Setups ===

'''Martin'''

* Motor: AXI 2212/26
* Battery: 3S1P 2100mAh LiPo
* Prop: 9x6

'''Matthew Currie'''

{|
|[[Image:FJ_MC_ANGLE.jpg|thumb|left|Multiplex FunJet]]
|[[Image:FJ_MC_SIDE.jpg|thumb|left|Multiplex FunJet]]
|[[Image:FJ_UNDERSIDE.JPG|thumb|left|Multiplex FunJet]]
|}

* Motor: AXI 2212/26
* Battery: LiPower Lites 3S1P 2100mAh 18C LiPo
* Prop: APC 9x6E (checked to draw ~ 11.5A)
* Receiver: Berg 4L
* Servos: 2x Hitec HS-55

=== Servos ===

Multiplex calls for 2 Hitec HS-55 or 2 HS-65 servos

=== Hitec HS-55 ===

* MSRP: $13 USD
* Torque: 13/16 oz/in @ 4.8/6.0v
* Speed: 0.09/0.08 seconds/ 60deg @ 4.8/6.0v
* Weight: 0.29 oz (7.8g)
* Size: 0.9 x 0.46 x 0.95"

=== Hitec HS-65HB ===

* MSRP:
* Motor Type: 3 Pole Ferrite
* Bearing Type: Top Ball Bearing
* Torque 4.8/6.0v: 22 / 26 oz (1.6 / 1.9 kg.)
* Speed 4.8/6.0v: 0.16 / 0.13 second
* Size: 0.9"x 0.5"x 0.9" (24 x 12 x 24m)
* Weigh : 0.39oz. 11.2 g.

== Recommended Motors ==
'''Himax HB2815-3000 Brushless Motor'''

[http://www.maxxprod.com/pdf/HB2815-xx00.pdf PDF Datasheet]

* MSRP $69.95 USD
* Dimensions: 27mm x 38mm
* Weight: 86g
* KV: 3000
* Max Amps: 30A
* Max Watts: 275W

'''AXI 2212/26'''

http://www.modelmotors.cz/index.php?page=61&product=2212&serie=26&line=GOLD

MSRP $69.95 USD
* Dimensions: 1-3/32" diameter, 1-3/16" case length, 3.17mm (1/8") shaft
* Weight: 57 g
* KV: 920
* Max Amps: 12A
* Max Watts: 275W
* Prop's:
9x6, 24.5 ounce thrust, 14:12 full throttle.

8x6, 19.5 ounce thrust, 19:38 full throttle.

== Funjet Back Plate Construction ==
{|
|[[Image:Funjet_Back_Plate_Components.jpg|thumb|left|Funjet back plate construction components]]
|}

* A suitable precursor for the back plate is 5mmx75mmx75mm balsa sandwiched by 1mmx75mmx75mm plywood. The laminating adhesive used was PVA glue. The sandwich was left to dry overnight clamped by similar size wooden plates in a vice.

* An outline of The 7mm elapor profile, cut from the back of the Funjet canopy, is drawn in a CAD/CAM program.
:*download ''[[Media:Funjet_Back_Plate_CADopia.pdf|Funjet back plate CADopia drawing (pdf)]]''

* A laser cutting firm transferred this outline to CorelDraw and cut an acrylic (Perspex) template.
:*download ''[[Media:Funjet_Back_Plate_CorelDraw .pdf|Funjet back plate CorelDraw drawing (pdf)]]''

* The balsa/plywood sandwich was attached by double sided tape to the acrylic template and the correct outline achieved by routing around the acrylic border.

{|
|[[Image:Funjet_Back_Plate_Fitted.jpg|thumb|left|Funjet back plate fitted]]
|[[Image:Tiny_v2_1_Funjet.jpg|thumb|left|Tiny v2.1 in a Funjet]]
|}
* The fitted plate looks remarkably similar to that displayed in the image on the right found on the main page of the wiki.

== Online Discussion on FunJet topics ==

* [http://www.rcgroups.com/forums/showpost.php?p=7257031&postcount=2856 Modifying the motor cowling to increase airflow]
* [http://www.rcgroups.com/forums/showthread.php?p=7593625#post7593625 Adding prop spacers to move prop further back]
* [http://www.rcgroups.com/forums/showpost.php?p=7081811&postcount=2582 Mounting a MicroDan 2505 Brushless Outrunner]

== Photos ==

{|
|-
|[[Image:Jet-motor-mount.jpg|thumb|Included Motor Mount]]
|[[Image:Funjet_highvis1_rycomm.jpg|thumb|Example of high visibility paint job]]
|[[Image:Funjet tipprotector sharkbyte.jpg|thumb|Idea for wing tip skid]]
|}

== Misc Notes ==

* [http://www.recherche.enac.fr/paparazzi/wiki_images/FunJet_Manual_English.pdf Multiplex FunJet Instruction Manual - English]
* [http://www.recherche.enac.fr/paparazzi/wiki_images/FunJet_Manual_Multilanguage.pdf Multiplex FunJet Instruction Manual - Original Multilanguage]
* Painting Elapor should be primed [[http://www.phillsmodels.com/acatalog/index.html?http%3A//www.phillsmodels.com/acatalog/Online_Catalogue_Paint_882.html&CatalogBody primer]]

* Fiberglass wing spar: 22.5" (571mm) x .25" (6.35mm)
* Motor Screws (to hold plastic motor plate to plastic motor cowl) are slot head and appear to be 3.0mm x 0.5mm (thread) x 16mm long
* Screws for AXI "outrunner" motor are 3.0mm Diameter x 0.5mm Thread x 6 mm Length

Contact

2008-05-28T19:04:32Z

Mcurrie: /* The IRC Chat Channel */

Get in touch with active members of the group through any of the following means:
== Paparazzi Users Forum ==

http://rc-autopilot.de/smf

== Mailing List ==

Browse the mailing list archives at:<br>
[http://lists.gnu.org/archive/html/paparazzi-devel/ http://lists.gnu.org/archive/html/paparazzi-devel/]

And join the Paparazzi mailing list at:<br>
[http://lists.nongnu.org/mailman/listinfo/paparazzi-devel http://lists.nongnu.org/mailman/listinfo/paparazzi-devel]

After registering, you can send an e-mail to the entire group by using the address: paparazzi-devel@nongnu.org

== The IRC Chat Channel ==

The most active discussion occurs on [http://en.wikipedia.org/wiki/Internet_Relay_Chat IRC] where a dozen or so members are typically online. Stop by anytime and say hello to the group, but don't be discouraged by hours of inactivity at certian times of day. You can use a [http://embed.mibbit.com/?server=irc.freenode.net&channel=%23paparazzi&noServerNotices=true web-based IRC portal] that makes it easy for people to jump in from any computer, but more active users will benefit from the power of conventional client software such as [http://www.xchat.org Xchat] or [http://www.mirc.com mIRC].

=== Web Based Access ===
Simply go to [http://embed.mibbit.com/?server=irc.freenode.net&channel=%23paparazzi&noServerNotices=true www.mibbit.com] or the older interface [http://www.ircatwork.com/ www.ircatwork.com]. Enter the server, channel name, a unique ''nickname'', and say hello to the team!

=== Client Software ===
A full featured IRC chat program is essential for active users. Download one of the many freeware/shareware IRC clients and put [irc://irc.freenode.net/#paparazzi irc://irc.freenode.net/#paparazzi] at the top of your favorites list!
* [http://www.silverex.org/download Xchat2] is a free version of Xchat for windows
* [http://www.xchat.org Xchat] is a popular and easy to use freeware application.
*: Run ''apt-get install xchat'' to install in Linux, or download a [http://b0at.tx0.org/xchat/ Windows build.]
*: Choose '''FreeNode''' and some nicknames in the network list and click '''Edit''' to enter the '''#paparazzi''' channel and a Nicserv password. Follow the instructions below to register your chosen nickname and password on the network.
* [http://www.mirc.com mIRC] is another popular freeware client for Windows only.

==== Registering on the Freenode IRC Network ====

Registering is optional but is required for private one-on-one chats. Private chats are useful for pasting large amounts of code back and forth without flooding the group or for any off-topic discussion you may wish to have. Commands in IRC begin with a forward slash '/'. Type these two commands into your IRC client to register and log on.

Select your own unique password and use it in place of ''<password>''. Make sure you are currently using the "nickname" that you would like to use.

/msg NickServ REGISTER <password>

You will now have registered your nickname to your hostmask (or IP address) and the Freenode IRC network will attempt to prevent others from using your nickname. You will need to identify yourself to the system now every time you log onto IRC with the command below. This can be added to the "perform" section of your software to be run automatically every time you log on.

/msg NickServ IDENTIFY <password>

These commands return output results as well, depending on what IRC client you are using to chat it may have appeared in either your main chat window or a separate server window where other server related messages appear. Check this window for confirmation.

Note: You may find that your IRC connection will occasionally be interrupted, leaving your nic floating on the server. When this happens the server will not let you log back on using the same nic until that nic has been dropped, usually within 30 minutes. The convention is to append an underscore to your original nic for temporary use.

Links

2007-12-31T18:03:30Z

Mcurrie: /* The IRC Chat Channel */

== The Project Page ==

The Paparazzi project is hosted at http://www.nongnu.org/paparazzi/ where the CVS repository is available.

== The IRC Chat Channel ==

Network: Freenode
Network Host: irc.freenode.net
Channel: #paparazzi

* Web Based: Simply go to [http://ircatwork.com ircatwork.com], enter the network host, the channel, a unique ''nickname'', and say hello to the team!
* Client Software: Download one of the many freeware/shareware IRC clients and put [irc://irc.freenode.net/#paparazzi #paparazzi] at the top of your favorites list!
*: [http://www.mirc.com mIRC]
*: [http://www.xchat.org Xchat]

== Paparazzi Users Forum ==

http://rc-autopilot.de/smf - please join and get this forum going

http://groups.yahoo.com/group/paparazzi-autopilot/

== Paparazzi teams/users/contributors ==

http://www.miraterre.com/index.html

http://mecano.gme.usherb.ca/~vamudes/

http://pfump.org

http://www.ismo.hs-bremen.de/dokuwiki/doku.php?id=elem:projekte:intro#semesterprojekte (German)

Links

2007-12-31T18:01:23Z

Mcurrie: /* The IRC Chat Channel */

== The Project Page ==

The Paparazzi project is hosted at http://www.nongnu.org/paparazzi/ where the CVS repository is available.

== The IRC Chat Channel ==

* Network: Freenode (irc.freenode.net)
* Channel: #paparazzi

* Web Based: Simply go to [http://ircatwork.com ircatwork.com], enter the servername (irc.freenode.net), the channel (#paparazzi), a unique ''nickname'', and say hello to the team!
* Client Software: Download one of the many freeware/shareware IRC clients and put [irc://irc.freenode.net/#paparazzi] at the top of your favorites list!
*: [http://www.mirc.com mIRC]
*: [http://www.xchat.org Xchat]

== Paparazzi Users Forum ==

http://rc-autopilot.de/smf - please join and get this forum going

http://groups.yahoo.com/group/paparazzi-autopilot/

== Paparazzi teams/users/contributors ==

http://www.miraterre.com/index.html

http://mecano.gme.usherb.ca/~vamudes/

http://pfump.org

http://www.ismo.hs-bremen.de/dokuwiki/doku.php?id=elem:projekte:intro#semesterprojekte (German)

Links

2007-12-31T18:00:00Z

Mcurrie: /* The IRC Chat Channel */

== The Project Page ==

The Paparazzi project is hosted at http://www.nongnu.org/paparazzi/ where the CVS repository is available.

== The IRC Chat Channel ==

* Web Based: Simply go to [http://ircatwork.com/], enter the servername, channel, a unique ''nickname'', and say hello to the team!
* Client Software: Download one of the many freeware/shareware IRC clients and put [irc://irc.freenode.net/#paparazzi] at the top of your favorites list!
*: [http://www.mirc.com mIRC]
*: [http://www.xchat.org Xchat]

== Paparazzi Users Forum ==

http://rc-autopilot.de/smf - please join and get this forum going

http://groups.yahoo.com/group/paparazzi-autopilot/

== Paparazzi teams/users/contributors ==

http://www.miraterre.com/index.html

http://mecano.gme.usherb.ca/~vamudes/

http://pfump.org

http://www.ismo.hs-bremen.de/dokuwiki/doku.php?id=elem:projekte:intro#semesterprojekte (German)

Tiny Assembly

2007-10-20T01:55:02Z

Mcurrie: /* Tiny13 1.1 Specifics */

== General Tips ==

* Use a quality pair of tweezers, 0402 components will seem like 1/4W resistors again
* Liquid Flux and a small brush or even the lead of a 1/4W resistor will turn a small congealed soldering mess into perfection
* Use optical magnification if you or your eyes need it (it is not necessary however)
* Use a liquid flux cleaner either spray on or brush on and scrub the board clean. This will a) impress your friends b) reveal potential shorts or lack of solder and c) reduce high resistance electrical paths on the board particularly around the A/D section
* Print out a customized and enlarged diagram of the PCB you are working on. Pencil in the component designators by hand while using the graphical desktop environment as an aid
* Print out a Bill of Materials sheet
* 0402 components, if fallen onto a dirty workbench will be hopelessly lost. Use a clean white blotter or even some sheets of paper.
* Populate as little parts as necessary for a first power-up test. In most cases it is perfectly OK to place EVERY component minus the LEA-4P GPS module. Doing this allows you to divide and conquer should a problem arise during assembly.

== Tiny13 1.1 Specifics ==

* Place the vertically shorter tantalum chip capacitors (C18 & C21) near the 3V3 LDO first as you will be able to place the vertically taller with tweezers.
* Place the diode (U$2) next to the large "pulse" inductor before any other backside components
* Do not expect either of the two LEDs to illuminate. They are configured via airborne flight code, you may never see or need them.

== LEA-4P Mounting ==

It is advised not to use hot air reflow rework station / solder paste for this assembly as it is quite easy to "blow" solder underneath the LEA-4P causing a short. Instead apply a small amount of solder flux paste and a small tip soldering iron w/ fine solder. This soldering tip should be as large as will allow you to apply solder to the pins. The LEA-4P and surrounding ground planes are excellent heat sinks so the larger tip you can use the easier it will be. Print out the schematic to see the required pin wiring. Solder only the necessary pins, you will realize why if you ever have to remove the LEA-4P module from the PCB. Realize that the footprint is not symmetrical and will only mount one way so you do not have to go crazy making sure you have the black dot facing the right direction.

== Solder Paste Usage ==

Solder paste can easily become your secret weapon against the difficult placing of the fine-pitch components in use in this project. The most crucial parameter you can control is how much solder paste is used. If too much is used (even 1/10 of a gram too much), you will be left removing many solder bridges between pins and pads manually. Alternatively if too little is used you will be left individually soldering pins.

Below is an example of too much

[[image:SOLDERPASTE_TOOMUCH.jpg]]

this is the result after reflowing: 5 different solder bridges that must be removed. Sometimes it is as easy as applying a small amount of liquid flux to the area then dragging a hot micro tipped iron between the two pins, drawing the bridge towards the pad. You may also want to try copper braid for wicking the excess solder away. I often find this removes too much solder.

[[image:Solderpaste_resulttoomuch.jpg]]

Below is an image where an adequate amount of solder paste was applied.

[[image:Solderpaste_enough.jpg]]

The results of the above solder paste.

[[image:Solderpaste_enough-results.jpg]]

== Expected Current Consumptions ==

Here are some general current guidelines to aid in initial assembly checks.

Tiny13 w/ fresh, unprogrammed LPC & NO LEA-4P GPS: ~15mAh @ 12.3V (185mWh)
Tiny13 running target code (not airborne code) & NO LEA-4P GPS: ~25mAh @ 12.3V (310mWh)
Tiny13 running target code (not airborne code) w/ GPS: ~45mAh @ 12.3V (550mWh)

''The Tiny13 uses a switching supply, realize that you will see varying currents with varied input voltages hence the inclusion of mWh units''

== Some thoughts about starting up a Tiny ==

* populate all parts except the LEA-4P for first tests to make them simpler
* check the polarity of all parts, compare to a picture of a working reference board
* use a microscope or a magnifying glass to check for short circuits
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 7V
* use the on-board supply, do not try to feed voltage from the outside
* the 7V should not drop due to current limiting, measure the 5V and the 3.3V supply on the board
-> wrong voltages: check the parts around the power supply
* measure the current, it should be around 50mA at 7V with the LPC running and no code loaded (switching supply: reduces to around 25mA @12V)
* attach reset, therefore connect LPC_RESET to GND (the board button is NOT reset), current should reduce to 15mA at 7V (10mA @12V)
-> check if reset signal can be measured at the LPC reset pin 57
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)
* connect LPC_TXD_0 and LPC_RXD_0 of Serial1 to the serial port of your PC through a 3.3V-USB-RS232 converter (LPC_TXD_0 - PC_RX, LPC_RX_0 - PC_TX), attach LPC_P0.14 to a buffered PC_RTS or connect to a button
* run the serial ROM loader lpc21isp to flash USB bootloader with
make bl_upload
* pull the LPC_P0.14 line low if not connected to RTS and then reset the board
-> check the rx/tx pins for data if flashing does not succeed
* deattach the LPC_P0.14, reset the board
* the USB bootloader outputs debug information with 115200 8N1 on the serial port
-> try the uart_tunnel from arm7/test, logical high and low should be sent from LPC_RXD_0 to LPC_TXD_1 and LPC_RXD_1 to LPC_TXD_0 (at GPS pins)
* LPC_P0.23 (USB Vbus) should be low, LPC_USB_CONNECT high
-> check parts around Q1
* connect USB+ (D+), USB- (D-), LPC_P0.23 (USB Vbus) and GND of Serial2 with your PC, reset the board
* LPC_P0.23 (USB Vbus) should go high from PC USB, LPC_USB_CONNECT should go low through LPC software
* the PC will detect a new USB device, check with "dmesg" and "lsusb" - they should both show a USB device with VID/PID 7070:1234
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-
* flash the autopilot with
make [AIRCRAFT] ap.upload
* check telemetry through serial port, messages should be displayed
* test A/D converters for supply voltage and IR sensors
* check modem, connect tx, rx, gnd and supply
* try to aquire sats outside

== Troubleshooting ==

Below are some oddball facts discovered in the process of debugging problems. These bits of information may cut a few hours off of a bug chasing adventure.

* With everything on the board, minus the LPC2148 you should see ~ 580 ohms of resistance on 3V3 rail

Tiny Assembly

2007-10-20T01:01:57Z

Mcurrie:

== General Tips ==

* Use a quality pair of tweezers, 0402 components will seem like 1/4W resistors again
* Liquid Flux and a small brush or even the lead of a 1/4W resistor will turn a small congealed soldering mess into perfection
* Use optical magnification if you or your eyes need it (it is not necessary however)
* Use a liquid flux cleaner either spray on or brush on and scrub the board clean. This will a) impress your friends b) reveal potential shorts or lack of solder and c) reduce high resistance electrical paths on the board particularly around the A/D section
* Print out a customized and enlarged diagram of the PCB you are working on. Pencil in the component designators by hand while using the graphical desktop environment as an aid
* Print out a Bill of Materials sheet
* 0402 components, if fallen onto a dirty workbench will be hopelessly lost. Use a clean white blotter or even some sheets of paper.
* Populate as little parts as necessary for a first power-up test. In most cases it is perfectly OK to place EVERY component minus the LEA-4P GPS module. Doing this allows you to divide and conquer should a problem arise during assembly.

== Tiny13 1.1 Specifics ==

* Place the vertically shorter tantalum chip capacitors near the supply first as you will be able to place the vertically taller with tweezers.
* Place the diode next to the large "pulse" inductor before any other backside components'
* Do not expect either of the two LEDs to illuminate. They are configured via airborne flight code, you may never see or need them.

== LEA-4P Mounting ==

It is advised not to use hot air reflow rework station / solder paste for this assembly as it is quite easy to "blow" solder underneath the LEA-4P causing a short. Instead apply a small amount of solder flux paste and a small tip soldering iron w/ fine solder. This soldering tip should be as large as will allow you to apply solder to the pins. The LEA-4P and surrounding ground planes are excellent heat sinks so the larger tip you can use the easier it will be. Print out the schematic to see the required pin wiring. Solder only the necessary pins, you will realize why if you ever have to remove the LEA-4P module from the PCB. Realize that the footprint is not symmetrical and will only mount one way so you do not have to go crazy making sure you have the black dot facing the right direction.

== Solder Paste Usage ==

Solder paste can easily become your secret weapon against the difficult placing of the fine-pitch components in use in this project. The most crucial parameter you can control is how much solder paste is used. If too much is used (even 1/10 of a gram too much), you will be left removing many solder bridges between pins and pads manually. Alternatively if too little is used you will be left individually soldering pins.

Below is an example of too much

[[image:SOLDERPASTE_TOOMUCH.jpg]]

this is the result after reflowing: 5 different solder bridges that must be removed. Sometimes it is as easy as applying a small amount of liquid flux to the area then dragging a hot micro tipped iron between the two pins, drawing the bridge towards the pad. You may also want to try copper braid for wicking the excess solder away. I often find this removes too much solder.

[[image:Solderpaste_resulttoomuch.jpg]]

Below is an image where an adequate amount of solder paste was applied.

[[image:Solderpaste_enough.jpg]]

The results of the above solder paste.

[[image:Solderpaste_enough-results.jpg]]

== Expected Current Consumptions ==

Here are some general current guidelines to aid in initial assembly checks.

Tiny13 w/ fresh, unprogrammed LPC & NO LEA-4P GPS: ~15mAh @ 12.3V (185mWh)
Tiny13 running target code (not airborne code) & NO LEA-4P GPS: ~25mAh @ 12.3V (310mWh)
Tiny13 running target code (not airborne code) w/ GPS: ~45mAh @ 12.3V (550mWh)

''The Tiny13 uses a switching supply, realize that you will see varying currents with varied input voltages hence the inclusion of mWh units''

== Some thoughts about starting up a Tiny ==

* populate all parts except the LEA-4P for first tests to make them simpler
* check the polarity of all parts, compare to a picture of a working reference board
* use a microscope or a magnifying glass to check for short circuits
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 7V
* use the on-board supply, do not try to feed voltage from the outside
* the 7V should not drop due to current limiting, measure the 5V and the 3.3V supply on the board
-> wrong voltages: check the parts around the power supply
* measure the current, it should be around 50mA at 7V with the LPC running and no code loaded (switching supply: reduces to around 25mA @12V)
* attach reset, therefore connect LPC_RESET to GND (the board button is NOT reset), current should reduce to 15mA at 7V (10mA @12V)
-> check if reset signal can be measured at the LPC reset pin 57
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)
* connect LPC_TXD_0 and LPC_RXD_0 of Serial1 to the serial port of your PC through a 3.3V-USB-RS232 converter (LPC_TXD_0 - PC_RX, LPC_RX_0 - PC_TX), attach LPC_P0.14 to a buffered PC_RTS or connect to a button
* run the serial ROM loader lpc21isp to flash USB bootloader with
make bl_upload
* pull the LPC_P0.14 line low if not connected to RTS and then reset the board
-> check the rx/tx pins for data if flashing does not succeed
* deattach the LPC_P0.14, reset the board
* the USB bootloader outputs debug information with 115200 8N1 on the serial port
-> try the uart_tunnel from arm7/test, logical high and low should be sent from LPC_RXD_0 to LPC_TXD_1 and LPC_RXD_1 to LPC_TXD_0 (at GPS pins)
* LPC_P0.23 (USB Vbus) should be low, LPC_USB_CONNECT high
-> check parts around Q1
* connect USB+ (D+), USB- (D-), LPC_P0.23 (USB Vbus) and GND of Serial2 with your PC, reset the board
* LPC_P0.23 (USB Vbus) should go high from PC USB, LPC_USB_CONNECT should go low through LPC software
* the PC will detect a new USB device, check with "dmesg" and "lsusb" - they should both show a USB device with VID/PID 7070:1234
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-
* flash the autopilot with
make [AIRCRAFT] ap.upload
* check telemetry through serial port, messages should be displayed
* test A/D converters for supply voltage and IR sensors
* check modem, connect tx, rx, gnd and supply
* try to aquire sats outside

== Troubleshooting ==

Below are some oddball facts discovered in the process of debugging problems. These bits of information may cut a few hours off of a bug chasing adventure.

* With everything on the board, minus the LPC2148 you should see ~ 580 ohms of resistance on 3V3 rail

Tiny Assembly

2007-10-20T01:00:09Z

Mcurrie: /* Some thoughts about starting up a Tiny */

== General Tips ==

* Use a quality pair of tweezers, 0402 components will seem like 1/4W resistors again
* Liquid Flux and a small brush or even the lead of a 1/4W resistor will turn a small congealed soldering mess into perfection
* Use optical magnification if you or your eyes need it (it is not necessary however)
* Use a liquid flux cleaner either spray on or brush on and scrub the board clean. This will a) impress your friends b) reveal potential shorts or lack of solder and c) reduce high resistance electrical paths on the board particularly around the A/D section
* Print out a customized and enlarged diagram of the PCB you are working on. Pencil in the component designators by hand while using the graphical desktop environment as an aid
* Print out a Bill of Materials sheet
* 0402 components, if fallen onto a dirty workbench will be hopelessly lost. Use a clean white blotter or even some sheets of paper.
* Populate as little parts as necessary for a first power-up test. In most cases it is perfectly OK to place EVERY component minus the LEA-4P GPS module. Doing this allows you to divide and conquer should a problem arise during assembly.

== Tiny13 1.1 Specifics ==

* Place the vertically shorter tantalum chip capacitors near the supply first as you will be able to place the vertically taller with tweezers.
* Place the diode next to the large "pulse" inductor before any other backside components'
* Do not expect either of the two LEDs to illuminate. They are configured via airborne flight code, you may never see or need them.

== LEA-4P Mounting ==

It is advised not to use hot air reflow rework station / solder paste for this assembly as it is quite easy to "blow" solder underneath the LEA-4P causing a short. Instead apply a small amount of solder flux paste and a small tip soldering iron w/ fine solder. This soldering tip should be as large as will allow you to apply solder to the pins. The LEA-4P and surrounding ground planes are excellent heat sinks so the larger tip you can use the easier it will be. Print out the schematic to see the required pin wiring. Solder only the necessary pins, you will realize why if you ever have to remove the LEA-4P module from the PCB. Realize that the footprint is not symmetrical and will only mount one way so you do not have to go crazy making sure you have the black dot facing the right direction.

== Solder Paste Usage ==

Solder paste can easily become your secret weapon against the difficult placing of the fine-pitch components in use in this project. The most crucial parameter you can control is how much solder paste is used. If too much is used (even 1/10 of a gram too much), you will be left removing many solder bridges between pins and pads manually. Alternatively if too little is used you will be left individually soldering pins.

Below is an example of too much

[[image:SOLDERPASTE_TOOMUCH.jpg]]

this is the result after reflowing: 5 different solder bridges that must be removed. Sometimes it is as easy as applying a small amount of liquid flux to the area then dragging a hot micro tipped iron between the two pins, drawing the bridge towards the pad. You may also want to try copper braid for wicking the excess solder away. I often find this removes too much solder.

[[image:Solderpaste_resulttoomuch.jpg]]

Below is an image where an adequate amount of solder paste was applied.

[[image:Solderpaste_enough.jpg]]

The results of the above solder paste.

[[image:Solderpaste_enough-results.jpg]]

== Expected Current Consumptions ==

Here are some general current guidelines to aid in initial assembly checks.

Tiny13 w/ fresh, unprogrammed LPC & NO LEA-4P GPS: ~15mAh @ 12.3V (185mWh)
Tiny13 running target code (not airborne code) & NO LEA-4P GPS: ~25mAh @ 12.3V (310mWh)
Tiny13 running target code (not airborne code) w/ GPS: ~45mAh @ 12.3V (550mWh)

''The Tiny13 uses a switching supply, realize that you will see varying currents with varied input voltages hence the inclusion of mWh units''

== Some thoughts about starting up a Tiny ==

* populate all parts except the LEA-4P for first tests to make them simpler
* check the polarity of all parts, compare to a picture of a working reference board
* use a microscope or a magnifying glass to check for short circuits
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 7V
* use the on-board supply, do not try to feed voltage from the outside
* the 7V should not drop due to current limiting, measure the 5V and the 3.3V supply on the board
-> wrong voltages: check the parts around the power supply
* measure the current, it should be around 50mA at 7V with the LPC running and no code loaded (switching supply: reduces to around 25mA @12V)
* attach reset, therefore connect LPC_RESET to GND (the board button is NOT reset), current should reduce to 15mA at 7V (10mA @12V)
-> check if reset signal can be measured at the LPC reset pin 57
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)
* connect LPC_TXD_0 and LPC_RXD_0 of Serial1 to the serial port of your PC through a 3.3V-USB-RS232 converter (LPC_TXD_0 - PC_RX, LPC_RX_0 - PC_TX), attach LPC_P0.14 to a buffered PC_RTS or connect to a button
* run the serial ROM loader lpc21isp to flash USB bootloader with
make bl_upload
* pull the LPC_P0.14 line low if not connected to RTS and then reset the board
-> check the rx/tx pins for data if flashing does not succeed
* deattach the LPC_P0.14, reset the board
* the USB bootloader outputs debug information with 115200 8N1 on the serial port
-> try the uart_tunnel from arm7/test, logical high and low should be sent from LPC_RXD_0 to LPC_TXD_1 and LPC_RXD_1 to LPC_TXD_0 (at GPS pins)
* LPC_P0.23 (USB Vbus) should be low, LPC_USB_CONNECT high
-> check parts around Q1
* connect USB+ (D+), USB- (D-), LPC_P0.23 (USB Vbus) and GND of Serial2 with your PC, reset the board
* LPC_P0.23 (USB Vbus) should go high from PC USB, LPC_USB_CONNECT should go low through LPC software
* the PC will detect a new USB device, check with "dmesg" and "lsusb" - they should both show a USB device with VID/PID 7070:1234
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-
* flash the autopilot with
make [AIRCRAFT] ap.upload
* check telemetry through serial port, messages should be displayed
* test A/D converters for supply voltage and IR sensors
* check modem, connect tx, rx, gnd and supply
* try to aquire sats outside

Tiny Assembly

2007-10-20T00:59:10Z

Mcurrie: /* Some thoughts about starting up a Tiny */

== General Tips ==

* Use a quality pair of tweezers, 0402 components will seem like 1/4W resistors again
* Liquid Flux and a small brush or even the lead of a 1/4W resistor will turn a small congealed soldering mess into perfection
* Use optical magnification if you or your eyes need it (it is not necessary however)
* Use a liquid flux cleaner either spray on or brush on and scrub the board clean. This will a) impress your friends b) reveal potential shorts or lack of solder and c) reduce high resistance electrical paths on the board particularly around the A/D section
* Print out a customized and enlarged diagram of the PCB you are working on. Pencil in the component designators by hand while using the graphical desktop environment as an aid
* Print out a Bill of Materials sheet
* 0402 components, if fallen onto a dirty workbench will be hopelessly lost. Use a clean white blotter or even some sheets of paper.
* Populate as little parts as necessary for a first power-up test. In most cases it is perfectly OK to place EVERY component minus the LEA-4P GPS module. Doing this allows you to divide and conquer should a problem arise during assembly.

== Tiny13 1.1 Specifics ==

* Place the vertically shorter tantalum chip capacitors near the supply first as you will be able to place the vertically taller with tweezers.
* Place the diode next to the large "pulse" inductor before any other backside components'
* Do not expect either of the two LEDs to illuminate. They are configured via airborne flight code, you may never see or need them.

== LEA-4P Mounting ==

It is advised not to use hot air reflow rework station / solder paste for this assembly as it is quite easy to "blow" solder underneath the LEA-4P causing a short. Instead apply a small amount of solder flux paste and a small tip soldering iron w/ fine solder. This soldering tip should be as large as will allow you to apply solder to the pins. The LEA-4P and surrounding ground planes are excellent heat sinks so the larger tip you can use the easier it will be. Print out the schematic to see the required pin wiring. Solder only the necessary pins, you will realize why if you ever have to remove the LEA-4P module from the PCB. Realize that the footprint is not symmetrical and will only mount one way so you do not have to go crazy making sure you have the black dot facing the right direction.

== Solder Paste Usage ==

Solder paste can easily become your secret weapon against the difficult placing of the fine-pitch components in use in this project. The most crucial parameter you can control is how much solder paste is used. If too much is used (even 1/10 of a gram too much), you will be left removing many solder bridges between pins and pads manually. Alternatively if too little is used you will be left individually soldering pins.

Below is an example of too much

[[image:SOLDERPASTE_TOOMUCH.jpg]]

this is the result after reflowing: 5 different solder bridges that must be removed. Sometimes it is as easy as applying a small amount of liquid flux to the area then dragging a hot micro tipped iron between the two pins, drawing the bridge towards the pad. You may also want to try copper braid for wicking the excess solder away. I often find this removes too much solder.

[[image:Solderpaste_resulttoomuch.jpg]]

Below is an image where an adequate amount of solder paste was applied.

[[image:Solderpaste_enough.jpg]]

The results of the above solder paste.

[[image:Solderpaste_enough-results.jpg]]

== Expected Current Consumptions ==

Here are some general current guidelines to aid in initial assembly checks.

Tiny13 w/ fresh, unprogrammed LPC & NO LEA-4P GPS: ~15mAh @ 12.3V (185mWh)
Tiny13 running target code (not airborne code) & NO LEA-4P GPS: ~25mAh @ 12.3V (310mWh)
Tiny13 running target code (not airborne code) w/ GPS: ~45mAh @ 12.3V (550mWh)

''The Tiny13 uses a switching supply, realize that you will see varying currents with varied input voltages hence the inclusion of mWh units''

== Some thoughts about starting up a Tiny ==

* populate all parts except the LEA-4P for first tests to make them simpler
* check the polarity of all parts, compare to a picture of a working reference board
* use a microscope or a magnifying glass to check for short circuits
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 7V
* With everything on the board, minus the LPC2148 you should see ~ 580 ohms of resistance on 3V3 rail
* use the on-board supply, do not try to feed voltage from the outside
* the 7V should not drop due to current limiting, measure the 5V and the 3.3V supply on the board
-> wrong voltages: check the parts around the power supply
* measure the current, it should be around 50mA at 7V with the LPC running and no code loaded (switching supply: reduces to around 25mA @12V)
* attach reset, therefore connect LPC_RESET to GND (the board button is NOT reset), current should reduce to 15mA at 7V (10mA @12V)
-> check if reset signal can be measured at the LPC reset pin 57
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)
* connect LPC_TXD_0 and LPC_RXD_0 of Serial1 to the serial port of your PC through a 3.3V-USB-RS232 converter (LPC_TXD_0 - PC_RX, LPC_RX_0 - PC_TX), attach LPC_P0.14 to a buffered PC_RTS or connect to a button
* run the serial ROM loader lpc21isp to flash USB bootloader with
make bl_upload
* pull the LPC_P0.14 line low if not connected to RTS and then reset the board
-> check the rx/tx pins for data if flashing does not succeed
* deattach the LPC_P0.14, reset the board
* the USB bootloader outputs debug information with 115200 8N1 on the serial port
-> try the uart_tunnel from arm7/test, logical high and low should be sent from LPC_RXD_0 to LPC_TXD_1 and LPC_RXD_1 to LPC_TXD_0 (at GPS pins)
* LPC_P0.23 (USB Vbus) should be low, LPC_USB_CONNECT high
-> check parts around Q1
* connect USB+ (D+), USB- (D-), LPC_P0.23 (USB Vbus) and GND of Serial2 with your PC, reset the board
* LPC_P0.23 (USB Vbus) should go high from PC USB, LPC_USB_CONNECT should go low through LPC software
* the PC will detect a new USB device, check with "dmesg" and "lsusb" - they should both show a USB device with VID/PID 7070:1234
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-
* flash the autopilot with
make [AIRCRAFT] ap.upload
* check telemetry through serial port, messages should be displayed
* test A/D converters for supply voltage and IR sensors
* check modem, connect tx, rx, gnd and supply
* try to aquire sats outside

Tiny v1.1

2007-10-20T00:57:44Z

Mcurrie: /* Home Assembly */

The Tiny autopilot was designed with an end user application in mind.

== Features ==

* Single LPC2148 MCU
* 8 Analog input channels 0V - 3.3V
* 1 3.3V TTL UART (5V tolerant)
* 7 PWM outputs
* 1 R/C receiver PWM frame input
* 1 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* 1 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus
* 1 USB (client)
* Integrated GPS receiver and patch antenna (4Hz update)
* 5V/2A switching power supply & 3.3V linear regulator
* 2 LEDs (status display)
* 1 button (initiate launch)
* 25 grams
* 63 x 35mm (smaller then a business card)

The Tiny autopilot uses a single Philips LPC2148 ARM7 based microcontroller.
The [http://www.arm.com/products/CPUs/families/ARM7Family.html ARM7] is a low-power 32-bit RISC processor core and the [http://www.standardics.philips.com/products/lpc2000/ Philips LPC2148] has 512KB on-chip Flash ROM, 40KB RAM and can be clocked at 60MHz.

Although critical control code such as the R/C interface and servo output are well segregated in Paparazzi software and well protected from interference from flaws in the stability/navigation/comm/payload code, great care must be taken when experimenting with new software as some errors can cause a the processor to halt or stall for extended periods causing total loss of control. The dual processor [[Classix]] addresses this risk by runnning critical code on a separate independent processor.

The schematics are available from the [http://cvs.savannah.nongnu.org/viewcvs/paparazzi3/hw/controller/?root=paparazzi CVS repository].
<br>

[[Image:TINY_1.3_MCU_300PX.jpg]]
[[Image:TINY_1.3_MCU_BOTTOM_300PX.jpg]]

== Architecture ==

[[Image:Tiny_v099_Architecture.gif]]

== Pinout ==
'''(Tiny13 v1.1)'''

[[Image:Tiny13_v1_1_pinout.gif]]
<br style="clear:both">

''Pins Name and Type are specified with respect to the Autopilot Board''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
|+'''SERIAL 1'''
!''Pin #''!!''Name''!!''Type''!!''Desription''!!width="50"|''Suggested Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3.3v||PWR||3.3v Rail from Tiny||style="background:red; color:white"|Red
|-
|3||SDA0||I/O O.D.||I2C0 data||
|-
|4||SCL0||I/O O.D.||I2C0 clock||
|-
|5||P0.14||IN||In-Circuit Serial Programming (ISP) enable - LOW on this pin during boot up to enable ''(Note 1)''||
|-
|6||RESET||IN||External Reset - A LOW on this pin performs a MCU hardware reset||
|-
|7||RXD_0||IN||UART0 Serial Input (used by ISP Serial Bootloader) (5V Tolerant)||style="background:green; color:white"|Green
|-
|8||TXD_0||OUT||UART0 Serial Output (used by ISP Serial Bootloader) (5V Tolerant)||style="background:blue; color:white"|Blue
|}

''Note 1 : Holding this pin low for at least 3mS after a RESET (or power up) instructs the controller to enter programming mode.''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
|+'''SERIAL 2'''
!''Pin #''!!''Name''!!''Type''!!''Desription''!!width="50"|''Suggested Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3.3V||PWR||3.3v Rail from Tiny||style="background:red; color:white"|Red
|-
|3||SCK||I/O||SPI0 Serial clock. Clock output from master or input to slave||
|-
|4||MISO||I/O||SPI0 Master In Slave Out. Data input to master or data output from slave||
|-
|5||MOSI||I/O||SPI0 Master Out Slave In. Data output from master or data input to slave||
|-
|6||SSEL||IN||SSP Slave Select. Selects the SSP interface as a slave (SSEL1)||
|-
|7||INT||IN||External interrupt 2 input (EINT2)||
|-
|8||USB+||I/O||USB bidirectional D+ line||style="background:green; color:white"|Green
|-
|9||USB-||I/O||USB bidirectional D- line||style="background:white; color:black"|White
|-
|10||P0.23||IN||Indicates the presence of USB bus power (VBUS) (5V Tolerant)||style="background:orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
|+'''RC'''
!''Pin #''!!''Name''!!''Type''!!''Desription''!!width="50"|''Suggested Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +5v||PWR||5v Rail from Tiny to R/C receiver supply||style="background:red; color:white"|Red
|-
|3||PPM_IN||IN||PPM Stream from RC Receiver (5V TOLERANT)||style="background:white; color:black"|White
|-
|4||NC||-||''no connection''||
|-
|5||NC||-||''no connection''||
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
|+'''ANALOG'''
!''Pin #''!!''Name''!!''Type''!!''Desription''!!width="50"|''Suggested Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3.3V||PWR||3.3v Rail from Tiny||style="background:red; color:white"|Red
|-
|3||ADC_0||IN||Analog to Digital Converter Input #0||
|-
|4||ADC_1||IN||Analog to Digital Converter Input #1||
|-
|5||ADC_2||IN||Analog to Digital Converter Input #2||
|-
|6||ADC_3||IN||Analog to Digital Converter Input #3||
|-
|7||ADC_4||IN||Analog to Digital Converter Input #4||
|-
|8||ADC_5||IN||Analog to Digital Converter Input #5||
|-
|9||ADC_6||IN||Analog to Digital Converter Input #6||
|-
|10||ADC_7||IN||Analog to Digital Converter Input #7||
|}

'''POWER SUPPLY'''<br>
For reference, Matthew Currie is assembling his Tiny(s) with WS Deans Micro 2R connectors for power as they are a commonly available R/C connector and are of high quality and durability. They do not have a positive lock mechanism but insert under a lot of pressure. They do not require any special crimping tools and withstand up to 10A.

[[Image:Wsdm3007.png]]

== Bill of Materials (BOM) ==

Please note that there are differences between 0.9, 0.99, and 1.1. Choose the version that matches your hardware.

'''Warning''': C20 needs to be a low ESR capacitor and the one listed on the BOM isn't. A proper replacement would be B45197A2226K209. This could potentially cause instability of the 3V3 supply which, of course, is critical.

=== Tiny 1.1 BOM ===

[http://www.recherche.enac.fr/paparazzi/wiki_images/b/b1/1.1_bom.zip 1.1_bom.zip]

Addendum: There are digikey part numbers for two more of the components.
Murata inductor is 490-1116-1-ND
Tactile Switch is either SW1020CT-ND (grounded) or SW1021CT-ND.

=== Tiny 0.99 BOM ===
<small>
{|
|-valign="top"
|Qty ||Value||Device||Parts||Manufacturer||PN||distr PN
|-valign="top"
||7 || - ||53047-03 ||CAMERA, RC_RX, S0, S1, S3, S4, S5 ||Molex ||53047-0310 ||DK WM1732-ND
|-valign="top"
||1 || - ||53047-04 ||VIDEO_TX ||Molex ||53047-0410 ||DK WM1733-ND
|-valign="top"
||1 || - ||53047-08 ||SERIAL_1 ||Molex ||53047-0810 ||DK WM1737-ND
|-valign="top"
||2 || - ||53047-10 ||ANALOG, SERIAL_2 ||Molex ||53047-1010 ||DK WM1739-ND
|-valign="top"
||1 ||FUTABA_BEND ||FUTABA_BEND ||CON_ESC || - || - || -
|-valign="top"
||2 ||LEDCHIP ||LED0805 ||LED1, LED2 ||Kingbright ||APT2012EC ||MO 604-APT2012EC
|-valign="top"
||1 ||B3S ||B3S ||SW1 || OMRON ELECTRONICS || B3S-1002 || RS 183-717
|-valign="top"
||1 ||0.47uH ||L-EUL2012C ||L2 || WURTH ELEKTRONIK || 74479032 || RS 308-8564
|-valign="top"
||1 ||15uH ||WE_PD ||L1 ||Pulse ||P1168.153T ||MO 673-P1168.153T
|-valign="top"
||2 ||33R ||R-EU_R1005 ||R9, R10 ||Yageo ||RC0402JR-0733L ||DK 311-33JRCT-ND
|-valign="top"
||1 ||150R ||R-EU_R1005 ||R12 ||Yageo ||RC0402JR-07150L ||DK 311-150JRCT-ND
|-valign="top"
||3 ||1K ||R-EU_R1005 ||R2, R3, R8 ||Yageo ||RC0402JR-071KL ||DK 311-1.0KJRCT-ND
|-valign="top"
||1 ||1.5K ||R-EU_R1005 ||R11 ||Yageo ||RC0402JR-071K5L ||DK 311-1.5KJRCT-ND
|-valign="top"
||2 ||3.3K ||R-EU_R1005 ||R6, R15 ||Yageo ||RC0402JR-073K3L ||DK 311-3.3KJRCT-ND
|-valign="top"
||1 ||4.7K ||R-EU_R1005 ||R1 ||Yageo ||RC0402JR-074K7L ||DK 311-4.7KJRCT-ND
|-valign="top"
||7 ||10K ||R-EU_R1005 ||R4, R5, R13, R14, R16, R17, R18 ||Yageo ||RC0402JR-0710KL ||DK 311-10KJRCT-ND
|-valign="top"
||2 ||12K ||R-EU_R1005 ||R103, R105 ||Yageo ||RC0402JR-0712KL ||DK 311-12KJRCT-ND
|-valign="top"
||1 ||15K ||R-EU_R1005 ||R7 ||Yageo ||RC0402JR-0715KL ||DK 311-15KJRCT-ND
|-valign="top"
||2 ||56K ||R-EU_R1005 ||R102, R104 ||Yageo ||RC0402JR-0756KL ||DK 311-56KJRCT-ND
|-valign="top"
||1 ||100K ||R-EU_R1005 ||R101 ||Yageo ||RC0402JR-07100KL ||DK 311-100KJRCT-ND
|-valign="top"
||3 ||18pF ||C-EUC0402K ||C3, C7, C10 ||TDK ||C1005C0G1H180J ||DK 445-1238-1-ND
|-valign="top"
||2 ||22pF ||C-EUC0402K ||C8_1, C9_1 ||Yageo ||CC0402JRNPO9BN220 ||DK 311-1018-1-ND
|-valign="top"
||1 ||100pF ||C-EUC0402K ||C103 ||Kemet ||C0402C101J3GACTU ||DK 399-1022-1-ND
|-valign="top"
||1 ||220pF ||C-EUC0402K ||C102 ||Kemet ||C0402C221K5RACTU ||DK 399-1030-1-ND
|-valign="top"
||1 ||220pF/50V ||C-EUC1206K ||C4 ||Yageo ||CC1206KRX7R9BB221 ||DK 311-1164-1-ND
|-valign="top"
||1 ||1nF ||C-EUC0402K ||C104 ||Kemet ||C0402C102K3RACTU ||DK 399-1031-1-ND
|-valign="top"
||1 ||3.3nF ||C-EUC0402K ||C101 ||Kemet ||C0402C332K5RACTU ||DK 399-3070-1-ND
|-valign="top"
||1 ||22nF/50V ||C-EUC1206K ||C6 ||Yageo ||CC1206KRX7R9BB222 ||DK 311-1176-1-ND
|-valign="top"
||8 ||100nF ||C-EUC0402K ||C1_1, C2, C3_1, C4_1, C5_1, C6_1, C7_1, C106 ||Kemet ||C0402C104K8PACTU ||DK 99-3027-1-ND
|-valign="top"
||3 ||100nF ||C-EUC0603 ||C8, C9, C21 ||Kemet ||C0603C104J4RACTU ||DK 399-1097-1-ND
|-valign="top"
||1 ||10uF ||CPOL-EUA/3216-18R ||C18, C105 ||Kemet ||T491A106M010AS ||DK 399-1564-1-ND MO-80-T491A106K010
|-valign="top"
||1 ||22uF ||CPOL-EUB/3528-21R ||C20 ||Kemet ||B45196H1226M209 ||DK 495-2185-1-ND
|-valign="top"
||1 ||47uF/16V ||CPOL-EUD/7343-31R ||C5 ||Kemet ||B45197A3476K409 ||DK 495-1544-1-ND
|-valign="top"
||1 ||330uF/10V ||CPOL-EUD/7343-31R ||C1 ||Kemet ||B45197A2337K509 ||DK 495-1536-1-ND
|-valign="top"
||1 ||0.2F ||J1ROUND ||C77 ||Panasonic - ECG ||EEC-EN0F204J1 ||DK P11070CT-ND
|-valign="top"
||1 ||AD8552RU ||AD8552RU ||IC2 ||Analog Devices Inc ||AD8552ARU ||DK AD8552ARU-ND
|-valign="top"
||1 ||BAS70 ||BAS70 ||D1 ||Micro Commercial Co. ||BAS40-TP ||DK BAS40TPMSCT-ND
|-valign="top"
||1 ||STPS2L ||STPS2L ||D2 ||STMicroelectronics ||STPS2L30A ||DK 497-3759-1-ND
|-valign="top"
||1 ||CD4015B ||CD4015B ||IC1 ||Texas Instruments ||CD4015BPWR ||DK 296-14090-1-ND
|-valign="top"
||1 ||12MHz ||CRYSTAL_CTS ||Q1 ||CTS-Frequency Controls ||405C35B12M00000 ||DK CTX639CT-ND
|-valign="top"
||1 ||DDTA143 ||MUN2111T1 ||T1 ||Diodes Inc ||DDTA143ZCA-7 ||DK DDTA143ZCADICT-ND
|-valign="top"
||1 ||L5973D ||L5973D ||REG1 ||STMicroelectronics ||L5973D013TR ||DK 497-3638-1-ND
|-valign="top"
||1 ||REG1117 ||REG1117 ||REG2 ||National Semiconductor ||LM1117MP-3.3 ||DK LM1117MP-3.3CT-ND
|-valign="top"
||1 ||LEA-4P ||LEA-4P ||GPS ||Microblox ||LEA-4P-0-000-0 || -
|-valign="top"
||1 ||GPS_ANT_13 ||GPS_ANT_13 ||ANTENNA ||Sangshin || KSA-ST1580MS13 || -
|-valign="top"
||1 ||LPC2148 ||LPC2148 ||MCU ||Philips ||LPC2148FBD64-S ||DK 568-1765-ND
|-
|}

DK = digikey

MO = mouser

RS = radiospares
</small>

== Home Assembly ==

Visit here for the wiki page on [[Tiny_Assembly|Self Assembly Tips and Techniques]]. This page also includes Hardware Troubleshooting.

== Programming ==
[[Image:Tiny_test_wiring.jpg|thumb|Example wiring for programming and telemetry]]
The Philips LPC21xx series ARM7 microcontrollers include hardware ISP (InCircuit Serial Programming) and can be programmed through the serial interface UART0 (Serial1) by holding pin P0.14 low during power-up. Paparazzi software includes a USB bootloader program that allows for easy 1-second programming through a standard USB port with no adapters needed. This allows us to upload new settings, flight plans, or software updates quickly and conveniently without the need to disconnect the modem from UART0. <br>See the [[Compiling|Compiling and Flashing]] page for instructions on installing the bootloader and autopilot software.

Contact

2007-10-15T17:23:11Z

Mcurrie:

Get in touch with active members of the group through any of the following means:
== Paparazzi Users Forum ==

http://rc-autopilot.de/smf

== Mailing List ==

Browse the mailing list archives at:<br>
[http://lists.gnu.org/archive/html/paparazzi-devel/ http://lists.gnu.org/archive/html/paparazzi-devel/]

And join the Paparazzi mailing list at:<br>
[http://lists.nongnu.org/mailman/listinfo/paparazzi-devel http://lists.nongnu.org/mailman/listinfo/paparazzi-devel]

After registering, you can send an e-mail to the entire group by using the address: paparazzi-devel@nongnu.org

== The IRC Chat Channel ==

The most active discussion occurs on [http://en.wikipedia.org/wiki/Internet_Relay_Chat IRC] where a dozen or so members are typically online. Stop by anytime and say hello to the group, but don't be discouraged by hours of inactivity at certian times of day. We run a [http://hq.curtek.com/cgi-bin/irc.cgi web-based IRC portal] that makes it easy for people to jump in from any computer, but more active users will benefit from the power of conventional client software such as [http://www.xchat.org Xchat] or [http://www.mirc.com mIRC].

=== Web Based Access ===
Simply go to [http://www.ircatwork.com/ www.ircatwork.com]. Enter the server, channel name, a unique ''nickname'', and say hello to the team!

=== Client Software ===
A full featured IRC chat program is essential for active users. Download one of the many freeware/shareware IRC clients and put [irc://irc.freenode.net/#paparazzi irc://irc.freenode.net/#paparazzi] at the top of your favorites list!
* [http://www.xchat.org Xchat] is a popular and easy to use freeware application.
*: Run ''apt-get install xchat'' to install in Linux, or download a [http://b0at.tx0.org/xchat/ Windows build.]
*: Choose '''FreeNode''' and some nicknames in the network list and click '''Edit''' to enter the '''#paparazzi''' channel and a Nicserv password. Follow the instructions below to register your chosen nickname and password on the network.
* [http://www.mirc.com mIRC] is another popular freeware client for Windows only.

==== Registering on the Freenode IRC Network ====

Registering is optional but is required for private one-on-one chats. Private chats are useful for pasting large amounts of code back and forth without flooding the group or for any off-topic discussion you may wish to have. Commands in IRC begin with a forward slash '/'. Type these two commands into your IRC client to register and log on.

Select your own unique password and use it in place of ''<password>''. Make sure you are currently using the "nickname" that you would like to use.

/msg NickServ REGISTER <password>

You will now have registered your nickname to your hostmask (or IP address) and the Freenode IRC network will attempt to prevent others from using your nickname. You will need to identify yourself to the system now every time you log onto IRC with the command below. This can be added to the "perform" section of your software to be run automatically every time you log on.

/msg NickServ IDENTIFY <password>

These commands return output results as well, depending on what IRC client you are using to chat it may have appeared in either your main chat window or a separate server window where other server related messages appear. Check this window for confirmation.

Note: You may find that your IRC connection will occasionally be interrupted, leaving your nic floating on the server. When this happens the server will not let you log back on using the same nic until that nic has been dropped, usually within 30 minutes. The convention is to append an underscore to your original nic for temporary use.

Airframes

2007-10-11T21:12:18Z

Mcurrie: /* Multiplex FunJet */

== Multiplex FunJet ==
{|
|-valign="top"
|[[Image:Funjet_flight_dawnron1.jpg|thumb|left|Multiplex FunJet]]
|
The [[FunJet|FunJet]] is a new electric pusher-prop model from Multiplex made of durable and CA safe Elapor foam. It offers plenty of room internally for avionics in an attractive package.

'''[[FunJet|More details...]]'''
|}

== Misc Airframe Notes ==

[http://www.motocalc.com MotoCalc] is an Electric Flight Performance Prediction program for Windows and is available for a 30 day free trial. MotoCalc has an internal database of thousands of motors/props/etc. and can make power/flight predictions based on data input.

[http://brantuas.com/ezcalc/dma1.asp Electric Motor Calculator] by Diversity Model Aircraft is a free online tool for matching props to motors to batteries.

[http://www.gobrushless.com/testing/thrust_calculator.php?prop=45&rb1=1&Value=9720&submit=Calculate+Now Propeller Thrust Calculator] is a free online calculator to give thrust from given propeller and RPM or vice versa.

=== Battery Specs ===

'''Nickel Cadmium (NiCd)'''

* Energy/Weight: 40-60 Wh/kg
* Nominal Cell Voltage: 1.2V
* Fully Charged Cell Voltage: 1.2V
* Depleted Cell Voltage: 0.8-1.0V

'''Nickel Metal Hydride (NiMh)'''

* Energy/Weight: 30-80 Wh/kg
* Nominal Cell Voltage: 1.2V
* Fully Charged Cell Voltage: 1.35-1.4 V (unloaded)
* Depleted Cell Voltage: 1.0V

'''Lithium-Ion'''

* Energy/weight: 160 Wh/kg
* Nominal Cell Voltage: 3.6 / 3.7 V
* Fully Charged Cell Voltage: 4.2V
* Lowest Cell Discharge Voltage Before Damage: 2.4v to 3.0v

'''Lithium-Ion Polymer (LiPo)'''

* Energy/weight: 130-200 Wh/kg
* Nominal Cell Voltage: 3.7V
* Fully Charged Cell Voltage: 4.23V
* Lowest Cell Discharge Voltage Before Damage: 3.0V

'''Typical Power Requirements'''

* 70W/kg (35W/lb) for sedate flying from hand launch
* 100W/kg (50W/lb) for ground take off
* 150W/kg (75W/lb) for performance / aerobatics

== Mass Figures ==

Provided below are some weights to aid in estimating an all up weight for your uav

* Tiny13 1.1 Weight: 25g (0.88oz)
* IR Sensor Head: 5g (0.18oz)
* XBee Pro: 4g (0.14oz)
* Hitec HS-55 Servo: 8g (0.28)
* Brushless Outrunner 250W: ~90g (~3oz)
* FunJet assembled, no hardware: 165g (5.82oz)
* FMA Encore 5ch Receiver: 11g (0.40oz)
* Castle Creations Phoenix 35: 24.5g (0.9oz)