http://wiki.paparazziuav.org/w/api.php?action=feedcontributions&feedformat=atom&user=AlexisldPaparazziUAV - User contributions [en]2026-04-08T19:32:34ZUser contributionsMediaWiki 1.37.1http://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=2822Airframe Configuration2007-11-05T00:07:43Z<p>Alexisld: /* R/C */</p>
<hr />
<div>The airframe configuration file is located in <b><tt>conf/airframes/</tt></b> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.<br />
<br />
== Selecting the Airframe File ==<br />
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:<br />
<?xml version="1.0"?><br />
<conf><br />
<aircraft <br />
name="Twin1"<br />
ac_id="1"<br />
airframe="airframes/twinstar1.xml" <br />
radio="radios/mc3030.xml" <br />
flight_plan="flight_plans/mav05_cw.xml"<br />
telemetry="telemetry/default.xml"<br />
gui_color="blue"<br />
/><br />
<aircraft <br />
name="Plaster"<br />
ac_id="2"<br />
airframe="airframes/plaster1.xml" <br />
radio="radios/cockpitMM.xml" <br />
telemetry="telemetry/default.xml"<br />
flight_plan="flight_plans/dummy.xml"<br />
/><br />
.<br />
.<br />
.<br />
</conf><br />
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply specify your airframe name in the flash command typed from the prompt:<br />
make AIRCRAFT=<b>Twin1</b> ap.upload<br />
More information can be found on the [[Conf.xml|conf.xml]] page<br />
<br />
== XML Parameters ==<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the servo commands you need to control the aircraft. In our example, we have only three:<br />
<tt><br />
<commands><br />
<axis name="THROTTLE" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="PITCH" failsafe_value="0"/><br />
</commands></tt><br />
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].<br />
<br />
=== Servos ===<br />
<br />
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:<br />
<tt><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos></tt><br />
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:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel<br />
* Any reduction of the total travel range should be done mechanically to maintain precision<br />
* 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.<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<tt><br />
<command_laws><br />
<let var="aileron" value="@ROLL * 0.3"/><br />
<let var="elevator" value="@PITCH * 0.7"/> <br />
<set servo="THROTTLE" value="@THROTTLE"/><br />
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/><br />
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/><br />
</command_laws></tt><br />
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]<br />
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.<br />
<br />
<br />
Note that the signs used in the description follow the standard convention. <br />
<br />
=== Auto1 ===<br />
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.<br />
<tt><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="RadOfDeg(35)"/><br />
<define name="MAX_PITCH" value="RadOfDeg(35)"/><br />
</section><br />
</tt><br />
<br><br />
<br />
=== ADC === <br />
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.<br />
<br><br />
<br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:<br />
<br />
<tt><br />
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/><br />
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/><br />
</tt><br />
<br />
Pitch and roll directions are defined here with the "-" sign on some of the 4 <b><tt>coeff</tt></b> values. Some trial and error is usually needed to get the directions correct.<br />
<br />
Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.<br />
<br><br />
<br />
=== Gyro === <br />
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>).<br />
<br />
<tt><br />
<section name="GYRO" prefix="GYRO_"<br />
<define name="ADC_ROLL_COEFF" value="1"/><br />
<define name="ROLL_NEUTRAL" value="500"/><br />
<define name="ADC_TEMP_NEUTRAL" value="476"/><br />
<define name="ADC_TEMP_SLOPE" value="0"/><br />
</section><br />
</tt><br />
<br />
<br />
=== Bat === <br />
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <b><tt>LOW_BATTERY</tt></b> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.<br />
<br />
<tt><br />
<section name="BAT"><br />
<define name="MILLIAMP_PER_PERCENT value "0.86"/><br />
<define name="VOLTAGE_ADC_A" value="0.0177531"/><br />
<define name="VOLTAGE_ADC_B" value="0.173626"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/><br />
<define name="LOW_BATTERY" value"9.3" unit="V"/><br />
</section><br />
</tt><br />
<br />
=== Horizontal Control ===<br />
<tt><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="-0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/><br />
<define name="ROLL_PGAIN" value="5000."/><br />
<define name="AILERON_OF_THROTTLE" value="0.0"/><br />
<define name="PITCH_PGAIN" value="-8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</tt><br />
<br />
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.<br />
<br />
=== Misc ===<br />
<tt><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s"><br />
<define name="CARROT" value="5." unit="s"/><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
<define name="CONTROL_RATE" value"60" unit="Hz"/><br />
</section><br />
</tt><br />
<br />
* The "NOMINAL_AIRSPEED" is mainly used in the simulator.<br />
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.<br />
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)<br />
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).<br />
<br />
== Hardware definitions - Makefile ==<br />
<br />
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:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<makefile><br />
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile<br />
<nowiki>FLASH_MODE=IAP</nowiki><br />
.<br />
.<br />
.<br />
</makefile><br />
}}<br />
Below this are the definintions and configuration of the peripherals and interfaces.<br />
<br />
=== R/C ===<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki><br />
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki><br />
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki><br />
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki><br />
}}<br />
<br />
You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.<br />
<br />
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. <br />
<br />
<tt>wiring on classix PWM connector<br />
connector LPC shared port <br />
PWM1 PWM5 AD1_6 CAP1_3 P0.21<br />
PWM2 PWM3 RXD0 EINT0 P0.1<br />
PWM3 PWM1 TXD0 P0.0<br />
PWM4 PWM6 RXD1 EINT3 P0.9<br />
PWM5 PWM4 TXD1 AD1_1 P0.8<br />
PWM6 PWM2 SSEL0 EINT2 P0.7</tt><br />
<br />
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 ).<br />
<br />
=== Modem ===<br />
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.<br />
<br />
Paparazzi supports the following modem protocols:<br />
* 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.<br />
* 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.<br />
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.<br />
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:<br />
==== Configuring The Serial Protocol ====<br />
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. 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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="DATALINK" prefix="DATALINK_"><br />
<define name="DEVICE_TYPE" value="PPRZ"/><br />
<define name="DEVICE_ADDRESS" value="...."/><br />
</section><br />
</nowiki><br />
}}<br />
The above example tells the autopilot to send and recieve data in standard serial form.<br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
# Serial modem <br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki><br />
}}<br />
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 />
<br><br />
Note:<br />
* The autopilot and modem serial port baud rates must match at all times, check your modem documentation to find the default baud rate and configure a different rate as needed.<br />
<br />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<!-- <arg flag="-transport" constant="xbee"/> Comment this line for standard serial protocol --><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
<br />
==== Configuring The Maxstream API Protocol ====<br />
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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="MISC"><br />
...<br />
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/><br />
<define name="NO_XBEE_API_INIT" value="FALSE"/><br />
...<br />
</section></nowiki><br />
}}<br />
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 <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, 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 />
<br><br />
Notes: <br />
* 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="<b>TRUE</b>"/> </tt>.<br />
* 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.<br />
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".<br />
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.<br />
<br />
<br style="clear:both><br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
<nowiki># Maxstream API protocol</nowiki><br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki><br />
}} <br />
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 />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<arg flag="-transport" constant="xbee"/><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
=== GPS ===<br />
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:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki><br />
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki><br />
}}<br />
'''Note:'''<br />
* 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]]<br />
<br />
=== Sensors ===<br />
<br />
=== Control loops ===<br />
<br />
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.<br />
<br />
First the horizontal loop:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.srcs += fw_h_ctl.c</nowiki><br />
}}<br />
<br />
== Radio Control ==<br />
The Paparazzi autpilot interfaces 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.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=2821Airframe Configuration2007-11-05T00:03:57Z<p>Alexisld: /* R/C */</p>
<hr />
<div>The airframe configuration file is located in <b><tt>conf/airframes/</tt></b> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.<br />
<br />
== Selecting the Airframe File ==<br />
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:<br />
<?xml version="1.0"?><br />
<conf><br />
<aircraft <br />
name="Twin1"<br />
ac_id="1"<br />
airframe="airframes/twinstar1.xml" <br />
radio="radios/mc3030.xml" <br />
flight_plan="flight_plans/mav05_cw.xml"<br />
telemetry="telemetry/default.xml"<br />
gui_color="blue"<br />
/><br />
<aircraft <br />
name="Plaster"<br />
ac_id="2"<br />
airframe="airframes/plaster1.xml" <br />
radio="radios/cockpitMM.xml" <br />
telemetry="telemetry/default.xml"<br />
flight_plan="flight_plans/dummy.xml"<br />
/><br />
.<br />
.<br />
.<br />
</conf><br />
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply specify your airframe name in the flash command typed from the prompt:<br />
make AIRCRAFT=<b>Twin1</b> ap.upload<br />
More information can be found on the [[Conf.xml|conf.xml]] page<br />
<br />
== XML Parameters ==<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the servo commands you need to control the aircraft. In our example, we have only three:<br />
<tt><br />
<commands><br />
<axis name="THROTTLE" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="PITCH" failsafe_value="0"/><br />
</commands></tt><br />
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].<br />
<br />
=== Servos ===<br />
<br />
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:<br />
<tt><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos></tt><br />
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:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel<br />
* Any reduction of the total travel range should be done mechanically to maintain precision<br />
* 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.<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<tt><br />
<command_laws><br />
<let var="aileron" value="@ROLL * 0.3"/><br />
<let var="elevator" value="@PITCH * 0.7"/> <br />
<set servo="THROTTLE" value="@THROTTLE"/><br />
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/><br />
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/><br />
</command_laws></tt><br />
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]<br />
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.<br />
<br />
<br />
Note that the signs used in the description follow the standard convention. <br />
<br />
=== Auto1 ===<br />
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.<br />
<tt><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="RadOfDeg(35)"/><br />
<define name="MAX_PITCH" value="RadOfDeg(35)"/><br />
</section><br />
</tt><br />
<br><br />
<br />
=== ADC === <br />
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.<br />
<br><br />
<br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:<br />
<br />
<tt><br />
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/><br />
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/><br />
</tt><br />
<br />
Pitch and roll directions are defined here with the "-" sign on some of the 4 <b><tt>coeff</tt></b> values. Some trial and error is usually needed to get the directions correct.<br />
<br />
Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.<br />
<br><br />
<br />
=== Gyro === <br />
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>).<br />
<br />
<tt><br />
<section name="GYRO" prefix="GYRO_"<br />
<define name="ADC_ROLL_COEFF" value="1"/><br />
<define name="ROLL_NEUTRAL" value="500"/><br />
<define name="ADC_TEMP_NEUTRAL" value="476"/><br />
<define name="ADC_TEMP_SLOPE" value="0"/><br />
</section><br />
</tt><br />
<br />
<br />
=== Bat === <br />
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <b><tt>LOW_BATTERY</tt></b> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.<br />
<br />
<tt><br />
<section name="BAT"><br />
<define name="MILLIAMP_PER_PERCENT value "0.86"/><br />
<define name="VOLTAGE_ADC_A" value="0.0177531"/><br />
<define name="VOLTAGE_ADC_B" value="0.173626"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/><br />
<define name="LOW_BATTERY" value"9.3" unit="V"/><br />
</section><br />
</tt><br />
<br />
=== Horizontal Control ===<br />
<tt><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="-0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/><br />
<define name="ROLL_PGAIN" value="5000."/><br />
<define name="AILERON_OF_THROTTLE" value="0.0"/><br />
<define name="PITCH_PGAIN" value="-8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</tt><br />
<br />
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.<br />
<br />
=== Misc ===<br />
<tt><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s"><br />
<define name="CARROT" value="5." unit="s"/><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
<define name="CONTROL_RATE" value"60" unit="Hz"/><br />
</section><br />
</tt><br />
<br />
* The "NOMINAL_AIRSPEED" is mainly used in the simulator.<br />
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.<br />
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)<br />
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).<br />
<br />
== Hardware definitions - Makefile ==<br />
<br />
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:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<makefile><br />
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile<br />
<nowiki>FLASH_MODE=IAP</nowiki><br />
.<br />
.<br />
.<br />
</makefile><br />
}}<br />
Below this are the definintions and configuration of the peripherals and interfaces.<br />
<br />
=== R/C ===<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki><br />
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki><br />
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki><br />
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki><br />
}}<br />
<br />
You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.<br />
<br />
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. <br />
<br />
<tt><br />
<nowiki>wiring on classix PWM connector</nowiki><br />
<nowiki>connector LPC shared port </nowiki><br />
PWM1 PWM5 AD1_6 CAP1_3 P0.21<br />
PWM2 PWM3 RXD0 EINT0 P0.1<br />
PWM3 PWM1 TXD0 P0.0<br />
PWM4 PWM6 RXD1 EINT3 P0.9<br />
PWM5 PWM4 TXD1 AD1_1 P0.8<br />
PWM6 PWM2 SSEL0 EINT2 P0.7<br />
</tt><br />
<br />
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 ).<br />
<br />
=== Modem ===<br />
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.<br />
<br />
Paparazzi supports the following modem protocols:<br />
* 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.<br />
* 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.<br />
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.<br />
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:<br />
==== Configuring The Serial Protocol ====<br />
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. 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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="DATALINK" prefix="DATALINK_"><br />
<define name="DEVICE_TYPE" value="PPRZ"/><br />
<define name="DEVICE_ADDRESS" value="...."/><br />
</section><br />
</nowiki><br />
}}<br />
The above example tells the autopilot to send and recieve data in standard serial form.<br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
# Serial modem <br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki><br />
}}<br />
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 />
<br><br />
Note:<br />
* The autopilot and modem serial port baud rates must match at all times, check your modem documentation to find the default baud rate and configure a different rate as needed.<br />
<br />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<!-- <arg flag="-transport" constant="xbee"/> Comment this line for standard serial protocol --><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
<br />
==== Configuring The Maxstream API Protocol ====<br />
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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="MISC"><br />
...<br />
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/><br />
<define name="NO_XBEE_API_INIT" value="FALSE"/><br />
...<br />
</section></nowiki><br />
}}<br />
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 <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, 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 />
<br><br />
Notes: <br />
* 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="<b>TRUE</b>"/> </tt>.<br />
* 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.<br />
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".<br />
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.<br />
<br />
<br style="clear:both><br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
<nowiki># Maxstream API protocol</nowiki><br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki><br />
}} <br />
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 />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<arg flag="-transport" constant="xbee"/><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
=== GPS ===<br />
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:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki><br />
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki><br />
}}<br />
'''Note:'''<br />
* 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]]<br />
<br />
=== Sensors ===<br />
<br />
=== Control loops ===<br />
<br />
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.<br />
<br />
First the horizontal loop:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.srcs += fw_h_ctl.c</nowiki><br />
}}<br />
<br />
== Radio Control ==<br />
The Paparazzi autpilot interfaces 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.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=2820Airframe Configuration2007-11-05T00:00:17Z<p>Alexisld: /* R/C */</p>
<hr />
<div>The airframe configuration file is located in <b><tt>conf/airframes/</tt></b> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.<br />
<br />
== Selecting the Airframe File ==<br />
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:<br />
<?xml version="1.0"?><br />
<conf><br />
<aircraft <br />
name="Twin1"<br />
ac_id="1"<br />
airframe="airframes/twinstar1.xml" <br />
radio="radios/mc3030.xml" <br />
flight_plan="flight_plans/mav05_cw.xml"<br />
telemetry="telemetry/default.xml"<br />
gui_color="blue"<br />
/><br />
<aircraft <br />
name="Plaster"<br />
ac_id="2"<br />
airframe="airframes/plaster1.xml" <br />
radio="radios/cockpitMM.xml" <br />
telemetry="telemetry/default.xml"<br />
flight_plan="flight_plans/dummy.xml"<br />
/><br />
.<br />
.<br />
.<br />
</conf><br />
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply specify your airframe name in the flash command typed from the prompt:<br />
make AIRCRAFT=<b>Twin1</b> ap.upload<br />
More information can be found on the [[Conf.xml|conf.xml]] page<br />
<br />
== XML Parameters ==<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the servo commands you need to control the aircraft. In our example, we have only three:<br />
<tt><br />
<commands><br />
<axis name="THROTTLE" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="PITCH" failsafe_value="0"/><br />
</commands></tt><br />
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].<br />
<br />
=== Servos ===<br />
<br />
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:<br />
<tt><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos></tt><br />
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:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel<br />
* Any reduction of the total travel range should be done mechanically to maintain precision<br />
* 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.<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<tt><br />
<command_laws><br />
<let var="aileron" value="@ROLL * 0.3"/><br />
<let var="elevator" value="@PITCH * 0.7"/> <br />
<set servo="THROTTLE" value="@THROTTLE"/><br />
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/><br />
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/><br />
</command_laws></tt><br />
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]<br />
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.<br />
<br />
<br />
Note that the signs used in the description follow the standard convention. <br />
<br />
=== Auto1 ===<br />
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.<br />
<tt><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="RadOfDeg(35)"/><br />
<define name="MAX_PITCH" value="RadOfDeg(35)"/><br />
</section><br />
</tt><br />
<br><br />
<br />
=== ADC === <br />
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.<br />
<br><br />
<br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:<br />
<br />
<tt><br />
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/><br />
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/><br />
</tt><br />
<br />
Pitch and roll directions are defined here with the "-" sign on some of the 4 <b><tt>coeff</tt></b> values. Some trial and error is usually needed to get the directions correct.<br />
<br />
Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.<br />
<br><br />
<br />
=== Gyro === <br />
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>).<br />
<br />
<tt><br />
<section name="GYRO" prefix="GYRO_"<br />
<define name="ADC_ROLL_COEFF" value="1"/><br />
<define name="ROLL_NEUTRAL" value="500"/><br />
<define name="ADC_TEMP_NEUTRAL" value="476"/><br />
<define name="ADC_TEMP_SLOPE" value="0"/><br />
</section><br />
</tt><br />
<br />
<br />
=== Bat === <br />
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <b><tt>LOW_BATTERY</tt></b> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.<br />
<br />
<tt><br />
<section name="BAT"><br />
<define name="MILLIAMP_PER_PERCENT value "0.86"/><br />
<define name="VOLTAGE_ADC_A" value="0.0177531"/><br />
<define name="VOLTAGE_ADC_B" value="0.173626"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/><br />
<define name="LOW_BATTERY" value"9.3" unit="V"/><br />
</section><br />
</tt><br />
<br />
=== Horizontal Control ===<br />
<tt><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="-0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/><br />
<define name="ROLL_PGAIN" value="5000."/><br />
<define name="AILERON_OF_THROTTLE" value="0.0"/><br />
<define name="PITCH_PGAIN" value="-8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</tt><br />
<br />
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.<br />
<br />
=== Misc ===<br />
<tt><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s"><br />
<define name="CARROT" value="5." unit="s"/><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
<define name="CONTROL_RATE" value"60" unit="Hz"/><br />
</section><br />
</tt><br />
<br />
* The "NOMINAL_AIRSPEED" is mainly used in the simulator.<br />
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.<br />
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)<br />
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).<br />
<br />
== Hardware definitions - Makefile ==<br />
<br />
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:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<makefile><br />
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile<br />
<nowiki>FLASH_MODE=IAP</nowiki><br />
.<br />
.<br />
.<br />
</makefile><br />
}}<br />
Below this are the definintions and configuration of the peripherals and interfaces.<br />
<br />
=== R/C ===<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki><br />
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki><br />
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki><br />
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki><br />
}}<br />
<br />
You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.<br />
<br />
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. <br />
<br />
{{Box Code|<br />
wiring on classix PWM connector<br />
connector LPC shared port<br />
PWM1 PWM5 AD1_6 CAP1_3 P0.21<br />
PWM2 PWM3 RXD0 EINT0 P0.1<br />
PWM3 PWM1 TXD0 P0.0<br />
PWM4 PWM6 RXD1 EINT3 P0.9<br />
PWM5 PWM4 TXD1 AD1_1 P0.8<br />
PWM6 PWM2 SSEL0 EINT2 P0.7<br />
}}<br />
<br />
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 ).<br />
<br />
=== Modem ===<br />
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.<br />
<br />
Paparazzi supports the following modem protocols:<br />
* 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.<br />
* 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.<br />
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.<br />
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:<br />
==== Configuring The Serial Protocol ====<br />
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. 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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="DATALINK" prefix="DATALINK_"><br />
<define name="DEVICE_TYPE" value="PPRZ"/><br />
<define name="DEVICE_ADDRESS" value="...."/><br />
</section><br />
</nowiki><br />
}}<br />
The above example tells the autopilot to send and recieve data in standard serial form.<br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
# Serial modem <br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki><br />
}}<br />
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 />
<br><br />
Note:<br />
* The autopilot and modem serial port baud rates must match at all times, check your modem documentation to find the default baud rate and configure a different rate as needed.<br />
<br />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<!-- <arg flag="-transport" constant="xbee"/> Comment this line for standard serial protocol --><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
<br />
==== Configuring The Maxstream API Protocol ====<br />
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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="MISC"><br />
...<br />
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/><br />
<define name="NO_XBEE_API_INIT" value="FALSE"/><br />
...<br />
</section></nowiki><br />
}}<br />
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 <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, 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 />
<br><br />
Notes: <br />
* 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="<b>TRUE</b>"/> </tt>.<br />
* 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.<br />
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".<br />
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.<br />
<br />
<br style="clear:both><br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
<nowiki># Maxstream API protocol</nowiki><br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki><br />
}} <br />
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 />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<arg flag="-transport" constant="xbee"/><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
=== GPS ===<br />
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:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki><br />
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki><br />
}}<br />
'''Note:'''<br />
* 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]]<br />
<br />
=== Sensors ===<br />
<br />
=== Control loops ===<br />
<br />
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.<br />
<br />
First the horizontal loop:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.srcs += fw_h_ctl.c</nowiki><br />
}}<br />
<br />
== Radio Control ==<br />
The Paparazzi autpilot interfaces 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.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=2819Airframe Configuration2007-11-05T00:00:04Z<p>Alexisld: /* R/C */</p>
<hr />
<div>The airframe configuration file is located in <b><tt>conf/airframes/</tt></b> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.<br />
<br />
== Selecting the Airframe File ==<br />
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:<br />
<?xml version="1.0"?><br />
<conf><br />
<aircraft <br />
name="Twin1"<br />
ac_id="1"<br />
airframe="airframes/twinstar1.xml" <br />
radio="radios/mc3030.xml" <br />
flight_plan="flight_plans/mav05_cw.xml"<br />
telemetry="telemetry/default.xml"<br />
gui_color="blue"<br />
/><br />
<aircraft <br />
name="Plaster"<br />
ac_id="2"<br />
airframe="airframes/plaster1.xml" <br />
radio="radios/cockpitMM.xml" <br />
telemetry="telemetry/default.xml"<br />
flight_plan="flight_plans/dummy.xml"<br />
/><br />
.<br />
.<br />
.<br />
</conf><br />
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply specify your airframe name in the flash command typed from the prompt:<br />
make AIRCRAFT=<b>Twin1</b> ap.upload<br />
More information can be found on the [[Conf.xml|conf.xml]] page<br />
<br />
== XML Parameters ==<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the servo commands you need to control the aircraft. In our example, we have only three:<br />
<tt><br />
<commands><br />
<axis name="THROTTLE" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="PITCH" failsafe_value="0"/><br />
</commands></tt><br />
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].<br />
<br />
=== Servos ===<br />
<br />
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:<br />
<tt><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos></tt><br />
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:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel<br />
* Any reduction of the total travel range should be done mechanically to maintain precision<br />
* 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.<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<tt><br />
<command_laws><br />
<let var="aileron" value="@ROLL * 0.3"/><br />
<let var="elevator" value="@PITCH * 0.7"/> <br />
<set servo="THROTTLE" value="@THROTTLE"/><br />
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/><br />
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/><br />
</command_laws></tt><br />
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]<br />
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.<br />
<br />
<br />
Note that the signs used in the description follow the standard convention. <br />
<br />
=== Auto1 ===<br />
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.<br />
<tt><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="RadOfDeg(35)"/><br />
<define name="MAX_PITCH" value="RadOfDeg(35)"/><br />
</section><br />
</tt><br />
<br><br />
<br />
=== ADC === <br />
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.<br />
<br><br />
<br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:<br />
<br />
<tt><br />
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/><br />
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/><br />
</tt><br />
<br />
Pitch and roll directions are defined here with the "-" sign on some of the 4 <b><tt>coeff</tt></b> values. Some trial and error is usually needed to get the directions correct.<br />
<br />
Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.<br />
<br><br />
<br />
=== Gyro === <br />
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>).<br />
<br />
<tt><br />
<section name="GYRO" prefix="GYRO_"<br />
<define name="ADC_ROLL_COEFF" value="1"/><br />
<define name="ROLL_NEUTRAL" value="500"/><br />
<define name="ADC_TEMP_NEUTRAL" value="476"/><br />
<define name="ADC_TEMP_SLOPE" value="0"/><br />
</section><br />
</tt><br />
<br />
<br />
=== Bat === <br />
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <b><tt>LOW_BATTERY</tt></b> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.<br />
<br />
<tt><br />
<section name="BAT"><br />
<define name="MILLIAMP_PER_PERCENT value "0.86"/><br />
<define name="VOLTAGE_ADC_A" value="0.0177531"/><br />
<define name="VOLTAGE_ADC_B" value="0.173626"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/><br />
<define name="LOW_BATTERY" value"9.3" unit="V"/><br />
</section><br />
</tt><br />
<br />
=== Horizontal Control ===<br />
<tt><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="-0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/><br />
<define name="ROLL_PGAIN" value="5000."/><br />
<define name="AILERON_OF_THROTTLE" value="0.0"/><br />
<define name="PITCH_PGAIN" value="-8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</tt><br />
<br />
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.<br />
<br />
=== Misc ===<br />
<tt><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s"><br />
<define name="CARROT" value="5." unit="s"/><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
<define name="CONTROL_RATE" value"60" unit="Hz"/><br />
</section><br />
</tt><br />
<br />
* The "NOMINAL_AIRSPEED" is mainly used in the simulator.<br />
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.<br />
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)<br />
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).<br />
<br />
== Hardware definitions - Makefile ==<br />
<br />
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:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<makefile><br />
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile<br />
<nowiki>FLASH_MODE=IAP</nowiki><br />
.<br />
.<br />
.<br />
</makefile><br />
}}<br />
Below this are the definintions and configuration of the peripherals and interfaces.<br />
<br />
=== R/C ===<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki><br />
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki><br />
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki><br />
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki><br />
}}<br />
<br />
You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.<br />
<br />
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. <br />
<br />
{{Box Code<br />
wiring on classix PWM connector<br />
connector LPC shared port<br />
PWM1 PWM5 AD1_6 CAP1_3 P0.21<br />
PWM2 PWM3 RXD0 EINT0 P0.1<br />
PWM3 PWM1 TXD0 P0.0<br />
PWM4 PWM6 RXD1 EINT3 P0.9<br />
PWM5 PWM4 TXD1 AD1_1 P0.8<br />
PWM6 PWM2 SSEL0 EINT2 P0.7<br />
}}<br />
<br />
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 ).<br />
<br />
=== Modem ===<br />
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.<br />
<br />
Paparazzi supports the following modem protocols:<br />
* 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.<br />
* 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.<br />
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.<br />
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:<br />
==== Configuring The Serial Protocol ====<br />
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. 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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="DATALINK" prefix="DATALINK_"><br />
<define name="DEVICE_TYPE" value="PPRZ"/><br />
<define name="DEVICE_ADDRESS" value="...."/><br />
</section><br />
</nowiki><br />
}}<br />
The above example tells the autopilot to send and recieve data in standard serial form.<br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
# Serial modem <br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki><br />
}}<br />
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 />
<br><br />
Note:<br />
* The autopilot and modem serial port baud rates must match at all times, check your modem documentation to find the default baud rate and configure a different rate as needed.<br />
<br />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<!-- <arg flag="-transport" constant="xbee"/> Comment this line for standard serial protocol --><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
<br />
==== Configuring The Maxstream API Protocol ====<br />
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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="MISC"><br />
...<br />
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/><br />
<define name="NO_XBEE_API_INIT" value="FALSE"/><br />
...<br />
</section></nowiki><br />
}}<br />
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 <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, 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 />
<br><br />
Notes: <br />
* 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="<b>TRUE</b>"/> </tt>.<br />
* 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.<br />
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".<br />
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.<br />
<br />
<br style="clear:both><br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
<nowiki># Maxstream API protocol</nowiki><br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki><br />
}} <br />
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 />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<arg flag="-transport" constant="xbee"/><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
=== GPS ===<br />
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:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki><br />
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki><br />
}}<br />
'''Note:'''<br />
* 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]]<br />
<br />
=== Sensors ===<br />
<br />
=== Control loops ===<br />
<br />
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.<br />
<br />
First the horizontal loop:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.srcs += fw_h_ctl.c</nowiki><br />
}}<br />
<br />
== Radio Control ==<br />
The Paparazzi autpilot interfaces 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.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=2818Airframe Configuration2007-11-04T23:58:58Z<p>Alexisld: /* R/C */</p>
<hr />
<div>The airframe configuration file is located in <b><tt>conf/airframes/</tt></b> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.<br />
<br />
== Selecting the Airframe File ==<br />
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:<br />
<?xml version="1.0"?><br />
<conf><br />
<aircraft <br />
name="Twin1"<br />
ac_id="1"<br />
airframe="airframes/twinstar1.xml" <br />
radio="radios/mc3030.xml" <br />
flight_plan="flight_plans/mav05_cw.xml"<br />
telemetry="telemetry/default.xml"<br />
gui_color="blue"<br />
/><br />
<aircraft <br />
name="Plaster"<br />
ac_id="2"<br />
airframe="airframes/plaster1.xml" <br />
radio="radios/cockpitMM.xml" <br />
telemetry="telemetry/default.xml"<br />
flight_plan="flight_plans/dummy.xml"<br />
/><br />
.<br />
.<br />
.<br />
</conf><br />
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply specify your airframe name in the flash command typed from the prompt:<br />
make AIRCRAFT=<b>Twin1</b> ap.upload<br />
More information can be found on the [[Conf.xml|conf.xml]] page<br />
<br />
== XML Parameters ==<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the servo commands you need to control the aircraft. In our example, we have only three:<br />
<tt><br />
<commands><br />
<axis name="THROTTLE" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="PITCH" failsafe_value="0"/><br />
</commands></tt><br />
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].<br />
<br />
=== Servos ===<br />
<br />
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:<br />
<tt><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos></tt><br />
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:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel<br />
* Any reduction of the total travel range should be done mechanically to maintain precision<br />
* 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.<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<tt><br />
<command_laws><br />
<let var="aileron" value="@ROLL * 0.3"/><br />
<let var="elevator" value="@PITCH * 0.7"/> <br />
<set servo="THROTTLE" value="@THROTTLE"/><br />
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/><br />
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/><br />
</command_laws></tt><br />
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]<br />
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.<br />
<br />
<br />
Note that the signs used in the description follow the standard convention. <br />
<br />
=== Auto1 ===<br />
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.<br />
<tt><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="RadOfDeg(35)"/><br />
<define name="MAX_PITCH" value="RadOfDeg(35)"/><br />
</section><br />
</tt><br />
<br><br />
<br />
=== ADC === <br />
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.<br />
<br><br />
<br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:<br />
<br />
<tt><br />
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/><br />
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/><br />
</tt><br />
<br />
Pitch and roll directions are defined here with the "-" sign on some of the 4 <b><tt>coeff</tt></b> values. Some trial and error is usually needed to get the directions correct.<br />
<br />
Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.<br />
<br><br />
<br />
=== Gyro === <br />
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>).<br />
<br />
<tt><br />
<section name="GYRO" prefix="GYRO_"<br />
<define name="ADC_ROLL_COEFF" value="1"/><br />
<define name="ROLL_NEUTRAL" value="500"/><br />
<define name="ADC_TEMP_NEUTRAL" value="476"/><br />
<define name="ADC_TEMP_SLOPE" value="0"/><br />
</section><br />
</tt><br />
<br />
<br />
=== Bat === <br />
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <b><tt>LOW_BATTERY</tt></b> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.<br />
<br />
<tt><br />
<section name="BAT"><br />
<define name="MILLIAMP_PER_PERCENT value "0.86"/><br />
<define name="VOLTAGE_ADC_A" value="0.0177531"/><br />
<define name="VOLTAGE_ADC_B" value="0.173626"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/><br />
<define name="LOW_BATTERY" value"9.3" unit="V"/><br />
</section><br />
</tt><br />
<br />
=== Horizontal Control ===<br />
<tt><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="-0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/><br />
<define name="ROLL_PGAIN" value="5000."/><br />
<define name="AILERON_OF_THROTTLE" value="0.0"/><br />
<define name="PITCH_PGAIN" value="-8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</tt><br />
<br />
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.<br />
<br />
=== Misc ===<br />
<tt><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s"><br />
<define name="CARROT" value="5." unit="s"/><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
<define name="CONTROL_RATE" value"60" unit="Hz"/><br />
</section><br />
</tt><br />
<br />
* The "NOMINAL_AIRSPEED" is mainly used in the simulator.<br />
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.<br />
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)<br />
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).<br />
<br />
== Hardware definitions - Makefile ==<br />
<br />
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:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<makefile><br />
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile<br />
<nowiki>FLASH_MODE=IAP</nowiki><br />
.<br />
.<br />
.<br />
</makefile><br />
}}<br />
Below this are the definintions and configuration of the peripherals and interfaces.<br />
<br />
=== R/C ===<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki><br />
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki><br />
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki><br />
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki><br />
}}<br />
<br />
You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.<br />
<br />
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. <br />
<br />
/*<br />
wiring on classix PWM connector<br />
connector LPC shared port<br />
PWM1 PWM5 AD1_6 CAP1_3 P0.21<br />
PWM2 PWM3 RXD0 EINT0 P0.1<br />
PWM3 PWM1 TXD0 P0.0<br />
PWM4 PWM6 RXD1 EINT3 P0.9<br />
PWM5 PWM4 TXD1 AD1_1 P0.8<br />
PWM6 PWM2 SSEL0 EINT2 P0.7<br />
<br />
*/<br />
<br />
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 ).<br />
<br />
=== Modem ===<br />
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.<br />
<br />
Paparazzi supports the following modem protocols:<br />
* 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.<br />
* 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.<br />
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.<br />
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:<br />
==== Configuring The Serial Protocol ====<br />
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. 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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="DATALINK" prefix="DATALINK_"><br />
<define name="DEVICE_TYPE" value="PPRZ"/><br />
<define name="DEVICE_ADDRESS" value="...."/><br />
</section><br />
</nowiki><br />
}}<br />
The above example tells the autopilot to send and recieve data in standard serial form.<br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
# Serial modem <br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki><br />
}}<br />
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 />
<br><br />
Note:<br />
* The autopilot and modem serial port baud rates must match at all times, check your modem documentation to find the default baud rate and configure a different rate as needed.<br />
<br />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<!-- <arg flag="-transport" constant="xbee"/> Comment this line for standard serial protocol --><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
<br />
==== Configuring The Maxstream API Protocol ====<br />
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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="MISC"><br />
...<br />
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/><br />
<define name="NO_XBEE_API_INIT" value="FALSE"/><br />
...<br />
</section></nowiki><br />
}}<br />
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 <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, 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 />
<br><br />
Notes: <br />
* 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="<b>TRUE</b>"/> </tt>.<br />
* 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.<br />
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".<br />
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.<br />
<br />
<br style="clear:both><br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
<nowiki># Maxstream API protocol</nowiki><br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki><br />
}} <br />
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 />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<arg flag="-transport" constant="xbee"/><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
=== GPS ===<br />
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:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki><br />
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki><br />
}}<br />
'''Note:'''<br />
* 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]]<br />
<br />
=== Sensors ===<br />
<br />
=== Control loops ===<br />
<br />
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.<br />
<br />
First the horizontal loop:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.srcs += fw_h_ctl.c</nowiki><br />
}}<br />
<br />
== Radio Control ==<br />
The Paparazzi autpilot interfaces 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.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=2817Airframe Configuration2007-11-04T23:56:57Z<p>Alexisld: /* R/C */</p>
<hr />
<div>The airframe configuration file is located in <b><tt>conf/airframes/</tt></b> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.<br />
<br />
== Selecting the Airframe File ==<br />
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:<br />
<?xml version="1.0"?><br />
<conf><br />
<aircraft <br />
name="Twin1"<br />
ac_id="1"<br />
airframe="airframes/twinstar1.xml" <br />
radio="radios/mc3030.xml" <br />
flight_plan="flight_plans/mav05_cw.xml"<br />
telemetry="telemetry/default.xml"<br />
gui_color="blue"<br />
/><br />
<aircraft <br />
name="Plaster"<br />
ac_id="2"<br />
airframe="airframes/plaster1.xml" <br />
radio="radios/cockpitMM.xml" <br />
telemetry="telemetry/default.xml"<br />
flight_plan="flight_plans/dummy.xml"<br />
/><br />
.<br />
.<br />
.<br />
</conf><br />
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply specify your airframe name in the flash command typed from the prompt:<br />
make AIRCRAFT=<b>Twin1</b> ap.upload<br />
More information can be found on the [[Conf.xml|conf.xml]] page<br />
<br />
== XML Parameters ==<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the servo commands you need to control the aircraft. In our example, we have only three:<br />
<tt><br />
<commands><br />
<axis name="THROTTLE" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="PITCH" failsafe_value="0"/><br />
</commands></tt><br />
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].<br />
<br />
=== Servos ===<br />
<br />
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:<br />
<tt><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos></tt><br />
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:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel<br />
* Any reduction of the total travel range should be done mechanically to maintain precision<br />
* 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.<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<tt><br />
<command_laws><br />
<let var="aileron" value="@ROLL * 0.3"/><br />
<let var="elevator" value="@PITCH * 0.7"/> <br />
<set servo="THROTTLE" value="@THROTTLE"/><br />
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/><br />
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/><br />
</command_laws></tt><br />
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]<br />
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.<br />
<br />
<br />
Note that the signs used in the description follow the standard convention. <br />
<br />
=== Auto1 ===<br />
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.<br />
<tt><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="RadOfDeg(35)"/><br />
<define name="MAX_PITCH" value="RadOfDeg(35)"/><br />
</section><br />
</tt><br />
<br><br />
<br />
=== ADC === <br />
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.<br />
<br><br />
<br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:<br />
<br />
<tt><br />
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/><br />
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/><br />
</tt><br />
<br />
Pitch and roll directions are defined here with the "-" sign on some of the 4 <b><tt>coeff</tt></b> values. Some trial and error is usually needed to get the directions correct.<br />
<br />
Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.<br />
<br><br />
<br />
=== Gyro === <br />
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>).<br />
<br />
<tt><br />
<section name="GYRO" prefix="GYRO_"<br />
<define name="ADC_ROLL_COEFF" value="1"/><br />
<define name="ROLL_NEUTRAL" value="500"/><br />
<define name="ADC_TEMP_NEUTRAL" value="476"/><br />
<define name="ADC_TEMP_SLOPE" value="0"/><br />
</section><br />
</tt><br />
<br />
<br />
=== Bat === <br />
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <b><tt>LOW_BATTERY</tt></b> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.<br />
<br />
<tt><br />
<section name="BAT"><br />
<define name="MILLIAMP_PER_PERCENT value "0.86"/><br />
<define name="VOLTAGE_ADC_A" value="0.0177531"/><br />
<define name="VOLTAGE_ADC_B" value="0.173626"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/><br />
<define name="LOW_BATTERY" value"9.3" unit="V"/><br />
</section><br />
</tt><br />
<br />
=== Horizontal Control ===<br />
<tt><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="-0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/><br />
<define name="ROLL_PGAIN" value="5000."/><br />
<define name="AILERON_OF_THROTTLE" value="0.0"/><br />
<define name="PITCH_PGAIN" value="-8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</tt><br />
<br />
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.<br />
<br />
=== Misc ===<br />
<tt><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s"><br />
<define name="CARROT" value="5." unit="s"/><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
<define name="CONTROL_RATE" value"60" unit="Hz"/><br />
</section><br />
</tt><br />
<br />
* The "NOMINAL_AIRSPEED" is mainly used in the simulator.<br />
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.<br />
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)<br />
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).<br />
<br />
== Hardware definitions - Makefile ==<br />
<br />
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:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<makefile><br />
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile<br />
<nowiki>FLASH_MODE=IAP</nowiki><br />
.<br />
.<br />
.<br />
</makefile><br />
}}<br />
Below this are the definintions and configuration of the peripherals and interfaces.<br />
<br />
=== R/C ===<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki><br />
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki><br />
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki><br />
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki><br />
}}<br />
<br />
You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.<br />
<br />
For the classix, you must specify which pins to use for PWM: <br />
<br />
/*<br />
wiring on classix PWM connector<br />
connector LPC shared port<br />
PWM1 PWM5 AD1_6 CAP1_3 P0.21<br />
PWM2 PWM3 RXD0 EINT0 P0.1<br />
PWM3 PWM1 TXD0 P0.0<br />
PWM4 PWM6 RXD1 EINT3 P0.9<br />
PWM5 PWM4 TXD1 AD1_1 P0.8<br />
PWM6 PWM2 SSEL0 EINT2 P0.7<br />
<br />
*/<br />
<br />
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 ). Then the makefile section should look like this in your airframe file: <br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
fbw.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\" -DPWM_SERVO_0 etc....<br />
fbw.srcs += $(SRC_ARCH)/servos_direct_hw.c<br />
}}<br />
<br />
=== Modem ===<br />
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.<br />
<br />
Paparazzi supports the following modem protocols:<br />
* 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.<br />
* 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.<br />
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.<br />
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:<br />
==== Configuring The Serial Protocol ====<br />
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. 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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="DATALINK" prefix="DATALINK_"><br />
<define name="DEVICE_TYPE" value="PPRZ"/><br />
<define name="DEVICE_ADDRESS" value="...."/><br />
</section><br />
</nowiki><br />
}}<br />
The above example tells the autopilot to send and recieve data in standard serial form.<br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
# Serial modem <br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki><br />
}}<br />
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 />
<br><br />
Note:<br />
* The autopilot and modem serial port baud rates must match at all times, check your modem documentation to find the default baud rate and configure a different rate as needed.<br />
<br />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<!-- <arg flag="-transport" constant="xbee"/> Comment this line for standard serial protocol --><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
<br />
==== Configuring The Maxstream API Protocol ====<br />
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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="MISC"><br />
...<br />
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/><br />
<define name="NO_XBEE_API_INIT" value="FALSE"/><br />
...<br />
</section></nowiki><br />
}}<br />
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 <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, 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 />
<br><br />
Notes: <br />
* 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="<b>TRUE</b>"/> </tt>.<br />
* 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.<br />
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".<br />
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.<br />
<br />
<br style="clear:both><br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
<nowiki># Maxstream API protocol</nowiki><br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki><br />
}} <br />
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 />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<arg flag="-transport" constant="xbee"/><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
=== GPS ===<br />
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:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki><br />
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki><br />
}}<br />
'''Note:'''<br />
* 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]]<br />
<br />
=== Sensors ===<br />
<br />
=== Control loops ===<br />
<br />
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.<br />
<br />
First the horizontal loop:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.srcs += fw_h_ctl.c</nowiki><br />
}}<br />
<br />
== Radio Control ==<br />
The Paparazzi autpilot interfaces 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.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Radio_Control&diff=2776Radio Control2007-10-14T22:54:14Z<p>Alexisld: </p>
<hr />
<div>This XML file, usually located in the <tt>conf/radios</tt> directory, contains a description of the radio control transmitter PPM signal. It should follow the grammar described in <tt>radio.dtd</tt> .<br />
<br />
The contents are an '''ordered''' sequence of elements describing each channel with its name and its range:<br />
<tt><!DOCTYPE radio SYSTEM "radio.dtd"><br />
<radio name="cockpitMM" data_min="900" data_max="2100" sync_min ="5000" sync_max ="15000"><br />
<channel ctl="D" function="ROLL" min="2000" neutral="1498" max="1000" average="0"/><br />
...<br />
<channel ctl="E" function="MODE" min="2000" neutral="1500" max="1000" average="1"/><br />
...<br />
</radio></tt><br />
The order of the channels must be the order of the pulses in the PPM signal.<br />
<br />
Among the top attributes, we find<br />
* <tt>name</tt>: used only in debug traces.<br />
* <tt>data_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) used to code one channel of the PPM signal.<br />
* <tt>sync_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) between two impulses set of the PPM signal.<br />
<br />
Each channel is described with its transmitter name (<tt>ctl</tt>), its <tt>function</tt> name, its range in microseconds and its neutral value in microseconds.<br />
These values are used by the autopilot to compute a normalized input from the PPM signal (this file is preprocessed and the produced code is included in the airborne code). Note that the <tt>min</tt> and <tt>max</tt> attributes can be exchanged to reverse the direction of the command.<br />
<br />
The <tt>average</tt> attribute must be set to '''1''' for ''discrete'' channels for which a trivial averaging filter will be applied. The neutral of a discrete channel need to be halfway through the min and max values. Otherwise it won't be mapped properly by the filter. <br />
<br />
Wrong attributes of the "radio" element will prevent the decoder to recognize any PPM frame; same for a wrong number or channels. <br />
<br />
== Measuring the PPM time values ==<br />
<br />
[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|R/C receiver timing diagram]]<br />
There are two common ways to measure the time characteristics of the PPM signal:<br />
# Using an oscilloscope: easy to achieve with a high level digital scope with capture and measure facilities.<br />
# Using the telemetry of the autopilot: the '''PPM''' message (defined in <tt>conf/messages.xml</tt>) contains the sequence of a (recently) received PPM signal. Two important notes:<br />
#: With the default telemetry configuration file (<tt>conf/telemetry/default.xml</tt>), this message is '''not''' sent in the '''default''' mode (numbered 0). This mode can be changed to '''debug''' (numbered 1) in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant: <tt><define name="TELEMETRY_MODE_FBW" value="1"/></tt><br />
#: The time unit used in this '''PPM''' message is hardware dependent:<br />
#:* On the obsolete AVR hardware, 1 microsecond = 16 units (because the crystal is running at 16MHz)<br />
#:* on the LPC hardware, 1 microsecond = 15 units (because the cristal is running at 12MHz)<br />
#:*:(<tt>conf/autopilot/tiny.h</tt>), the CPU clock is 5 times more, the peripheral bus is 4 times less, and the timer is not prescaled (<tt>sw/airborne/arm7/sys_time_hw.h</tt>) !!!)</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=2775Airframe Configuration2007-10-14T21:32:25Z<p>Alexisld: /* R/C */</p>
<hr />
<div>The airframe configuration file is located in <b><tt>conf/airframes/</tt></b> and contains all the hardware and software settings for a particular aircraft. This is a hybrid file containing [http://en.wikipedia.org/wiki/Xml xml] in the first half with [http://en.wikipedia.org/wiki/Makefile C Makefile] code at the bottom. All gains, trims, and behavior settings are in the top XML section and the hardware definitions such as processor type, modem protocol, servo driver, etc. are contained in the makefile.<br />
<br />
== Selecting the Airframe File ==<br />
Each airframe file must be assigned a name, unique ID, flight plan, etc. in [[Conf.xml|<tt>conf/conf.xml</tt>]] as follows:<br />
<?xml version="1.0"?><br />
<conf><br />
<aircraft <br />
name="Twin1"<br />
ac_id="1"<br />
airframe="airframes/twinstar1.xml" <br />
radio="radios/mc3030.xml" <br />
flight_plan="flight_plans/mav05_cw.xml"<br />
telemetry="telemetry/default.xml"<br />
gui_color="blue"<br />
/><br />
<aircraft <br />
name="Plaster"<br />
ac_id="2"<br />
airframe="airframes/plaster1.xml" <br />
radio="radios/cockpitMM.xml" <br />
telemetry="telemetry/default.xml"<br />
flight_plan="flight_plans/dummy.xml"<br />
/><br />
.<br />
.<br />
.<br />
</conf><br />
Then, to compile and flash the airframe settings and associated flight plan to your autopilot, simply specify your airframe name in the flash command typed from the prompt:<br />
make AIRCRAFT=<b>Twin1</b> ap.upload<br />
More information can be found on the [[Conf.xml|conf.xml]] page<br />
<br />
== XML Parameters ==<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the servo commands you need to control the aircraft. In our example, we have only three:<br />
<tt><br />
<commands><br />
<axis name="THROTTLE" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="PITCH" failsafe_value="0"/><br />
</commands></tt><br />
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].<br />
<br />
=== Servos ===<br />
<br />
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:<br />
<tt><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="AILEVON_LEFT" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="AILEVON_RIGHT" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos></tt><br />
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:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymetrical travel<br />
* Any reduction of the total travel range should be done mechanically to maintain precision<br />
* 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.<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<tt><br />
<command_laws><br />
<let var="aileron" value="@ROLL * 0.3"/><br />
<let var="elevator" value="@PITCH * 0.7"/> <br />
<set servo="THROTTLE" value="@THROTTLE"/><br />
<set servo="AILEVON_LEFT" value="$elevator + $aileron"/><br />
<set servo="AILEVON_RIGHT" value="$elevator - $aileron"/><br />
</command_laws></tt><br />
[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]<br />
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.<br />
<br />
<br />
Note that the signs used in the description follow the standard convention. <br />
<br />
=== Auto1 ===<br />
The next section, named <b><tt>AUTO1</tt></b>, gives the maximum roll and pitch (in radians) allowed for the augmented stability mode.<br />
<tt><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="RadOfDeg(35)"/><br />
<define name="MAX_PITCH" value="RadOfDeg(35)"/><br />
</section><br />
</tt><br />
<br><br />
<br />
=== ADC === <br />
In the "adc" section, you will find the correspondance between arguments and their assigned pins on the autopilot board.<br />
<br><br />
<br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. It is necessary to calibrate them in order to obtain the neutral values. As the X-Y sensor pairs are usually installed with a 45 degree rotation, combining roll and pitch we have a formula to separate roll from pitch and adjust the output accordingly:<br />
<br />
<tt><br />
<linear name="RollOfIrs" arity="2" coeff1="-0.7" coeff2="0.7"/><br />
<linear name="PitchOfIrs" arity="2" coeff1="-0.7" coeff2="-0.7"/><br />
</tt><br />
<br />
Pitch and roll directions are defined here with the "-" sign on some of the 4 <b><tt>coeff</tt></b> values. Some trial and error is usually needed to get the directions correct.<br />
<br />
Note that the roll angle is positive when the right wing low while pitch is positive when the nose is up.<br />
<br><br />
<br />
=== Gyro === <br />
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>).<br />
<br />
<tt><br />
<section name="GYRO" prefix="GYRO_"<br />
<define name="ADC_ROLL_COEFF" value="1"/><br />
<define name="ROLL_NEUTRAL" value="500"/><br />
<define name="ADC_TEMP_NEUTRAL" value="476"/><br />
<define name="ADC_TEMP_SLOPE" value="0"/><br />
</section><br />
</tt><br />
<br />
<br />
=== Bat === <br />
This section for the monitoring the main power battery. The allowed voltage range for this aircraft is 9-12.5V. <b><tt>MILLIAMP_PER_PERCENT</tt></b> represents the consumption (in mA) for one percent of THROTTLE and for one time unit. The <b><tt>LOW_BATTERY</tt></b> value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode.<br />
<br />
<tt><br />
<section name="BAT"><br />
<define name="MILLIAMP_PER_PERCENT value "0.86"/><br />
<define name="VOLTAGE_ADC_A" value="0.0177531"/><br />
<define name="VOLTAGE_ADC_B" value="0.173626"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/><br />
<define name="LOW_BATTERY" value"9.3" unit="V"/><br />
</section><br />
</tt><br />
<br />
=== Horizontal Control ===<br />
<tt><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="-0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="0.35" unit="radians"/><br />
<define name="ROLL_PGAIN" value="5000."/><br />
<define name="AILERON_OF_THROTTLE" value="0.0"/><br />
<define name="PITCH_PGAIN" value="-8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</tt><br />
<br />
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.<br />
<br />
=== Misc ===<br />
<tt><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12." unit="m/s"><br />
<define name="CARROT" value="5." unit="s"/><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
<define name="CONTROL_RATE" value"60" unit="Hz"/><br />
</section><br />
</tt><br />
<br />
* The "NOMINAL_AIRSPEED" is mainly used in the simulator.<br />
* "CARROT" gives the distance (in seconds, so ground speed is taken into account) between the carrot and the aircraft.<br />
* "KILL_MODE_DISTANCE" is the threshold distance to switch the autopilot into KILL mode (defined descent with no throttle)<br />
* "CONTROL_RATE" is the rate of the low level control loops in Hertz (60 or 20).<br />
<br />
== Hardware definitions - Makefile ==<br />
<br />
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:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<makefile><br />
include $(PAPARAZZI_SRC)/conf/autopilot/tiny.makefile<br />
<nowiki>FLASH_MODE=IAP</nowiki><br />
.<br />
.<br />
.<br />
</makefile><br />
}}<br />
Below this are the definintions and configuration of the peripherals and interfaces.<br />
<br />
=== R/C ===<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DRADIO_CONTROL -DRADIO_CONTROL_TYPE=RC_FUTABA</nowiki><br />
<nowiki>ap.EXTRA_SRCS += radio_control.c $(SRC_ARCH)/ppm_hw.c</nowiki><br />
<nowiki>ap.CFLAGS += -DACTUATORS=\"servos_direct_hw.h\"</nowiki><br />
<nowiki>ap.EXTRA_SRCS += $(SRC_ARCH)/servos_direct_hw.c</nowiki><br />
}}<br />
<br />
You can set RADIO_CONTROL_TYPE to RC_FUTABA, for falling edge PPM, or RC_JR for rising edge PPM.<br />
<br />
=== Modem ===<br />
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.<br />
<br />
Paparazzi supports the following modem protocols:<br />
* 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.<br />
* 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.<br />
* Coronis Wavecard - necessary for operation with the unusual Coronis Wavecard modem.<br />
Select the baud/protocol in the airframe file by commenting/uncommenting the appropriate section as follows:<br />
==== Configuring The Serial Protocol ====<br />
Users are advised to start with the standard serial protocol before attempting to setup an addressed API link. 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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="DATALINK" prefix="DATALINK_"><br />
<define name="DEVICE_TYPE" value="PPRZ"/><br />
<define name="DEVICE_ADDRESS" value="...."/><br />
</section><br />
</nowiki><br />
}}<br />
The above example tells the autopilot to send and recieve data in standard serial form.<br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
# Serial modem <br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c pprz_transport.c</nowiki><br />
}}<br />
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 />
<br><br />
Note:<br />
* The autopilot and modem serial port baud rates must match at all times, check your modem documentation to find the default baud rate and configure a different rate as needed.<br />
<br />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<!-- <arg flag="-transport" constant="xbee"/> Comment this line for standard serial protocol --><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
<br />
==== Configuring The Maxstream API Protocol ====<br />
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.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki><br />
<section name="MISC"><br />
...<br />
<define name="XBEE_INIT" value="\"ATPL2\rATRN1\rATTT80\r\ATBD6\rATWR\r\""/><br />
<define name="NO_XBEE_API_INIT" value="FALSE"/><br />
...<br />
</section></nowiki><br />
}}<br />
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 <tt><define name="NO_XBEE_API_INIT" value="<b>TRUE</b>"/></tt>, 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 />
<br><br />
Notes: <br />
* 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="<b>TRUE</b>"/> </tt>.<br />
* 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.<br />
* For temporary boot-time API configuration remove any baud rate changes, remove <tt>ATWR\r</tt> from the end of the string and keep "NO_XBEE_API_INIT" value="FALSE".<br />
* Upgrade your Maxstream firmware to the latest version before attempting API mode operation.<br />
<br />
<br style="clear:both><br />
<br />
{{Box Code|conf/airframes/myplane.xml - makefile section at the bottom|<br />
<nowiki># Maxstream API protocol</nowiki><br />
<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><br />
<nowiki>ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c datalink.c xbee.c</nowiki><br />
}} <br />
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 />
<br style="clear:both><br />
<br />
Ensure that the ground station is using the same protocol and an equal or higher baud rate:<br />
{{Box Code|conf/control_panel.xml|<br />
<nowiki><br />
<session name="USB"><br />
<program name="link"><br />
<arg flag="-d" constant="/dev/paparazzi/ttyUSB0"/><br />
<arg flag="-transport" constant="xbee"/><br />
<arg flag="-uplink" constant=""/><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
...<br />
</session><br />
</nowiki><br />
}}<br />
<br />
=== GPS ===<br />
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:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.CFLAGS += -DGPS -DUBX -DUSE_UART1 -DGPS_LINK=Uart1 -DUART1_BAUD=B38400</nowiki><br />
<nowiki>ap.srcs += gps_ubx.c gps.c</nowiki><br />
}}<br />
'''Note:'''<br />
* 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]]<br />
<br />
=== Sensors ===<br />
<br />
=== Control loops ===<br />
<br />
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.<br />
<br />
First the horizontal loop:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<nowiki>ap.srcs += fw_h_ctl.c</nowiki><br />
}}<br />
<br />
== Radio Control ==<br />
The Paparazzi autpilot interfaces 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.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2774Classix2007-10-14T21:30:06Z<p>Alexisld: /* Pinout */</p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
# Note that FOO2 is used for PPM_in ...<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
<br />
* check the polarity of all parts, compare to a picture of a working reference board<br />
* use a microscope or a magnifying glass to check for short circuits<br />
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 5V<br />
* the 5V should not drop due to current limiting, measure the 3.7V and the 3.3V supply on the board<br />
-> wrong voltages: check the parts around the power supply<br />
* measure the current, it should be around 40mA at 5V with the LPC running and no code loaded <br />
* attach one reset to GND, current should reduce to 30mA at 5V<br />
-> check if reset signal can be measured at the LPC reset pin 57<br />
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)<br />
* connect TXD and RXD of either AP_Serial or FBW_Serial 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 ground or connect to a pushbutton and reset the board<br />
* run the serial ROM loader lpc21isp to flash USB bootloader with<br />
make upload_bl PROC=GENERIC<br />
-> check the rx/tx pins for data if flashing does not succeed<br />
* deattach the LPC_P0.14, reset the board, current should be around 160 mA @ 5V when both AP and FWB are programmed<br />
* the USB bootloader outputs debug information with 115200 8N1 on the serial port<br />
picocom -b 115200 /dev/ttyUSB0<br />
* connect USB+ (D+), USB- (D-), and GND of AP or FBW with your PC, reset the board. Note that there is no connection to P0.23 on the Classix v0.99 and thus you will get a "Broken Pipe" error at the end of the programming. Furthermore, if you don't always connect it to ground, the code won't always start after a reset! <br />
* 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<br />
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-<br />
* flash the autopilot with<br />
make AIRCRAFT=myplane clean_ac ap.upload<br />
(where myplane is the name of your airframe as defined in conf/conf.xml... Try with AIRCRAFT=TJ1 if you don't know what to use)<br />
* check telemetry through serial port, messages should be displayed<br />
* test A/D converters for supply voltage and IR sensors<br />
* check modem, connect tx, rx, gnd and supply<br />
* try to aquire sats outside<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
* No connection to P0.23... result in random behavior of the USB Bootloader and a "Broken Pipe" error message when programming, even if the programming is successfull! <br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed. The last one is clearly a bug!!</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Radio_Control&diff=2757Radio Control2007-10-12T22:35:39Z<p>Alexisld: </p>
<hr />
<div>This XML file, usually located in the <tt>conf/radios</tt> directory, contains a description of the radio control transmitter PPM signal. It should follow the grammar described in <tt>radio.dtd</tt> .<br />
<br />
The contents are an '''ordered''' sequence of elements describing each channel with its name and its range:<br />
<tt><!DOCTYPE radio SYSTEM "radio.dtd"><br />
<radio name="cockpitMM" data_min="900" data_max="2100" sync_min ="5000" sync_max ="15000"><br />
<channel ctl="D" function="ROLL" min="2000" neutral="1498" max="1000" average="0"/><br />
...<br />
<channel ctl="E" function="MODE" min="2000" neutral="1500" max="1000" average="1"/><br />
...<br />
</radio></tt><br />
The order of the channels must be the order of the pulses in the PPM signal.<br />
<br />
Among the top attributes, we find<br />
* <tt>name</tt>: used only in debug traces.<br />
* <tt>data_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) used to code one channel of the PPM signal.<br />
* <tt>sync_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) between two impulses set of the PPM signal.<br />
<br />
Each channel is described with its transmitter name (<tt>ctl</tt>), its <tt>function</tt> name, its range in microseconds and its neutral value in microseconds.<br />
These values are used by the autopilot to compute a normalized input from the PPM signal (this file is preprocessed and the produced code is included in the airborne code). Note that the <tt>min</tt> and <tt>max</tt> attributes can be exchanged to reverse the direction of the command.<br />
<br />
The <tt>average</tt> attribute must be set to '''1''' for ''discrete'' channels for which a trivial averaging filter will be applied.<br />
<br />
Wrong attributes of the "radio" element will prevent the decoder to recognize any PPM frame; same for a wrong number or channels. <br />
<br />
== Measuring the PPM time values ==<br />
<br />
[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|R/C receiver timing diagram]]<br />
There are two common ways to measure the time characteristics of the PPM signal:<br />
# Using an oscilloscope: easy to achieve with a high level digital scope with capture and measure facilities.<br />
# Using the telemetry of the autopilot: the '''PPM''' message (defined in <tt>conf/messages.xml</tt>) contains the sequence of a (recently) received PPM signal. Two important notes:<br />
#: With the default telemetry configuration file (<tt>conf/telemetry/default.xml</tt>), this message is '''not''' sent in the '''default''' mode (numbered 0). This mode can be changed to '''debug''' (numbered 1) in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant: <tt><define name="TELEMETRY_MODE_FBW" value="1"/></tt><br />
#: The time unit used in this '''PPM''' message is hardware dependent:<br />
#:* On the obsolete AVR hardware, 1 microsecond = 16 units (because the crystal is running at 16MHz)<br />
#:* on the LPC hardware, 1 microsecond = 15 units (because the cristal is running at 12MHz)<br />
#:*:(<tt>conf/autopilot/tiny.h</tt>), the CPU clock is 5 times more, the peripheral bus is 4 times less, and the timer is not prescaled (<tt>sw/airborne/arm7/sys_time_hw.h</tt>) !!!)</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2674Classix2007-09-18T17:50:38Z<p>Alexisld: /* Assembly */</p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
<br />
* check the polarity of all parts, compare to a picture of a working reference board<br />
* use a microscope or a magnifying glass to check for short circuits<br />
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 5V<br />
* the 5V should not drop due to current limiting, measure the 3.7V and the 3.3V supply on the board<br />
-> wrong voltages: check the parts around the power supply<br />
* measure the current, it should be around 40mA at 5V with the LPC running and no code loaded <br />
* attach one reset to GND, current should reduce to 30mA at 5V<br />
-> check if reset signal can be measured at the LPC reset pin 57<br />
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)<br />
* connect TXD and RXD of either AP_Serial or FBW_Serial 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 ground or connect to a pushbutton and reset the board<br />
* run the serial ROM loader lpc21isp to flash USB bootloader with<br />
make upload_bl PROC=GENERIC<br />
-> check the rx/tx pins for data if flashing does not succeed<br />
* deattach the LPC_P0.14, reset the board, current should be around 160 mA @ 5V when both AP and FWB are programmed<br />
* the USB bootloader outputs debug information with 115200 8N1 on the serial port<br />
picocom -b 115200 /dev/ttyUSB0<br />
* connect USB+ (D+), USB- (D-), and GND of AP or FBW with your PC, reset the board. Note that there is no connection to P0.23 on the Classix v0.99 and thus you will get a "Broken Pipe" error at the end of the programming. Furthermore, if you don't always connect it to ground, the code won't always start after a reset! <br />
* 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<br />
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-<br />
* flash the autopilot with<br />
make AIRCRAFT=myplane clean_ac ap.upload<br />
(where myplane is the name of your airframe as defined in conf/conf.xml... Try with AIRCRAFT=TJ1 if you don't know what to use)<br />
* check telemetry through serial port, messages should be displayed<br />
* test A/D converters for supply voltage and IR sensors<br />
* check modem, connect tx, rx, gnd and supply<br />
* try to aquire sats outside<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
* No connection to P0.23... result in random behavior of the USB Bootloader and a "Broken Pipe" error message when programming, even if the programming is successfull! <br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed. The last one is clearly a bug!!</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2673Classix2007-09-18T17:48:24Z<p>Alexisld: /* TODO */</p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
<br />
* check the polarity of all parts, compare to a picture of a working reference board<br />
* use a microscope or a magnifying glass to check for short circuits<br />
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 5V<br />
* the 5V should not drop due to current limiting, measure the 3.7V and the 3.3V supply on the board<br />
-> wrong voltages: check the parts around the power supply<br />
* measure the current, it should be around 40mA at 5V with the LPC running and no code loaded <br />
* attach one reset to GND, current should reduce to 30mA at 5V<br />
-> check if reset signal can be measured at the LPC reset pin 57<br />
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)<br />
* connect TXD and RXD of either AP_Serial or FBW_Serial 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 ground or connect to a pushbutton and reset the board<br />
* run the serial ROM loader lpc21isp to flash USB bootloader with<br />
make upload_bl PROC=GENERIC<br />
-> check the rx/tx pins for data if flashing does not succeed<br />
* deattach the LPC_P0.14, reset the board, current should be around 160 mA @ 5V when both AP and FWB are programmed<br />
* the USB bootloader outputs debug information with 115200 8N1 on the serial port<br />
picocom -b 115200 /dev/ttyUSB0<br />
* connect USB+ (D+), USB- (D-), and GND of AP or FBW with your PC, reset the board<br />
* 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<br />
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-<br />
* flash the autopilot with<br />
make AIRCRAFT=myplane clean_ac ap.upload<br />
(where myplane is the name of your airframe as defined in conf/conf.xml... Try with AIRCRAFT=TJ1 if you don't know what to use)<br />
* check telemetry through serial port, messages should be displayed<br />
* test A/D converters for supply voltage and IR sensors<br />
* check modem, connect tx, rx, gnd and supply<br />
* try to aquire sats outside<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
* No connection to P0.23... result in random behavior of the USB Bootloader and a "Broken Pipe" error message when programming, even if the programming is successfull! <br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed. The last one is clearly a bug!!</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Installation/Linux&diff=2645Installation/Linux2007-09-04T18:15:02Z<p>Alexisld: /* Extra for Ubuntu 7.04 */</p>
<hr />
<div>Precompiled binaries can be downloaded and executed with the ''paparazzi-bin'' package but to maintain the power and flexibility of open-source code, most operations within Paparazzi involve recompilation of autopilot and/or ground station code. Therefore the typical installation requires all of the necessary C, OCAML, and Perl compilers as well as some XML and Ivy handlers.<br />
<br />
== Setting your Environment Variables ==<br />
Before launching the GCS or compiling anything you must have the Paparazzi source and home environment variables set correctly in your shell. These variables can be automatically set in your shell by adding the following lines to your .bashrc file:<br />
{{Box Code|/home/your_username/.bashrc|<br />
export PAPARAZZI_HOME<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
export PAPARAZZI_SRC<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
}}<br />
If you wish to manually set the env variables (i.e. when compiling a backup copy of your code in a different folder) execute the following command from the folder you wish to set as your active paparazzi folder:<br />
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`<br />
Verify that your variables are set correctly with the following command:<br />
env | grep PAPARAZZI<br />
which should return the following:<br />
PAPARAZZI_HOME<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
PAPARAZZI_SRC<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
<br />
== Installation on Debian ==<br />
<br />
Paparazzi is packaged for Debian as well as all of its dependencies. The [http://www.recherche.enac.fr/paparazzi/debian repository] hosted at ENAC holds their latest version.<br />
<br />
=== Installation from the Command Line===<br />
Just add the following line(s) to your repository list (<b>/etc/apt/sources.list</b>). Note: etch users must include ''both'' sarge and etch lines.<br />
{{Box Code|/etc/apt/sources.list|<br />
deb <nowiki>http://www.recherche.enac.fr/paparazzi/debian</nowiki> sarge main<br />
#if needed deb <nowiki>http://www.recherche.enac.fr/paparazzi/debian etch main</nowiki><br />
}}<br />
Then, update your sources and install the precompiled binaries as well as the dependencies needed for recompiling:<br />
apt-get update<br />
apt-get install paparazzi-bin<br />
apt-get install paparazzi-base<br />
apt-get install paparazzi-dev<br />
apt-get install paparazzi-arm7<br />
<br />
=== Installation thru Synaptic Package Manager ===<br />
* Launch ''Synaptic Package Manager'' (''Applications/System'' Tools Menu)<br />
* In '''Settings/Repositories''', add a new repository on URI = '''<nowiki>http://www.recherche.enac.fr/paparazzi/debian</nowiki>''', Distribution = '''sarge''', Section = '''main'''<br />
* Users of current linux versions must also add '''<nowiki>http://www.recherche.enac.fr/paparazzi/debian</nowiki>''', Distribution = '''etch''', Section = '''main''' (both Sarge and Etch are needed)<br />
* Search for paparazzi-bin, paparazzi-base, paparazzi-dev, and paparazzi-arm7 packages (use the ''Search'' button)<br />
* Mark them for installation (right-click on package names)<br />
* Left-click on ''Apply''<br />
<br />
=== Optional/Obsolete Packages ===<br />
Users of older AVR based boards will also need the paparazzi-avr package.<br />
<br />
=== Installing the Source Code ===<br />
After the dependency packages are installed the complete source code should be downloaded from the CVS. See the [http://savannah.nongnu.org/cvs/?group=paparazzi project page] at Savannah for more details. From /home/''your_username''/ type:<br />
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/paparazzi co paparazzi3<br />
This will download all of the code and install it into /home/''your_username''/paparazzi3/<br />
<br />
If you cannot use the CVS install, occasionally updated tarballs can also be fetched from the [[Downloads|Downloads]] page.<br />
<br />
=== Extra for Ubuntu 7.04 ===<br />
<br />
The Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:<br />
<br />
sudo apt-get remove brltty<br />
<br />
You need permission to access the "raw" USB bus. You should be member of the dialout group and tell the system to allow access by copying the file "10-paparazzi.rules" as root from $PAPARAZZI_HOME/conf/system/udev/rules/ to /etc/udev/rules.d and adding the line <br />
<br />
BUS=="usb", SYSFS{idVendor}=="7070", GROUP="dialout"<br />
<br />
== Launching the Software ==<br />
Make sure your [[Installation#Setting_your_Environment_Variables|environment variables]] are set correctly and launch the software from /home/''your_username''/paparazzi3/ with:<br />
<br />
./paparazzi<br />
<br />
== Recompiling ==<br />
After any CVS update or source code modification the code can be recompiled from /home/''your_username''/paparazzi3/ with the following command:<br />
<br />
make<br />
<br />
The ''make'' command will only recompile portions of the software where changed have been detected. If it does not behave as expected you can deleted all compiled files and recompile from scratch with the following commands:<br />
<br />
make clean<br />
make<br />
<br />
See the [[Compiling]] page for more info.<br />
<br />
== Manual Installation of Individual Packages ==<br />
Users of Ubuntu or other Linux flavors or anyone needing manual control of each individual package can install them independently. The list of dependencies of the Debian package is located in the <tt>debian/control</tt> file and may help users of other distributions.<br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/sarge/main/binary-i386/libsubject-perl_2.00_all.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/xml-light-ocaml_2.1-2_i386.deb</nowiki><br />
wget <nowiki>http://www.tls.cena.fr/products/ivy/download/packages/ivy-perl_4.21_all.deb</nowiki><br />
wget <nowiki>http://www.tls.cena.fr/products/ivy/download/packages/ivy-c_3.9.2-1_i386.deb</nowiki><br />
wget <nowiki>http://www.tls.cena.fr/products/ivy/download/packages/ivy-c-dev_3.9.2-1_i386.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/ivy-ocaml_1.1-2_i386.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/paparazzi-base_3.1-2_i386.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/paparazzi-bin_3.1-2_i386.deb</nowiki> <br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/paparazzi-dev_3.1-2_i386.deb</nowiki><br />
sudo dpkg -i libsubject-perl_2.00_all.deb<br />
sudo dpkg -i xml-light-ocaml_2.1-2_i386.deb<br />
sudo dpkg -i ivy-ocaml_1.1-2_i386.deb<br />
sudo dpkg -i ivy-perl_4.21_all.deb<br />
sudo apt-get install perl-tk<br />
sudo apt-get -f install<br />
sudo dpkg -i paparazzi-base_3.1-2_i386.deb<br />
sudo dpkg -i paparazzi-bin_3.1-2_i386.deb<br />
sudo dpkg -i paparazzi-dev_3.1-2_i386.deb<br />
mkdir -p $USER/paparazzi3/conf/<br />
paparazzi<br />
Then follow the source install installation instructions above with cvs and after building the cvs paparazzi execute the ./paparazzi in the cvs distribution to get paparazzi-center as above. Note: compiling and loading the AP will fail on ubuntu unless you have installed an arm-elf-gcc cross tool chain. NEW Paparazzi users who are also new to Debian, may prefer the Ubuntu distribution (based on Debian) as it allows an easier entry to paparazzi goodness then a "pure" debian distribution for the novice while allowing access to all of Debian's wizardry as you become more experienced.<br />
<br />
== Software Updates ==<br />
Paparazzi is a very rapidly evolving project and as such, you will find that variables and functions are frequently added, changed, or removed. Update your software with care and caution, and always test the functionality on the ground and in the air as some updates will affect tuning parameters. Your airframe file will not be updated by the CVS system and therefore any new or modified variable names will need to be added manually. The compiler will usually identify the problem variables at which point you can look at some of the most recent airframe files on the CVS to find the proper syntax. See the [[Compiling]] page for more help if needed.<br />
<br><br />
That said, keeping your software up to date is easy with the CVS system. The system will compare all source code files with the server and update any that are needed, automatically merging any minor changes that you have incorporated along the way.<br />
<br />
To download and automatically merge any updated source files, run the following command from your Paparazzi directory<br />
cvs update -d<br />
where the <tt>-d</tt> is needed to get any new directories.<br />
<br />
Users making changes to their code structure may prefer to have more control over the updating and merging process and may wish to install and use '''tkcvs''' instead which provides highlighted comparisons of any files that differ between your code and the CVS server and allows for a file by file update.<br />
<br />
To update your Linux distribution as well as any dependencies of Paparazzi (seldom necessary), run the following as root:<br />
apt-get update<br />
apt get upgrade<br />
<br />
== LiveCd ==<br />
<br />
The LiveCD is an easy way to test Paparazzi: no installation is required and no changes are made to your computer. Simply burn the image as a boot CD and reboot! The LiveCD includes Linux and the complete paparazzi binary package (code source, tools and cross compilers). It is intended for demonstration only and not frequently updated but it contains the complete system and can store changed files on a pen drive or compressed file on your hard drive so that it can compile, flash, and operate any aircraft, albeit slowly. <br />
<br />
The CD image is available from the [[Downloads|Downloads]] page.<br />
<br />
The Paparazzi demo is launchable on the Live CD from the Paparazzi icon.<br />
<br />
Knoppix allows for all the user data to be saved on a hard disk partition (most file systems are supported) or on a removable device (typically a USB pendrive). Note that this action is not destructive: the user data tree is compressed and stored on your file system as a single file (<tt>knoppix.img</tt>).<br />
* From the Knoppix menu (second from bottom left), choose '''Configure''', '''Create a persistent KNOPPIX disk image'''<br />
* Choose your media (be sure to connect your USB pendrive before booting!)<br />
* Choose if you want an encrypted filesystem (to protect your flight plan designed for the next MAV competition :-) )<br />
* Choose the size of your home directory (100Mb is recommended)<br />
On the next reboot, this saved state will be automatically located and loaded.<br />
<br />
Using this persistent feature, the Paparazzix Live CD can really be used to configure, simulate and fly an aircraft with the Paparazzi system.<br />
<br />
The Live CD can also be used to install a Debian system on the hard disk, using the <tt>knoppix-installer</tt> command. Be sure to backup the hard disk before trying ...</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Installation/Linux&diff=2644Installation/Linux2007-09-04T18:14:32Z<p>Alexisld: /* Installation on Debian */</p>
<hr />
<div>Precompiled binaries can be downloaded and executed with the ''paparazzi-bin'' package but to maintain the power and flexibility of open-source code, most operations within Paparazzi involve recompilation of autopilot and/or ground station code. Therefore the typical installation requires all of the necessary C, OCAML, and Perl compilers as well as some XML and Ivy handlers.<br />
<br />
== Setting your Environment Variables ==<br />
Before launching the GCS or compiling anything you must have the Paparazzi source and home environment variables set correctly in your shell. These variables can be automatically set in your shell by adding the following lines to your .bashrc file:<br />
{{Box Code|/home/your_username/.bashrc|<br />
export PAPARAZZI_HOME<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
export PAPARAZZI_SRC<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
}}<br />
If you wish to manually set the env variables (i.e. when compiling a backup copy of your code in a different folder) execute the following command from the folder you wish to set as your active paparazzi folder:<br />
export PAPARAZZI_HOME=`pwd`;export PAPARAZZI_SRC=`pwd`<br />
Verify that your variables are set correctly with the following command:<br />
env | grep PAPARAZZI<br />
which should return the following:<br />
PAPARAZZI_HOME<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
PAPARAZZI_SRC<nowiki>=</nowiki>/home/''your_username''/paparazzi3<br />
<br />
== Installation on Debian ==<br />
<br />
Paparazzi is packaged for Debian as well as all of its dependencies. The [http://www.recherche.enac.fr/paparazzi/debian repository] hosted at ENAC holds their latest version.<br />
<br />
=== Installation from the Command Line===<br />
Just add the following line(s) to your repository list (<b>/etc/apt/sources.list</b>). Note: etch users must include ''both'' sarge and etch lines.<br />
{{Box Code|/etc/apt/sources.list|<br />
deb <nowiki>http://www.recherche.enac.fr/paparazzi/debian</nowiki> sarge main<br />
#if needed deb <nowiki>http://www.recherche.enac.fr/paparazzi/debian etch main</nowiki><br />
}}<br />
Then, update your sources and install the precompiled binaries as well as the dependencies needed for recompiling:<br />
apt-get update<br />
apt-get install paparazzi-bin<br />
apt-get install paparazzi-base<br />
apt-get install paparazzi-dev<br />
apt-get install paparazzi-arm7<br />
<br />
=== Installation thru Synaptic Package Manager ===<br />
* Launch ''Synaptic Package Manager'' (''Applications/System'' Tools Menu)<br />
* In '''Settings/Repositories''', add a new repository on URI = '''<nowiki>http://www.recherche.enac.fr/paparazzi/debian</nowiki>''', Distribution = '''sarge''', Section = '''main'''<br />
* Users of current linux versions must also add '''<nowiki>http://www.recherche.enac.fr/paparazzi/debian</nowiki>''', Distribution = '''etch''', Section = '''main''' (both Sarge and Etch are needed)<br />
* Search for paparazzi-bin, paparazzi-base, paparazzi-dev, and paparazzi-arm7 packages (use the ''Search'' button)<br />
* Mark them for installation (right-click on package names)<br />
* Left-click on ''Apply''<br />
<br />
=== Optional/Obsolete Packages ===<br />
Users of older AVR based boards will also need the paparazzi-avr package.<br />
<br />
=== Installing the Source Code ===<br />
After the dependency packages are installed the complete source code should be downloaded from the CVS. See the [http://savannah.nongnu.org/cvs/?group=paparazzi project page] at Savannah for more details. From /home/''your_username''/ type:<br />
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/paparazzi co paparazzi3<br />
This will download all of the code and install it into /home/''your_username''/paparazzi3/<br />
<br />
If you cannot use the CVS install, occasionally updated tarballs can also be fetched from the [[Downloads|Downloads]] page.<br />
<br />
=== Extra for Ubuntu 7.04 ===<br />
<br />
The Braille TTY driver interferes with FTDI USB Serial adapters and should be removed:<br />
<br />
sudo apt-get remove brltty<br />
<br />
You need permission to access the "raw" USB bus. You should be member of the dialout group and tell the system to allow access by copying the file "10-paparazzi.rules" as root from $PAPARAZZI_HOME/conf/system/udev/rules/ to /etc/udev/rules.d and adding the line <br />
<br />
BUS=="usb", SYSFS{idVendor}=="7070", GROUP="dialout"<br />
<br />
== Launching the Software ==<br />
Make sure your [[Installation#Setting_your_Environment_Variables|environment variables]] are set correctly and launch the software from /home/''your_username''/paparazzi3/ with:<br />
<br />
./paparazzi<br />
<br />
== Recompiling ==<br />
After any CVS update or source code modification the code can be recompiled from /home/''your_username''/paparazzi3/ with the following command:<br />
<br />
make<br />
<br />
The ''make'' command will only recompile portions of the software where changed have been detected. If it does not behave as expected you can deleted all compiled files and recompile from scratch with the following commands:<br />
<br />
make clean<br />
make<br />
<br />
See the [[Compiling]] page for more info.<br />
<br />
== Manual Installation of Individual Packages ==<br />
Users of Ubuntu or other Linux flavors or anyone needing manual control of each individual package can install them independently. The list of dependencies of the Debian package is located in the <tt>debian/control</tt> file and may help users of other distributions.<br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/sarge/main/binary-i386/libsubject-perl_2.00_all.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/xml-light-ocaml_2.1-2_i386.deb</nowiki><br />
wget <nowiki>http://www.tls.cena.fr/products/ivy/download/packages/ivy-perl_4.21_all.deb</nowiki><br />
wget <nowiki>http://www.tls.cena.fr/products/ivy/download/packages/ivy-c_3.9.2-1_i386.deb</nowiki><br />
wget <nowiki>http://www.tls.cena.fr/products/ivy/download/packages/ivy-c-dev_3.9.2-1_i386.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/ivy-ocaml_1.1-2_i386.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/paparazzi-base_3.1-2_i386.deb</nowiki><br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/paparazzi-bin_3.1-2_i386.deb</nowiki> <br />
wget <nowiki>http://www.recherche.enac.fr/paparazzi/debian/dists/etch/main/binary-i386/paparazzi-dev_3.1-2_i386.deb</nowiki><br />
sudo dpkg -i libsubject-perl_2.00_all.deb<br />
sudo dpkg -i xml-light-ocaml_2.1-2_i386.deb<br />
sudo dpkg -i ivy-ocaml_1.1-2_i386.deb<br />
sudo dpkg -i ivy-perl_4.21_all.deb<br />
sudo apt-get install perl-tk<br />
sudo apt-get -f install<br />
sudo dpkg -i paparazzi-base_3.1-2_i386.deb<br />
sudo dpkg -i paparazzi-bin_3.1-2_i386.deb<br />
sudo dpkg -i paparazzi-dev_3.1-2_i386.deb<br />
mkdir -p $USER/paparazzi3/conf/<br />
paparazzi<br />
Then follow the source install installation instructions above with cvs and after building the cvs paparazzi execute the ./paparazzi in the cvs distribution to get paparazzi-center as above. Note: compiling and loading the AP will fail on ubuntu unless you have installed an arm-elf-gcc cross tool chain. NEW Paparazzi users who are also new to Debian, may prefer the Ubuntu distribution (based on Debian) as it allows an easier entry to paparazzi goodness then a "pure" debian distribution for the novice while allowing access to all of Debian's wizardry as you become more experienced.<br />
<br />
== Software Updates ==<br />
Paparazzi is a very rapidly evolving project and as such, you will find that variables and functions are frequently added, changed, or removed. Update your software with care and caution, and always test the functionality on the ground and in the air as some updates will affect tuning parameters. Your airframe file will not be updated by the CVS system and therefore any new or modified variable names will need to be added manually. The compiler will usually identify the problem variables at which point you can look at some of the most recent airframe files on the CVS to find the proper syntax. See the [[Compiling]] page for more help if needed.<br />
<br><br />
That said, keeping your software up to date is easy with the CVS system. The system will compare all source code files with the server and update any that are needed, automatically merging any minor changes that you have incorporated along the way.<br />
<br />
To download and automatically merge any updated source files, run the following command from your Paparazzi directory<br />
cvs update -d<br />
where the <tt>-d</tt> is needed to get any new directories.<br />
<br />
Users making changes to their code structure may prefer to have more control over the updating and merging process and may wish to install and use '''tkcvs''' instead which provides highlighted comparisons of any files that differ between your code and the CVS server and allows for a file by file update.<br />
<br />
To update your Linux distribution as well as any dependencies of Paparazzi (seldom necessary), run the following as root:<br />
apt-get update<br />
apt get upgrade<br />
<br />
== LiveCd ==<br />
<br />
The LiveCD is an easy way to test Paparazzi: no installation is required and no changes are made to your computer. Simply burn the image as a boot CD and reboot! The LiveCD includes Linux and the complete paparazzi binary package (code source, tools and cross compilers). It is intended for demonstration only and not frequently updated but it contains the complete system and can store changed files on a pen drive or compressed file on your hard drive so that it can compile, flash, and operate any aircraft, albeit slowly. <br />
<br />
The CD image is available from the [[Downloads|Downloads]] page.<br />
<br />
The Paparazzi demo is launchable on the Live CD from the Paparazzi icon.<br />
<br />
Knoppix allows for all the user data to be saved on a hard disk partition (most file systems are supported) or on a removable device (typically a USB pendrive). Note that this action is not destructive: the user data tree is compressed and stored on your file system as a single file (<tt>knoppix.img</tt>).<br />
* From the Knoppix menu (second from bottom left), choose '''Configure''', '''Create a persistent KNOPPIX disk image'''<br />
* Choose your media (be sure to connect your USB pendrive before booting!)<br />
* Choose if you want an encrypted filesystem (to protect your flight plan designed for the next MAV competition :-) )<br />
* Choose the size of your home directory (100Mb is recommended)<br />
On the next reboot, this saved state will be automatically located and loaded.<br />
<br />
Using this persistent feature, the Paparazzix Live CD can really be used to configure, simulate and fly an aircraft with the Paparazzi system.<br />
<br />
The Live CD can also be used to install a Debian system on the hard disk, using the <tt>knoppix-installer</tt> command. Be sure to backup the hard disk before trying ...</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2643Classix2007-09-03T21:09:02Z<p>Alexisld: /* Assembly */</p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
<br />
* check the polarity of all parts, compare to a picture of a working reference board<br />
* use a microscope or a magnifying glass to check for short circuits<br />
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 5V<br />
* the 5V should not drop due to current limiting, measure the 3.7V and the 3.3V supply on the board<br />
-> wrong voltages: check the parts around the power supply<br />
* measure the current, it should be around 40mA at 5V with the LPC running and no code loaded <br />
* attach one reset to GND, current should reduce to 30mA at 5V<br />
-> check if reset signal can be measured at the LPC reset pin 57<br />
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)<br />
* connect TXD and RXD of either AP_Serial or FBW_Serial 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 ground or connect to a pushbutton and reset the board<br />
* run the serial ROM loader lpc21isp to flash USB bootloader with<br />
make upload_bl PROC=GENERIC<br />
-> check the rx/tx pins for data if flashing does not succeed<br />
* deattach the LPC_P0.14, reset the board, current should be around 160 mA @ 5V when both AP and FWB are programmed<br />
* the USB bootloader outputs debug information with 115200 8N1 on the serial port<br />
picocom -b 115200 /dev/ttyUSB0<br />
* connect USB+ (D+), USB- (D-), and GND of AP or FBW with your PC, reset the board<br />
* 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<br />
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-<br />
* flash the autopilot with<br />
make AIRCRAFT=myplane clean_ac ap.upload<br />
(where myplane is the name of your airframe as defined in conf/conf.xml... Try with AIRCRAFT=TJ1 if you don't know what to use)<br />
* check telemetry through serial port, messages should be displayed<br />
* test A/D converters for supply voltage and IR sensors<br />
* check modem, connect tx, rx, gnd and supply<br />
* try to aquire sats outside<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2642Classix2007-09-03T20:39:46Z<p>Alexisld: /* Assembly */</p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
<br />
* check the polarity of all parts, compare to a picture of a working reference board<br />
* use a microscope or a magnifying glass to check for short circuits<br />
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 5V<br />
* the 5V should not drop due to current limiting, measure the 3.7V and the 3.3V supply on the board<br />
-> wrong voltages: check the parts around the power supply<br />
* measure the current, it should be around 40mA at 5V with the LPC running and no code loaded <br />
* attach one reset to GND, current should reduce to 30mA at 5V<br />
-> check if reset signal can be measured at the LPC reset pin 57<br />
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)<br />
* connect TXD and RXD of either AP_Serial or FBW_Serial 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 ground or connect to a pushbutton and reset the board<br />
* run the serial ROM loader lpc21isp to flash USB bootloader with<br />
make upload_bl PROC=GENERIC<br />
-> check the rx/tx pins for data if flashing does not succeed<br />
* deattach the LPC_P0.14, reset the board, current should be around 160 mA @ 5V when both AP and FWB are programmed<br />
* the USB bootloader outputs debug information with 115200 8N1 on the serial port<br />
picocom -b 115200 /dev/ttyUSB0<br />
* connect USB+ (D+), USB- (D-), and GND of AP or FBW with your PC, reset the board<br />
* 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<br />
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-<br />
* flash the autopilot with<br />
make AIRCRAFT=myplane clean_ac ap.upload<br />
(where myplane is the name of your airframe as defined in conf/conf.xml)<br />
* check telemetry through serial port, messages should be displayed<br />
* test A/D converters for supply voltage and IR sensors<br />
* check modem, connect tx, rx, gnd and supply<br />
* try to aquire sats outside<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2641Classix2007-09-03T20:38:26Z<p>Alexisld: /* Assembly */</p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
<br />
* check the polarity of all parts, compare to a picture of a working reference board<br />
* use a microscope or a magnifying glass to check for short circuits<br />
* use a power supply for first tests, not a battery, limit the current to about 100mA, use a voltage of about 5V<br />
* the 5V should not drop due to current limiting, measure the 3.7V and the 3.3V supply on the board<br />
-> wrong voltages: check the parts around the power supply<br />
* measure the current, it should be around 40mA at 5V with the LPC running and no code loaded <br />
* attach one reset to GND, current should reduce to 30mA at 5V<br />
-> check if reset signal can be measured at the LPC reset pin 57<br />
* check the 12MHz at LPC pin 61, XTAL2 (XTAL_out)<br />
* connect TXD and RXD of either AP_Serial or FBW_Serial 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 ground or connect to a pushbutton and reset the board<br />
* run the serial ROM loader lpc21isp to flash USB bootloader with<br />
make upload_bl PROC=GENERIC<br />
-> check the rx/tx pins for data if flashing does not succeed<br />
* deattach the LPC_P0.14, reset the board, current should be around 160 mA @ 5V when both AP and FWB are programmed<br />
* the USB bootloader outputs debug information with 115200 8N1 on the serial port<br />
* connect USB+ (D+), USB- (D-), and GND of AP or FBW with your PC, reset the board<br />
* 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<br />
-> if a new USB device is detected but does not accept new address, the USBconnect worked, but not the communication, check USB+ and USB-<br />
* flash the autopilot with<br />
make AIRCRAFT=myplane clean_ac ap.upload<br />
(where myplane is the name of your airframe as defined in conf/conf.xml)<br />
* check telemetry through serial port, messages should be displayed<br />
* test A/D converters for supply voltage and IR sensors<br />
* check modem, connect tx, rx, gnd and supply<br />
* try to aquire sats outside<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2640Classix2007-09-03T20:20:17Z<p>Alexisld: </p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
* On first power up (no code in the LPC) I got 0.04 amp @ 5V<br />
* Once both LPC uploaded with the USB bootloader I got 0.16 amp @ 5V<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2639Classix2007-09-03T20:19:53Z<p>Alexisld: /* Assembly */</p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
On first power up (no code in the LPC) I got 0.04 amp @ 5V<br />
Once both LPC uploaded with the USB bootloader I got 0.16 amp @ 5V<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed.</div>Alexisldhttp://wiki.paparazziuav.org/w/index.php?title=Classix&diff=2638Classix2007-09-03T20:19:22Z<p>Alexisld: </p>
<hr />
<div>The Classix autopilot was designed for advanced applications. Dual processors provide a true hardware segregation of critical code for reliability - allowing the user to run experimental navigation or payload control software without fear of a processor crash causing a total loss of control. A [http://www.gumstix.com Gumstix] header is included so that the autopilot can be directly interfaced with this small onboard Linux PC for advanced video processing, sensor management, or sophisticated navigation routines such as sense-and-avoid or target following.<br />
<br />
== Classix Control Board ==<br />
<br />
[[Image:classix_proto1_top_small.jpg|thumb|left|300px|Classix autopilot with Gumstix daughterboard]]<br />
[[Image:classix_proto1_bot_small.jpg|thumb|left|300px|Classix Dual MCUs]]<br />
<br style="clear:both"><br />
<br />
== Features ==<br />
<br />
* Dual LPC2148 MCUs<br />
* 14 ADC channels<br />
* 2 UARTs<br />
* 6 PWM outputs<br />
* 2 R/C Receiver inputs<br />
* 2 combined USB clients<br />
* 2 [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] busses<br />
* 2 [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C]<br />
* Connector to dock with a [http://www.gumstix.com Gumstix] board<br />
* 5V input<br />
* 3.3V linear regulator & 3.7V linear regulator (for Gumstix)<br />
* Audio (for data downlink without a modem)<br />
* 2 LEDs (status display)<br />
* 12 grams<br />
* 89 x 30mm<br />
<br />
The Classix Control Board use 2 Philips LPC2148 ARM7 based microcontroller.<br />
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.<br />
<br />
With 2 MCUs this system is very robust, 1 MCU can handle all critical code, fly-by-wire and such, and the other can handle all autonomous processing. In the case of autonomous code error, the aircraft may be saved via manual control and the fbw MCU.<br />
<br />
The ability to dock with a [http://www.gumstix.com Gumstix] board would allow for image processing, heavy communications, or payload support.<br />
<br />
== Architecture ==<br />
<br />
[[Image:Classix_Architecture.jpg]]<br />
<br />
== Pinout ==<br />
[[Image:Classix_v099_pinout.jpg]]<br />
<br />
== BOM ==<br />
<br />
The materials list can be produced from the Eagle CAD files on the [[Downloads|downloads]] page.<br />
<br />
== Assembly == <br />
Here are a few observation from my Classix assembly/programming (see Tiny_Assembly for more info): <br />
- On first power up (no code in the LPC) I got 0.04 amp @ 5V<br />
- Once both LPC uploaded with the USB bootloader I got 0.16 amp @ 5V<br />
<br />
<br />
== TODO ==<br />
As noted in the IRC channel the clasix lacks certain "conveniences" of the tiny<br />
<br />
* No onboard CD4015B for a servo driver<br />
* No onboard 5V VR 2A VR for Servos<br />
* No onboard GPS<br />
<br />
The above being said , the first 2 items should be easily fixed by modifying the schematic(s) for the classix and regenerating the board layout in eagle(adding the necessary lines etc) or generating a servo driver and 5v VR board to interface with the classix for now till the above is completed.</div>Alexisld