http://wiki.paparazziuav.org/w/api.php?action=feedcontributions&user=Mbina&feedformat=atomPaparazziUAV - User contributions [en]2024-03-28T16:01:42ZUser contributionsMediaWiki 1.37.1http://wiki.paparazziuav.org/w/index.php?title=Subsystem/ahrs&diff=16174Subsystem/ahrs2013-10-17T19:27:22Z<p>Mbina: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree><br />
== AHRS subsystem ==<br />
The '''A'''ttitude and '''H'''eading '''R'''eference '''S'''ystem subsystem specifies which attitude estimation filter you are using.<br />
<br />
Currently possible AHRS subsystem types are<br />
* ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''<br />
* ''[[Subsystem/ahrs#Complementary_Quaternion.2FRotation_Matrix_.28floating_point.29|float_cmpl]]''<br />
* ''[[Subsystem/ahrs#DCM_.28floating_point.29|float_dcm]]''<br />
* ''[[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|int_cmpl_euler]]''<br />
* ''[[Subsystem/ahrs#Kalman_Filter_Quaternion|float_mlkf]]''<br />
* ''[[Subsystem/ahrs#Infrared|infrared]]''<br />
<br />
e.g. for the latest complementary filter:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_quat"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
== Implementations ==<br />
<br />
There is a test program ( sw/airborne/test/ahrs/compare_ahrs.py ) to compare different AHRS implementations on simple test cases.<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> '''Please also see [https://github.com/paparazzi/paparazzi/issues/93 issue 93] about proper handling of BODY_TO_IMU in all AHRS algorithms.'''<br />
<br />
<br />
=== Complementary Quaternion (fixed point) ===<br />
* Estimates the gyro bias.<br />
* By default uses magnetometer for heading.<br />
* In v3.9 and later:<br />
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.<br />
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130<br />
<br />
Other flags of interest are:<br />
*AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity<br />
*AHRS_MAG_UPDATE_ALL_AXES : '''available since v3.9''' use mag to also update roll/pitch and not only yaw (not recommended in most cases)<br />
*AHRS_MAG_UPDATE_YAW_ONLY : '''removed in v3.9, default behaviour since''' only update the yaw instead of all axes <br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_quat"/><br />
</firmware><br />
<br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value=" 0.51562740288882"/><br />
<define name="H_Y" value="-0.05707735220832"/><br />
<define name="H_Z" value=" 0.85490967783446"/><br />
</section><br />
</source><br />
}}<br />
<br />
Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.<br />
<br />
<p><br />
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.<br />
<br/><br />
Suitable for fixedwings. Needs GPS!<br />
<br/><br />
Suitable for rotorcraft if the magnetometer is calibrated.<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== Complementary Quaternion/Rotation Matrix (floating point) ===<br />
* Estimates the gyro bias.<br />
* By default uses magnetometer for heading.<br />
* You need to define either ''AHRS_PROPAGATE_RMAT'' or ''AHRS_PROPAGATE_QUAT'' (select if the propagation is done in rotation matrix or quaternion representation).<br />
* In v3.9 and later:<br />
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.<br />
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130<br />
Other flags of interest are:<br />
* AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity<br />
* AHRS_MAG_UPDATE_ALL_AXES : use mag to also update roll/pitch and not only yaw (not recommended in most cases)<br />
* AHRS_GRAVITY_UPDATE_NORM_HEURISTIC: lower the gain of the gravity update based on a acceleration norm heuristic (e.g. good for bungee takeoff)<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft or fixedwing"><br />
...<br />
<subsystem name="ahrs" type="float_cmpl_rmat"><br />
<define name="AHRS_PROPAGATE_QUAT"/><br />
</subsystem><br />
</firmware><br />
<br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value=" 0.51562740288882"/><br />
<define name="H_Y" value="-0.05707735220832"/><br />
<define name="H_Z" value=" 0.85490967783446"/><br />
</section><br />
</source><br />
}}<br />
<br />
Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.<br />
<br />
<br />
<p><br />
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.<br />
<br/><br />
Suitable for fixedwings. Needs GPS!<br />
<br/><br />
Suitable for rotorcraft if the magnetometer is calibrated.<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== DCM (floating point) ===<br />
* No direct gyro bias estimation, but also compensates for attitude drift.<br />
* Uses GPS speed for heading.<br />
* Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br />
* '''Careful, it doesn't handle all BODY_TO_IMU rotations (mounting positions) correctly!'''<br />
<br />
The algorithm was developed by William Premerlani and Paul Bizard. The theory can be found here: [[Media:DCMDraft2.pdf|DCMDraft2.pdf]] The algorithm is also used in the AHRS systems of the AdruIMU.<br />
The name DCM for the algorithm is really a misnomer, as that just means that the orientation is represented as a '''D'''irection'''C'''osine'''M'''atrix (rotation matrix). But since people already know it under that name, we kept it.<br />
<br />
Other flags of interest are:<br />
*USE_MAGNETOMETER : use magnetometer to update yaw (untested ? The magnetometer code has to be improved, since ferromagnetic materials affect the magnetic field. This is currently not implemented.)<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft or fixedwing"><br />
...<br />
<subsystem name="ahrs" type="float_dcm"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
<br />
<p><br />
Possible danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are not used.<br />
<br/><br />
Suitable for fixedwings with GPS.<br />
<br/><br />
Possibly suitable for rotorcraft if the magnetometer is used to determine the yaw and well calibrated, which seems to be questionable at the moment.<br />
<= This information needs an update (see info above)!<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
<br />
=== Complementary Euler (fixed point) ===<br />
* Not recommended for fixedwings, as this filter doesn't compensate for centrifugal force when flying turns.<br />
* Magnetometer is always only used for heading (yaw).<br />
* '''Does not handle the accel and mag updates correctly if BODY_TO_IMU is used for more than just adjustment by a few degrees.'''<br />
* In general, rather use ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''<br />
<br />
Optional flags/defines are:<br />
* FACE_REINJ_1 : defaults to 1024<br />
* IMU_MAG_OFFSET : offset to subtract from the heading calculated by the magnetometer<br />
* USE_NOISE_FILTER : apply a simple filter on the rate and accel inputs<br />
* USE_NOISE_CUT : cut rate input at 1 rad/s and accel input at 20m/s²<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_euler"/><br />
</firmware><br />
<br />
<section name="MISC"><br />
<define name="FACE_REINJ_1" value="1024"/> <!-- optional, defaults to 1024 --><br />
</section><br />
</source><br />
}}<br />
<br />
<p><br />
Possible danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are not used.<br />
<br/><br />
Repeat from above: '''Not''' suitable for fixedwings.<br />
<br/><br />
Suitable for rotorcraft. The magnetometer is used to determine the yaw and needs to be calibrated.<br />
Recommended replacement: [[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== Kalman Filter Quaternion ===<br />
Multiplicative Linearized [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] in quaternion formulation.<br />
* Available in v5.0 and later<br />
* Estimates the gyro bias.<br />
* Uses magnetometer to update all 3 axes.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="float_mlkf"/><br />
</firmware><br />
<br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value=" 0.51562740288882"/><br />
<define name="H_Y" value="-0.05707735220832"/><br />
<define name="H_Z" value=" 0.85490967783446"/><br />
</section><br />
</source><br />
}}<br />
<br />
Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.<br />
<br />
<p><br />
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.<br />
<br/><br />
'''Not''' suitable for fixedwings!<br />
<br/><br />
Suitable for rotorcraft. The magnetometer is used and needs to be well calibrated.<br />
Estimates attitude and heading. Does not use GPS.<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== Infrared ===<br />
For use with infrared sensors that detect aircraft attitude and the [[Module/infrared| infrared module]].<br />
<br />
== Local Magnetic Field ==<br />
[[Image:Noaa_mag_data.png|thumb|right|200px|Screenshot of noaa page]]<br />
[[Image:Normalised_mag_fields.png|thumb|right|200px|Screenshot of scilab page]]<br />
'''This is needed if the magnetometer should be used !'''<br />
<br />
First the values of the local magnetic field are needed. They can be found at the states geolocical institute.<br />
<br />
Neede values are:<br />
* north (x)<br />
* east (y)<br />
* vertical (z)<br />
<br />
USA [http://www.ngdc.noaa.gov/geomag-web/#igrfwmm ngdc.noaa.gov]<br />
<br />
AHRS needs these values as values of a unit vector (the lengh of a unit vector is 1), so they need to be converted.<br />
<br />
'''Convert them:'''<br />
<br />
Copy the north(x), east(y), and vertical(z) component values into scilab and execute "X/norm(X)" or run this in ipython:<br />
<br />
<source lang=python><br />
import numpy as np<br />
x = np.array([20875.1, 8480.2, -51279.8])<br />
x/np.linalg.norm(x)<br />
</source><br />
<br />
or enter this into [http://wolframalpha.com Wolfram Alpha]:<br />
<source lang=python><br />
{20875.1, 8480.2, -51279.8}/Norm[{20875.1, 8480.2, -51279.8}]<br />
</source><br />
[[Category:User_Documentation]] [[Category:Subsystems]]<br />
<br />
Lastly, enter the results into your airframe file as H_X, H_Y, and H_Z:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value="0.372692"/><br />
<define name="H_Y" value="0.151401"/><br />
<define name="H_Z" value="-0.915521"/><br />
</section><br />
</source><br />
}}</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Subsystem/ahrs&diff=16173Subsystem/ahrs2013-10-17T19:24:07Z<p>Mbina: Added basic info at the end of each AHRS section for users ... if info is incorrect please correct it</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree><br />
== AHRS subsystem ==<br />
The '''A'''ttitude and '''H'''eading '''R'''eference '''S'''ystem subsystem specifies which attitude estimation filter you are using.<br />
<br />
Currently possible AHRS subsystem types are<br />
* ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''<br />
* ''[[Subsystem/ahrs#Complementary_Quaternion.2FRotation_Matrix_.28floating_point.29|float_cmpl]]''<br />
* ''[[Subsystem/ahrs#DCM_.28floating_point.29|float_dcm]]''<br />
* ''[[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|int_cmpl_euler]]''<br />
* ''[[Subsystem/ahrs#Kalman_Filter_Quaternion|float_mlkf]]''<br />
* ''[[Subsystem/ahrs#Infrared|infrared]]''<br />
<br />
e.g. for the latest complementary filter:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_quat"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
== Implementations ==<br />
<br />
There is a test program ( sw/airborne/test/ahrs/compare_ahrs.py ) to compare different AHRS implementations on simple test cases.<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> '''Please also see [https://github.com/paparazzi/paparazzi/issues/93 issue 93] about proper handling of BODY_TO_IMU in all AHRS algorithms.'''<br />
<br />
<br />
=== Complementary Quaternion (fixed point) ===<br />
* Estimates the gyro bias.<br />
* By default uses magnetometer for heading.<br />
* In v3.9 and later:<br />
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.<br />
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130<br />
<br />
Other flags of interest are:<br />
*AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity<br />
*AHRS_MAG_UPDATE_ALL_AXES : '''available since v3.9''' use mag to also update roll/pitch and not only yaw (not recommended in most cases)<br />
*AHRS_MAG_UPDATE_YAW_ONLY : '''removed in v3.9, default behaviour since''' only update the yaw instead of all axes <br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_quat"/><br />
</firmware><br />
<br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value=" 0.51562740288882"/><br />
<define name="H_Y" value="-0.05707735220832"/><br />
<define name="H_Z" value=" 0.85490967783446"/><br />
</section><br />
</source><br />
}}<br />
<br />
Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.<br />
<br />
<p><br />
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.<br />
<br/><br />
Suitable for fixedwings. Needs GPS!<br />
<br/><br />
Possibly suitable for rotorcraft if the magnetometer is used to deterimine the yaw and well calibrated.<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== Complementary Quaternion/Rotation Matrix (floating point) ===<br />
* Estimates the gyro bias.<br />
* By default uses magnetometer for heading.<br />
* You need to define either ''AHRS_PROPAGATE_RMAT'' or ''AHRS_PROPAGATE_QUAT'' (select if the propagation is done in rotation matrix or quaternion representation).<br />
* In v3.9 and later:<br />
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.<br />
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130<br />
Other flags of interest are:<br />
* AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity<br />
* AHRS_MAG_UPDATE_ALL_AXES : use mag to also update roll/pitch and not only yaw (not recommended in most cases)<br />
* AHRS_GRAVITY_UPDATE_NORM_HEURISTIC: lower the gain of the gravity update based on a acceleration norm heuristic (e.g. good for bungee takeoff)<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft or fixedwing"><br />
...<br />
<subsystem name="ahrs" type="float_cmpl_rmat"><br />
<define name="AHRS_PROPAGATE_QUAT"/><br />
</subsystem><br />
</firmware><br />
<br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value=" 0.51562740288882"/><br />
<define name="H_Y" value="-0.05707735220832"/><br />
<define name="H_Z" value=" 0.85490967783446"/><br />
</section><br />
</source><br />
}}<br />
<br />
Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.<br />
<br />
<br />
<p><br />
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.<br />
<br/><br />
Suitable for fixedwings. Needs GPS!<br />
<br/><br />
Possibly suitable for rotorcraft if the magnetometer is used to deterimine the yaw and well calibrated.<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== DCM (floating point) ===<br />
* No direct gyro bias estimation, but also compensates for attitude drift.<br />
* Uses GPS speed for heading.<br />
* Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br />
* '''Careful, it doesn't handle all BODY_TO_IMU rotations (mounting positions) correctly!'''<br />
<br />
The algorithm was developed by William Premerlani and Paul Bizard. The theory can be found here: [[Media:DCMDraft2.pdf|DCMDraft2.pdf]] The algorithm is also used in the AHRS systems of the AdruIMU.<br />
The name DCM for the algorithm is really a misnomer, as that just means that the orientation is represented as a '''D'''irection'''C'''osine'''M'''atrix (rotation matrix). But since people already know it under that name, we kept it.<br />
<br />
Other flags of interest are:<br />
*USE_MAGNETOMETER : use magnetometer to update yaw (untested ? The magnetometer code has to be improved, since ferromagnetic materials affect the magnetic field. This is currently not implemented.)<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft or fixedwing"><br />
...<br />
<subsystem name="ahrs" type="float_dcm"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
<br />
<p><br />
Possible danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are not used.<br />
<br/><br />
Suitable for fixedwings with GPS.<br />
<br/><br />
Possibly suitable for rotorcraft if the magnetometer is used to deterimine the yaw and well calibrated, which seems to be questionable at the moment.<br />
<= This information needs an update (see info above)!<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
<br />
=== Complementary Euler (fixed point) ===<br />
* Not recommended for fixedwings, as this filter doesn't compensate for centrifugal force when flying turns.<br />
* Magnetometer is always only used for heading (yaw).<br />
* '''Does not handle the accel and mag updates correctly if BODY_TO_IMU is used for more than just adjustment by a few degrees.'''<br />
* In general, rather use ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''<br />
<br />
Optional flags/defines are:<br />
* FACE_REINJ_1 : defaults to 1024<br />
* IMU_MAG_OFFSET : offset to subtract from the heading calculated by the magnetometer<br />
* USE_NOISE_FILTER : apply a simple filter on the rate and accel inputs<br />
* USE_NOISE_CUT : cut rate input at 1 rad/s and accel input at 20m/s²<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_euler"/><br />
</firmware><br />
<br />
<section name="MISC"><br />
<define name="FACE_REINJ_1" value="1024"/> <!-- optional, defaults to 1024 --><br />
</section><br />
</source><br />
}}<br />
<br />
<p><br />
Possible danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are not used.<br />
<br/><br />
Repeat from above: '''Not''' suitable for fixedwings.<br />
<br/><br />
Suitable for rotorcraft. The magnetometer is used to deterimine the yaw and needs to be calibrated.<br />
Recommended replacement: [[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed point] and is thus suitable if the processor (on your board) has no [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== Kalman Filter Quaternion ===<br />
Multiplicative Linearized [http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter] in quaternion formulation.<br />
* Available in v5.0 and later<br />
* Estimates the gyro bias.<br />
* Uses magnetometer to update all 3 axes.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="float_mlkf"/><br />
</firmware><br />
<br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value=" 0.51562740288882"/><br />
<define name="H_Y" value="-0.05707735220832"/><br />
<define name="H_Z" value=" 0.85490967783446"/><br />
</section><br />
</source><br />
}}<br />
<br />
Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.<br />
<br />
<p><br />
No danger of [http://en.wikipedia.org/wiki/Gimbal_lock gimbal lock], since quaternions are used.<br />
<br/><br />
'''Not''' suitable for fixedwings!<br />
<br/><br />
Suitable for rotorcraft. The magnetometer is used and needs to be well calibrated.<br />
Estimates attitude and heading. Does not use GPS.<br />
<br/><br />
The arithmetic is [http://en.wikipedia.org/wiki/Floating_point floating point] and is thus '''not''' suitable if the processor (on your board) has '''no''' [http://en.wikipedia.org/wiki/Floating_point_unit FPU].<br />
</p><br />
<br />
=== Infrared ===<br />
For use with infrared sensors that detect aircraft attitude and the [[Module/infrared| infrared module]].<br />
<br />
== Local Magnetic Field ==<br />
[[Image:Noaa_mag_data.png|thumb|right|200px|Screenshot of noaa page]]<br />
[[Image:Normalised_mag_fields.png|thumb|right|200px|Screenshot of scilab page]]<br />
'''This is needed if the magnetometer should be used !'''<br />
<br />
First the values of the local magnetic field are needed. They can be found at the states geolocical institute.<br />
<br />
Neede values are:<br />
* north (x)<br />
* east (y)<br />
* vertical (z)<br />
<br />
USA [http://www.ngdc.noaa.gov/geomag-web/#igrfwmm ngdc.noaa.gov]<br />
<br />
AHRS needs these values as values of a unit vector (the lengh of a unit vector is 1), so they need to be converted.<br />
<br />
'''Convert them:'''<br />
<br />
Copy the north(x), east(y), and vertical(z) component values into scilab and execute "X/norm(X)" or run this in ipython:<br />
<br />
<source lang=python><br />
import numpy as np<br />
x = np.array([20875.1, 8480.2, -51279.8])<br />
x/np.linalg.norm(x)<br />
</source><br />
<br />
or enter this into [http://wolframalpha.com Wolfram Alpha]:<br />
<source lang=python><br />
{20875.1, 8480.2, -51279.8}/Norm[{20875.1, 8480.2, -51279.8}]<br />
</source><br />
[[Category:User_Documentation]] [[Category:Subsystems]]<br />
<br />
Lastly, enter the results into your airframe file as H_X, H_Y, and H_Z:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="AHRS" prefix="AHRS_"><br />
<define name="H_X" value="0.372692"/><br />
<define name="H_Y" value="0.151401"/><br />
<define name="H_Z" value="-0.915521"/><br />
</section><br />
</source><br />
}}</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Users&diff=16162Users2013-10-15T20:47:34Z<p>Mbina: /* Europe */</p>
<hr />
<div>Please add yourself to this list if you wish to share who you are and what you are doing with Paparazzi<br />
<br />
== Wiki User Pages ==<br />
<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
|+ User Pages<br />
|-<br />
|- style="background:bisque; color:black"<br />
|[http://paparazzi.enac.fr/wiki/User:Dconger Dconger]<br />
|[http://paparazzi.enac.fr/wiki/User:MarcusWolschon MarcusWolschon]<br />
|[http://paparazzi.enac.fr/wiki/User:Alfamyke Alfamyke]<br />
|[http://paparazzi.enac.fr/wiki/User:Danstah Danstah]<br />
|[http://paparazzi.enac.fr/wiki/User:Martinmm Martinmm]<br />
|- style="background:bisque; color:black"<br />
|[http://paparazzi.enac.fr/wiki/User:John_Burt John Burt]<br />
|[http://paparazzi.enac.fr/wiki/User:SilaS SilaS]<br />
|[http://paparazzi.enac.fr/wiki/User:Mecevans Mecevans]<br />
|[http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU-FCUAV]<br />
|[http://paparazzi.enac.fr/wiki/User:GPH Pierre-Selim]<br />
|- style="background:bisque; color:black"<br />
|[http://paparazzi.enac.fr/wiki/User:Martinpi martinpi]<br />
|[http://paparazzi.enac.fr/wiki/User:VAMK VAMK]<br />
|[http://paparazzi.enac.fr/wiki/User:EldenC Elden_Crom]<br />
|[http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison]<br />
|[http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider]<br />
|- style="background:bisque; color:black"<br />
|[http://paparazzi.enac.fr/wiki/User:Marc Marc]<br />
|[http://paparazzi.enac.fr/wiki/User:Bu5hm4nn Bu5hm4nn]<br />
|[http://paparazzi.enac.fr/wiki/User:HWal HWal]<br />
|[http://paparazzi.enac.fr/wiki/User:Aerodolphin Rui Costa]<br />
|[http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer]<br />
|- style="background:bisque; color:black"<br />
|[http://paparazzi.enac.fr/wiki/User:PaulCox Paul Cox]<br />
|[http://paparazzi.enac.fr/wiki/User:Bruzzlee Bruzzlee]<br />
|[http://paparazzi.enac.fr/wiki/User:Stspies Stspies]<br />
|[http://paparazzi.enac.fr/wiki/User:Mzr Mzr]<br />
|[http://brquad.blogspot.com AGRESSiVA]<br />
|- style="background:bisque; color:black"<br />
|add yourself here<br />
|[http://paparazzi.enac.fr/wiki/User:Martial Martial Châteauvieux]<br />
|[http://paparazzi.enac.fr/wiki/User:Christoph Christoph]<br />
|<br />
|<br />
|}<br />
<br />
== Developers ==<br />
See [[Developers]]<br />
<br />
== Paparazzi Users sorted geographically ==<br />
<br />
===Asia===<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
|+ Asia<br />
|-<br />
! Name !! Location !! Hardware !! Joined !! Current activities / project status <br />
|- style="background:bisque; color:black"<br />
| [mailto:wzxwyvippt@126.com WANGYAO]|| China || UMARIM,twog,tiny2.11 lisa/m2.0 ||| 2008|| fly with lisa/m2.0 now, fully auto takeoff and landing <br />
|- style="background:bisque; color:black"<br />
| [mailto:zhaojinhust@gmail.com ZHAOJin]|| China || Tiny2.11 ||| 2011|| Just Finished my hand-soldered Tiny2.11 board. Welcome to my blog: freikorps.blogcn.com (CHINESE中文)<br />
|- style="background:bisque; color:black"<br />
| [mailto:laizzb@126.com dianzhichong]|| China || Umarim ||| 2011|| Fixed-wing autonomous flight. Establish QQ group (group No. 5436583) and technology sharing<br />
|- style="background:bisque; color:black"<br />
| [mailto:wangcfan@163.com Wangcfan]|| China || Tiny2.11 ||| 2008 || The beginning, is now in learning phase;Learning in Tiny2.11 using the method of IMU!<br />
|- style="background:bisque; color:black"<br />
<br />
| [mailto:mnwxiaobao@gmail.com MNW]|| China || Tiny2.11 ||| 2009 || Just starting,having troubles with parts.<br />
|- style="background:bisque; color:black"<br />
| [mailto:shubhamearly@gmail.com Shubham]|| India || Tiny2.11 ||| 2009 || Writing the configuration code for airframe<br />
|- style="background:bisque; color:black"<br />
| [mailto:mundhra@gmail.com M Mundhra] || India || Tiny 1.3 ||| 2007 || Gain tuning on a flying wing configuration airframe <br />
|- style="background:bisque; color:black"<br />
| [mailto:ngkiangloong_at_hopetechnik.com Jianlun]|| Singapore || TWOG V1 ||| 2008 || trying to get TWOG onto an EasyStar. very much a newbie!<br />
|- style="background:bisque; color:black"<br />
| [mailto:praxmail@gmail.com prashanth] || India || Tiny 2.11 ||| 2008 || 6 autonomous flights till now, currently build a new wing like funjet <br />
|- style="background:bisque; color:black"<br />
| [mailto:spencerpangborn@gmail.com spencer] || Taipei, Taiwan || none ||| 2009 || research for now, hope to take aerial photos of Taipei City soon<br />
|- style="background:bisque; color:black"<br />
| [mailto:benybeejz@gmail.com benybee] || Bandar Lampung, Indonesia || Tiny13 1.1 ||| 2010 || trying to get wing dragon fully autonomous, for aireal photograph and research<br />
|- style="background:bisque; color:black"<br />
| [mailto:iman.shirdareh@gmail.com Iman Shirdareh]|| Iran || YAPA V2,TWOG ||| 2010 || Many flight in AUTO2 by different aircraft(1.7-21Kg)<br />
|- style="background:bisque; color:black" <br />
| [mailto:anilvanjare83@gmail.com Anil vanjare] || India || TWOG, Tiny v2.1,Umarim v10 ||| 2011 || ,Umarim board assembled and tested all are ok on ground, now building a MAV to do test flight using UMARIM, with prashant<br />
|}<br />
<br />
===Europe===<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
<br />
! Name !! Location !! Hardware !! Joined !! Current activities / project status <br />
<br />
|- style="background:lightgreen; color:black"<br />
|Austria<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:NeoFromMatrix NeoFromMatrix] || Lower Austria/Vienna, Austria || STM32F4-discovery, LisaMV2 || 2013 || wiki doc, testing with low cost/high performance hardware<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Martinpi Martin Piehslinger] || Vienna, Austria || Tiny 2.11 || 2008 || just starting<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:st.jr_at_gmx.at TomS] || Graz, Austria || Tiny 2.11 ||| 2008 || Starting to complete the wiring for the tiny and then trying to apply it to my TwinStar II.<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Mbina Markus Bina] || Lower Austria/Vienna, Austria || LisaMV2 || 2013 || wiki doc, testing with low/medium cost hardware<br />
<br />
|- style="background:lightgreen; color:black"<br />
|France<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:x-microdrones@2007.polytechnique.org X-MicroDrones] || Paris, France || Tiny 2.11, Quad-Tilt-Rotor VTOL ||| 2008 || Wiring completed, first flights soon... We're trying to adapt Paparazzi to a Quad-Tilt-Rotor VTOL able to perform both airplane-like and helicopter-like flights. Working on inertial measurement units implementation. <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:pvol_at_club.fr Philippe Volivert] || Paris, France || TWOG 2.12, EasyGlider, MPX3030 ||| July 2009 || Working on pan/tilt/roll camera<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:thibaut.bergal@estaca.eu ESTACA Modélisme] || Paris, France || TWOG 2.11, Swift 2, MC22 ||| January 2010 || Starting<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:limaiem@gmail.com Imed Limaiem] || Paris, France || TWOG 2.11, EPP-CF FPV ||| January 2010 || flight test; Town pollution measurement; <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:pauldanielcox_at_gmail_dot_com Paul Cox] <br />
| Toulouse <br />
| Tiny v2.11 || Nov. 2008 || GWS Slow Stick flying in AUTO2 reliably. Starting on stabilized video and payload drops Skype: pauldanielcox Gtalk: [use email] <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:charles-edmond.bichot@ec-lyon.fr Charles-Edmond Bichot] || Lyon, France || Tiny/YAPA, IR+GPS, XBee/smartphone ||| September 2009 || Teaching projects, solar cells, object detection in video / image<br />
<br />
|- style="background:lightgreen; color:black"<br />
|Germany<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:maik.hoepfel_at_web.de Maik Hoepfel] || Berlin, Germany || TWOG, Borjet Maja, Futaba 9C 35 Mhz ||| August 2009 || Have flown different airframes and am flying a Borjet Maja right now; built a more rugged case and connecting board for PPRZ; taking surveying pictures<br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:MarcusWolschon|Marcus Wolschon]] || Freiburg, Germany || Gumstix, Paraplane ||| 2008 || Porting Paparazzi to Linux-Userland with UDP-communication using mesh-networking.<br />
UDP-Downlink working, GPS via GPSD working, Pararazzi in Linux working, Hardware still RC-only due to sensor-soldering-issues<br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:Flixr|Felix Ruess]] || Munich, Germany || Lisa/M, Lisa/L, Booz, Twog ||| 2008 || coding more than flying.... unfortunately<br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:Christoph|Christoph Niemann]] || Bremen, Germany || Reely Condor with TWOG and Sparkfun Razor-IMU ||| 2010 || Several successful AUTO2-Flights. <br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:Martial|Martial Châteauvieux]] || Munich, Germany || Bormatec/Maja with TWOG and IR ||| 2011 || Next test in January 2012, as soon as the weather permits. Hopefully I can switch in AUTO2.<br />
|- style="background:bisque; color:black"<br />
| [[User:Stspies|Steffen Spies]] || Wolfsburg, Germany || Multiplex TwinStar with Tiny V2.11 and IR ||| 2010 || Awaiting first flight. <br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:Tobi|Tobias M]] || Germany || Multiplex TwinStar II TWOG v1 and IR/imu ||| 2007 || about 120h of flight tests in Auto2 with IR - coding and testing a new vertical control with airspeed - just changed from IR to Aspirin imu - about 3h Auto2 in that configuration<br />
<br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:RoN|Rolf N]] || Bremen, Germany || TWOG, YAPA2, analog airspeed, imu ||| 2010 || many AUTO2 flights<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:rijo1011_at_gmail.com Jochen Rieger] || Karlsruhe, Germany || Bormatec Maja, Lisa/L ||| 2011 || I hope the first flight is coming soon.<br />
<br />
|- style="background:lightgreen; color:black"<br />
| Portugal<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:azoreanuav_at_gmail.com Rui Costa] || Azores, Portugal || Outrunner Twinstar II with Tiny 2.11, Aerocomm datalink, 1W video tx ||| 2008 || Only ground test and software configuration.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:muralha_at_gmail.com Nuno Guedes] || Lamego, Portugal || Tiny 2.11 || 2008 || Starting<br />
<br />
<br />
|- style="background:lightgreen; color:black"<br />
|Switzerland<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:markggriffin_at_gmail.com MarkG] || Geneva, Switzerland || Modified Tiny v2.11, TWOG v1, EeePC as GCS, Multiplex FunJet & EasyStar ||| 2008 || Many successful flights. <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:spam1_at_marzer.com CedricM] || Geneva, Switzerland || Tiny 2.11, Multiplex FunJet with video camera ||| 2008 || Many successful flights working on an osd module and weather probes. <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:reto.buettner_at_gmail.com RetoB] || Meilen, Switzerland || TWOG, Tiny 2.11, Cougar, eHawk, Y-UAV, EzOSD, Scherrer UHF ||| 2010 || Many successful flights. See [http://www.aerovista.ch/news.html www.aerovista.ch] and [http://www.y-uav.com www.y-uav.com] for current status.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:schmiemi_at_students.zhaw.ch EmilioS] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Borjet Maja, UMARS||| 2010 || Many successful flights. See [http://www.imes.zhaw.ch/de/engineering/imes/projekte/leichtbautechnik/umars/projektbeschreibung.html UMARS] for current status.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:enso@zhaw.ch Oliver E] || Winterthur, Switzerland || Tiny 2.11 incl. ArduIMU, Kyosho Calmato, UMARS||| 2010 || Many Successful flights. A lot of experience as savety pilot. Experience with pich based speed control (best you can have). No programming skills unfortuanatley. <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:samuelbryner_gmx.ch Samuel B.] || Winterthur, Switzerland || Tiny 2.11, Multiplex Easyglider ||| 2010 || Just starting. No flight so far :/<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:sjwilks_at_gmail.com Simon W.] || Aarau, Switzerland || TWOG with ArduIMU in Jamara Roo, TWOG on a Telink Tempest flying wing, YAPA2 on a Bormatec Maja, Lisa/L on a Droidworx AD-8 HL ||| 2010 || Many successful flights. See [http://sites.google.com/site/paparazziuav/ http://sites.google.com/site/paparazziuav/].<br />
<br />
|- style="background:lightgreen; color:black"<br />
| UK<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:et@onyxnet.co.uk Alan K] || Middlesbrough, England || Tiny 2.11 & MaxStream ||| 2008 || Just starting.<br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:G R|Gareth R]] || Sheffield, UK || Tiny 2.11, video, bunch of helicopters, Multiplex Mentor, Multiplex Funjet, Multiplex Fox, GWS Formosa ||| 2008 || Came 4th in EMAV09 (although won the Golden Balls award for courage in the face of adversity and exceptional partying). Many AUTO2 flights with a camera and XBee868s. Current main airframe is a GWS Formosa (they are so cheap!).<br />
<br />
<br />
|- style="background:lightgreen; color:black"<br />
| Other<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:silas_at_silas.hu SilaS] || Budapest || Tiny 1.3,2.11, Twog 1.0 ||| 2007 || Applied tiny to GWS Estarter, finished long travels in AUTO2. Now transfert it to a Twinstar and working on pairing tiny with FPV. Successfull. Now using it on large gliders and jets.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:hendrix@gmail.gr| Chris Efstathiou] || Piraeus Hellas || tiny 2.11 on a Mpx EasyGlider, TWOG 1.3 on a Boomerang turbine jet, and my newest toy a X8 with a on camera ||| 2008 || The Easyglider is fully operational, still working on the jet which had his first flight with the TWOG at 25/1/2009 <br />
<br />
|- style="background:bisque; color:black"<br />
| [[User:openuas|OpenUAS]] || Amsterdam, The Netherlands || TWOG, Tiny, Lisa/L and various airframes || 2007 || Quite a few AUTO2 flights. Improving airspeed, IMU and strong wind integration<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:sanarlab@yandex.ru Andrew Saenko] || Russia, St-Petersburg || Tiny 1.13, Tiny 2.11, two own hardware designs, 5 kg aerial photo plane, 2.5 kg survelliance uav, Easystar ||| 2007 || Use modified autopilot and GCS in professional tasks, add self desidned IMU<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:chebuzz_at_gmail.com David "Buzz" Carlson] || Cyprus || Tiny 2.11, Lynx EDF & GWS SloStick, 9XTend datalink ||| 2008 || Quite a few AUTO2 flights. Plane currently grounded due to a TX run-in with a 1 year-old. Currently working on getting new TX and completing CBP store setup.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:kostalexis@ece.upatras.gr AneMos-Group] || Patras, Greece || Tiny 2.11, Quadrotor VTOL ||| 2008 || Working on IMU, Trying to implement Constrained Control for the quadrotor trajectory flight<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:VAMK Allan Ojala (VAMK)] || Vaasa, Finland || TWOG, with AC4790 radio and LEA-5H GPS ||| 2009 || Ditched the SIG Kadet. Built a new big plane TaigaCam. Self-build model made out of EPP and a plastic tube.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:alexandru.panait@ral.ro Phineas] || Bucharest, Romania || Tiny2.11 (PPZUAV) ||| November 2009 || Just started to set-up <br />
<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:lukeiron@hotmail.com Luke] || Torino, Italy || TWOG ||| December 2009 || Close to mount the AP on my Mentor <br />
|<br />
<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:helgewal@gmail.com Helge] || Bergen, Norway || TWOG ||| 2009 || First Auto2 flight with Twinstar2 in October 2010 <br />
|}<br />
<br />
===North America===<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
|-<br />
! Name !! Location !! Hardware !! Joined !! Current activities / project status <br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Mcurrie Matthew Currie] || Nanaimo, BC Canada || Tiny 13 v1.1 (Self-built) ||| November 2006 || Funjet + XBee<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:quill_at_u.washington.edu John Burt] [http://paparazzi.enac.fr/wiki/User:John_Burt wiki page]|| Portland, Oregon || Tiny v2.11 + LEA-4H (PPZUAV), Multiplex Cularis/Easystar, 9Xtend modem, T7CAP TX, ground station: EEE PC701 and/or Nokia N810 ||| Jan 2009 || Initial flight tests w/ Easystar in AUTO1 & AUTO2.<br />
<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:ogar0007@umn.edu Pat O'Gara] || St. Paul, MN || Tiny 2.11 and TWOG (PPZUAV) |||Oct. 2008 || Completed and flown FunJet and Minimag in Auto 2. Currently rebuilding MiniMag as an improved development platform. <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:kochesj@gvsu.edu John Koches] || Muskegon, Michigan || Tiny 2.11 (PPZUAV) ||| 2007 || currently flying a 48 inch zagi, 80 inch under construction.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:Stdeguir@gmail.com Steve Deguir] || New York, New York || Tiny2.11+LEA-5H (PPZUAV), XbeePro 2.4, Berg4L, JR FMA ||| Feb 2009 || <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:bmw330i@me.com David Conger] || San Diego (Ramona), California || Tiny1.3 (PPZUAV) ||| Sept 2007 || Flying Wing MAV with onboard video. Test platform for the new 900mhz XBPro 900 RF modems.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:mecevans@gmail.com Michael Evans] || Seaside(Monterey Bay), California || Tiny2.11 (PPZUAV) ||| Feb 2009 ||http://www.rcgroups.com/forums/showthread.php?t=1000937. <br />
<br />
|- style="background:bisque; color:black"<br />
| USU AggieAir Remote Sensing || Logan, UT || TWOG (PPZUAV) ||| January 2009 || Building 72" Flying Wings which will be used for remote sensing. Routine autonomous flight.<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://www.engr.usu.edu/wiki/index.php/OSAM USU OSAM-UAV] || Logan, UT || TWOG (PPZUAV) ||| June 2007 || 2x72" 5x48" 1x60" Flying Wings. Research backyard for AggieAir Remote Sensing. Routine autonomous flight.<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:CSU-FCUAV CSU Fuel Cell UAV] || Fort Collins, Co || Tiny 2.11 + LEA-5H (PPZUAV), 2.4Ghz XBPro ||| Mar 2009 || Maiden flight complete Feb 28. New Airframe in development.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:armz12@gmail.com Armen Gharibans] || La Jolla, California || Tiny2.11 (PPZUAV) ||| March 2009 || UCSD Project with Multiplex Mentor. Completed August 2, 2009. Several Successful Auto2 Flights. A LOT of help from David Conger.<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:EldenC Elden Crom] || Tucson, AZ || Twog 1.0 ||| July 2009 || Multiplex Twinstar, XBee Pro. Several Successful Auto2 Flights. Working toward precise Auto-Takeoff and Auto-Land <br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:jvs84 U of Arizona Autonomous Glider] || Tucson, AZ || None, will use TWOG 1.0 ||| December 2009 || Super Dimona, Aerocomm. No Flight test. Working toward setting waypoints within Paparazzi code <br />
<br />
|- style="background:bisque; color:black"<br />
| [Reegan] || Lubbock, TX || Planning on Tiny 2.11 (PPZUAV), 900mhz XBPro |||Dec. 2009 || Gaining info to begin a collegiate project<br />
<br />
|- style="background:bisque; color:black"<br />
| Team UAV UALR Caleb Tenberge || Little Rock, AR || Using TWOG 1.0 ||| Feb 2010 || Using a Telemaster, we are learning the GCS and building our plane. <br />
<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:changho.nam@asu.edu Arizona State University POLY - Capstone Team: Development of UAV /w surveillance System] || Mesa, AZ || Using TINY 2.1 - 2.4GHz Modem, CCD Camera /w 900 MHz Video Transmitter ||| March 2010 || 4-lbs Flying Wings. We made successful autonomous flights. <br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Scdwyer Stephen Dwyer] || Edmonton, AB, CAN || Nothing Yet ||| Jan 2011 || Obtaining Hardware <br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:muratagenc@yahoo.com Murat A. Genc] || New York, NY || not decided yet ||| May 2011 || just started<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/UAlberta_UASGroup University of Alberta UAS Group] || Edmonton, AB, CAN || TWOG 1.0, Asprin IMU ||| Aug 2011 || Completing tuning flights in Auto 1 on a Senior Telemaster with 26cc gas engine. Working towards a stable platform for research.<br />
<br />
|- style="background:bisque; color:black"<br />
| [mailto:piotr@esden.net Piotr Esden-Tempski] || Santa Cruz, CA || Lisa/L, Lisa/M, Aspirin, Quadshot, Rotorcraft ||| 2009 || Software and Hardware development as well as [http://thequadshot.com The Quadshot]<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://clubs.asua.arizona.edu/~mavclub University of Arizona MAV] || Tucson, AZ || Lisa/M 2.0, Aspirin v2.0, uBlox MAX-6Q, XBee 900 Pro/868LP, Mini-Vertigo ||| 2005 || University of Arizona Micro Air Vehicle Club (competing in IMAVs with Paparazzi since 2003.)<br />
<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Cwozny Chris Wozny] || Nashua, New Hampshire || Lisa/M, Aspirin ||| 2008 || Currently building quadcopter around Lisa/M 2.0 platform.<br />
<br />
|- style="background:bisque; color:black"<br />
| New User || 1 || 2 ||| 3 || 4 <br />
|}<br />
<br />
===Central America===<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
! Name !! Location !! Hardware !! Joined !! Current activities / project status<br />
|- style="background:bisque; color:black"<br />
| [mailto:joschau@comcast.net Joekadet] || David Panama' || Tiny v2.11/LEA-4P, RF Modems XBee Pro 2.4 GHz (PPZUAV). Multiplex Mentor ||| 2008 || Seven flights now. Flights 6 & 7 in Auto2. Now only a matter of fine tuning.<br />
|- style="background:bisque; color:black"<br />
| New User || 1 || 2 ||| 3 || 4 <br />
|}<br />
<br />
===South America===<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
! Name !! Location !! Hardware !! Joined !! Current activities / project status<br />
|- style="background:bisque; color:black"<br />
| [mailto:gustavoviolato@gmail.com Gustavo Violato] || São José dos Campos, Brasil || Tiny v2.11/LEA-4P, Modem XBee Pro 2.4 GHz Swift II ||| 2009 || Flying autonomously and enjoying it. Planning to use the system for flight test data acquisition and aircraft parameter recognition. <br />
|- style="background:bisque; color:black"<br />
| [mailto:agressiva@hotmail.com Eduardo Lavratti] || Porto Alegre - RS, Brasil || TWOG / BOOZ / LISA-M, UBLOX, Xbee900 60mw||| 2011 || Working with geoprocessing - developping new modules and sensors to paparazzi. [http://brquad.blogspot.com ACCENT AERiALS]<br />
|- style="background:bisque; color:black"<br />
| New User || 1 || 2 ||| 3 || 4 <br />
|}<br />
<br />
===Australia===<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
|-<br />
! Name !! Location !! Hardware !! Joined !! Current activities / project status<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:RH1N0 RH1N0] || Brisbane, QLD || TWOG, Multiplex Easystar, PPZGPS, H.264 live digital video, Ubiquiti modems ||| May 2011 || Multiple AUTO2 flights up to 40 min. Currently testing PPZIMU.<br />
|- style="background:bisque; color:black"<br />
| [mailto:todd_soaring@yahoo.com.au Todd Sandercock] || Adelaide, SA || Tiny v2.11, Multiplex Twinjet, 9Xtend modems ||| Jan 2008 || Completed successful flight testing. Now designing new airframe. <br />
|- style="background:bisque; color:black"<br />
| [mailto:reubenb87@gmail.com Reuben Brown]|| Gawler, SA || Tiny v2.11 ||| May 2009 || Getting the autopilot set up <br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Rbdavison Bernard Davison] || Neutral Bay, NSW || Tiny v2.11, Vertical + Horizontal IR sensors, XBee PRO modems, Futaba T6EXAP TX, Futaba R136F RX, Funjet, MacBook laptop ||| August 2008 || Several flights in Auto1<br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Rufus Chris Gough] || Canberra || TWOG v2.11, EZ* || September 09 || not yet airborn <br />
|- style="background:bisque; color:black"<br />
| [http://paparazzi.enac.fr/wiki/User:Adam.A Adam Amos] || Sydney, NSW || TWOG, IMU, BORJET MAJA || March 2010 || see [http://www.rescuerobotics.com.au www.rescuerobotics.com.au] for current status<br />
|}<br />
<br />
===Africa===<br />
{| class="wikitable" style="text-align:center;background:black; color:blue"<br />
! Name !! Location !! Hardware !! Joined !! Current activities / project status<br />
|- style="background:bisque; color:black"<br />
| [mailto:w1_th@yahoo.com W1th] || South Africa KZN || TWOG V1 ,LEA-5H GPS , RF Modems XBee Pro 868 (CheBuzz) ||| July 2009 || Got TWOG,GPS etc interfacing with Laptop and working , Have not done anything to it recently but...Made a website [http://sites.google.com/site/scarfclub/paparazi-uav SCARF Paparazzi-UAV] of my struggle ...<br />
|- style="background:bisque; color:black"<br />
| [mailto:willie.smit@nwu.ac.za Willie Smit] || South Africa NW || Tiny v2.11, LEA-4P GPS, RF Modems XBee Pro ||| April 2010 || We are currently doing test flights. Also doing research on obstacle avoidance.<br />
|- style="background:bisque; color:black"<br />
|}<br />
<br />
==Need help adding your information?==<br />
To have your information added by another paparazzi user, please send me an [http://www.rcgroups.com/forums/showpost.php?p=6575288&postcount=1 EMAIL] at with the <br />
following:<br />
<br />
*Name<br />
*Email<br />
*Location<br />
*Hardware<br />
*Join date<br />
*Current activities / project status<br />
<br />
[[Category:Community]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=GCS&diff=16161GCS2013-10-15T20:42:00Z<p>Mbina: code formatting</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>GCS</categorytree><br />
__TOC__<br />
<br />
Ground Control Station<br />
<br />
{|<br />
|-valign="top"<br />
|__TOC__<br />
|<br />
[[Image:gcs.jpg|frame|left|The Paparazzi Ground Control Station is the heart of the system and the user's primary interaction interface.]] [[Image:GCSParrotardroneandpaparazzi.jpg|right|370px| THe GCS is very flexible in the way you can change the look and add functionality. One only need to change a configuration file. For example, the look when using the configuration GCS setting for Paparazzi Parrot AR Drone 2]] <br />
|}<br />
<br />
= Introduction =<br />
<br />
The [[GCS_Configuration | versatile]] Paparazzi Ground Control Station is an operator control unit ground control software for unmanned aircraft. It allows to visualize and control an unmanned aircraft during development and operation, both indoors and outdoors. With a flexible software architecture it supports multiple UA types/autopilot projects. The purpose of the '''G'''round '''C'''ontrol '''S'''tation is real-time monitoring of an UA.<br />
<br />
= Features = <br />
<br />
The Paparazzi GroundControlStation is a feature-rich application with fully customizable views, each containing a collection of the most useful interface components for a particular purpose.<br />
<br />
* Simultaneous flying '''multi UAS''' support<br />
* Multi-system support (multiple procotols, multiple autopilots/projects) by writing a IVY Plugin<br />
* 2D Map capable of displaying Google Satellite, OpenStreetMaps Images and Microsoft Satellite Maps<br />
* Mission planning <br />
* '''Realtime movable waypoints'''<br />
* Realtime flightplan adjustments if needed<br />
* System status overview<br />
* '''Realtime''' Airframe '''in Air tuning''' and calibration<br />
* Supports rotary and fixed-wing e.g. Airplanes, helicopters, coaxial and quadrotors<br />
* Definable '''Hotkeys''' for quick simple in the field control<br />
* '''Voice''' status output<br />
* Full freely '''configurable GUI layout'''<br />
<br />
= Configuration Options =<br />
The [[GCS_Configuration|GCS is highly configurable]] and modules can be added, removed, or resized as needed. In addition to this the GCS has many '''command line options''' which can be used when launching the GCS<br />
<br><br />
See the [[GCS_Configuration|'''GCS configuration''']] page for details.<br />
<br />
= Simulation of Flightplan =<br />
Your flight plans can, and should, always be tested prior to a real autonomous flight. Testing end adjusting is possible from within the same GCS. See the [[Simulation|simulation]] page for details.<br />
<br />
= Options =<br />
<br />
== Strips ==<br />
<br />
Each A/C has an associated strip that displays information about the A/C and provides buttons for common commands. The strip has the following layout by default. Paparazzi GCS is very flexible and the strip can have more or less buttons according to your configuration.<br />
<br />
[[Image:strip.png|Aircraft information strip]]<br />
<br />
=== Displayed information ===<br />
<br />
* Left: Flight information<br />
* Center: Navigation information<br />
* Right: Navigation control<br />
* Bottom: Custom navigation and setting buttons<br />
<br />
=== Actions ===<br />
<br />
Every change in the waypoints (position or/and [[Altitude_definitions|altitude]]) must be confirmed with the dialog box that appears after the move. A modified waypoint remains animated on the map and the GCS continues to re-send the move request until confirmation is received from the aircraft.<br />
When clicked, the '''Mark''' button places a mark on the map at the A/C position. A snapshot from the video plugin is associated to this mark and can be viewed by moving the mouse over the mark. A click on the mark opens a dialog box allowing to delete the mark.<br />
A click on the colored bar at the top selects the corresponding A/C in the [[#notebook|Notebook]].<br />
<br />
== Map ==<br />
<br />
[[Image:GCSmap.png|thumb|400px|Sample map showing the various features]]<br />
<br />
=== Display ===<br />
<br />
The map display contains the following information:<br />
* The A/C track: it can be erased ''via'' the ''Clear track'' option from the A/C menu.<br />
* The A/C label (in clear blue near the A/C) contains the name of the A/C (Plaster), it's altitude (218 m) and it's ground speed (11.99 m/s). This option default is off. It can be activated with the ''A/C label'' option from the A/C menu.<br />
* The carrot (the orange triangle). This is the point the A/C is following during autonomous navigation.<br />
* The waypoints defined in the flight plan (blue diamonds).<br />
* The intended trajectory is shown as a green line, in this example a circle around waypoint 2.<br />
* The default background is black. [[Maps|Maps]] can be loaded to provide navigation reference.<br />
* The camera footprint (the grey polygon) is representative of the swath of land currently seen by the onboard camera. This option default is off. It can be activated with the ''Cam footprint'' option from the A/C menu. see also [[Pan_Tilt_Camera]]<br />
* The WGS84 coordinates of the mouse cursor are displayed at the top right hand corner (43.462019 1.270474).<br />
* A UTM kilometric grid can be added to the background ''via'' the ''UTM grid'' option from the ''Nav'' menu.<br />
* The [[Altitude_definitions|height Above Ground Level (AGL)]] displays the ground altitude of the mouse near the geographic position in the top right hand corner. The [http://srtm.usgs.gov/ SRTM] option must be enabled in the ''Nav'' menu and the height data must be downloaded as described [[Maps#Height_Data|here]].<br />
<br />
=== Navigation ===<br />
<br />
You can pan/zoom the map using the following:<br />
* Pan with the blue arrows on the map or use the arrow keys on the keyboard<br />
* zoom in/out with the mouse scroll wheel, the page up/page down buttons or the small up/down buttons at the top right hand corner where the zoom factor is displayed<br />
* fit the map to the window, in order to see all the waypoints and A/C, with the '''f''' key or the ''Fit'' option from the ''Nav'' menu;<br />
* center the map on an A/C with the ''Center A/C'' option from the corresponding A/C menu.<br />
<br />
=== Map Photo Tiles ===<br />
The default black background can be automatically filled with calibrated satellite photo tiles from Openstreetmaps, Google Maps or MS Maps. Note: If you download too much map data from Google into the GCS you may be blocked for downloading further map data for 24 hours. With OpenStreetmaps data and MS data there is no such limitation.<br />
<br><br />
See the [[Maps]] page for more info.<br />
<br />
=== Waypoint Editing ===<br />
<br />
The properties of any waypoint in the currently loaded flight plan can be modified by two methods:<br />
* Drag and drop the waypoints to a new location (a confirmation dialog will appear).<br />
* A single left click on a waypoint opens a dialog box where you can edit the waypoint's coordinates and altitude.<br />
<br />
Waypoint edits are sent to the aircraft immediately upon confirmation in the dialog box. The GCS will re-send the data and the waypoint will animate until the aircraft confirms receipt of the move request. New waypoints cannot be added during flight.<br />
<br><br />
See the [[Flight_Plans|Flight plans]] and [[Flight_Plan_Editor|Flight Plan Editor]] pages for more information on waypoints.<br />
<br />
== Notebook ==<br />
<br />
The notebook frame contains one page for each running aircraft. Each aircraft page is itself divided into subpages displaying telemetry data and giving access to the autopilot tuning parameters.<br />
<br />
Note that the colored tabs at the top of this section allow the user to select among multiple aircraft.<br />
<br />
=== Flight Plan ===<br />
<br />
<center><br />
[[Image:GCSfp.png|Flight plan tree]]<br />
</center><br />
<br />
The full tree of the flight plan is given in this page. The current block and the current stage are highlighted. A double-click on a block allows the operator to immediately switch navigation to this block.<br />
<br><br />
See the [[Flight_Plans|Flight plans]] and [[Flight_Plan_Editor|Flight Plan Editor]] pages for more information on flight plans.<br />
<br />
=== Settings ===<br />
<center><br />
[[Image:GCSsettings.png|Settings tab]]<br />
</center><br />
The setting page allows the operator to change variable values during flight. The layout of the page is generated from the <tt>dl_settings</tt> section of the settings.xml file, one tab is associated to every section and sub-section.<br />
<br />
On each line is displayed (from left to right), the name of the variable, its current value (periodically sent by the A/C), a slider or radio buttons for user input, and commit/undo buttons. Also note, clicking on the current value will send a request to obtain the current value from the aircraft.<br />
<br><br />
See the [[Telemetry#Settings|Telemetry]] page for more information on settings.<br />
<br><br />
The save button of this tab opens the following popup which proposes to the user to save the current values in the airframe file (according to the <tt>param</tt> attribute in the [[Telemetry#Settings|setttings]] configuration file). The values of the checked rows will be saved in the airframe file (or any other file) for further use. Units (e.g. deg or rad) are taken into account. '''It is recommended to backup the airframe file before overwriting it with this utility''' (even if time-stamped copy of the airframe file is actually automatically done).<br />
<br />
Symetrically, the Upload button of this dialog button will send all the checked values of the airframe file to the live aircraft.<br />
<center><br />
[[Image:Save settings.png|Settings tab]]<br />
</center><br />
<br />
=== PFD ===<br />
<br />
[[Image:GCSpfd.png|Primary Flight Display]]<br />
<br />
The Primary Flight Display contains an artificial horizon and two scales displaying the current ground speed (left side) and the altitude (right side). Minimum and maximum speeds are shown under and above the speed scale. A click on the scale resets these values to the current speed value.<br />
<br />
=== GPS, Infrared, Wind ===<br />
<br />
The '''GPS''' page gives the list of satellites tracked by the receiver and their respective signal strengths in dB.<br />
(35 is low, 45 is excellent) and if they are used to compute the fix (green: used, red:not used). This page may help to tune the position of the receiver on the aircraft relatively to other components (e.g. datalink and video transmitters).<br />
<br />
The '''Infrared''' page is only used for aircraft not equipped with the vertical infrared sensor. This page reports the required pre-flight calibration value as well as the evolution of the in-flight calibration correction factor (from hybridization with the GPS information).<br />
<br />
The '''Misc''' page displays the estimated wind velocity computed by the ground station during flight and relayed back to the aircraft. Wind velocity is estimated by vector addition of the GPS-measured ground speed in many different directions during level flight. This computation may soon be performed by the autopilot instead of the ground station.<br />
<br />
== Video Plugin ==<br />
<br />
The <tt>-mplayer</tt> option of GCS allows the user to display a video stream in this window. The video window can also be exchanged with the map by clicking anywhere inside the frame or from the menu.<br />
Use the following line in your [[Control_panel.xml|control panel]] to enable the video window.<br />
<tt>path_to_ground_segment/cockpit/gcs -mplayer rtsp://localhost:7070/video -layout appropriate_layout.xml</tt><br />
Note that a <tt>plugin</tt> widget must be specified in the used layout:<br />
<source lang="xml"> <widget size="300" name="plugin"/> </source><br />
A useful example of how to configure the GCS to show video from a USB DVB-T tuner with composite input follows:<br />
<br />
If you have an Avermedia DVB-T usb tuner like the Aver-Tv Hybrid Volar HX (Avermedia finally released Ubuntu Linux drivers)<br />
then in order to use the usb tuner as video input to the GCS you have to complete the following steps:<br />
<br />
First download and install the drivers and check that the Usb tuner works well by connecting a video signal to the composite input<br />
and then opening a console window and typing: <br />
<br />
'''mplayer tv:// -tv driver=v4l2:width=320:height=240:norm=NTSC:input=1:device=/dev/video1:noaudio'''<br />
<br />
Remember to change the "device=/dev/video1" in the above line with whatever your new usb tuner is registered with (if needed).<br />
Type "dmesg" in a console immediately after you connect the usb tuner and you should see a line stating the video device your usb tuner got registered with.<br />
If it says video0 change "device=/dev/video1" with "device=/dev/video0"<br />
Mine is registered as "video1" because "video0" is the built in laptop camera.<br />
If everything is ok then a blue or similar LED on the usb tuner dongle should light up indicating that the tuner driver is loaded<br />
and you should be able to watch the video on the pc screen (no audio yet).<br />
Now close the console and remove the Usb tuner as it is time to configure the control_panel.xml file by editing the GCS command line.<br />
Locate the line in the "control_panel.xml" file, usually located in "/Your Paparazzi directory/conf/" (mine is in "/paparazzi/conf/"),<br />
that starts with "<program name="GCS" command="sw/ground_segment/cockpit/gcs......".<br />
For example let's say that the complete line looks like this: <br />
<br />
<source lang="xml"> <program name="GCS" command="sw/ground_segment/cockpit/gcs -layout horizontal.xml"> </source><br />
<br />
Now add the below line at the end (before the quotes) of the original line:<br />
<br />
'''-mplayer 'tv:// -tv driver=v4l2:width=320:height=240:norm=NTSC:input=1:device=/dev/video1:alsa:adevice=hw.2,0:amode=1:audiorate=48000:forceaudio:volume=100:immediatemode=0''''<br />
<br />
The original line should look now like this:<br />
<br />
<program name="GCS" command="sw/ground_segment/cockpit/gcs -layout horizontal.xml -mplayer <br />
'tv:// -tv driver=v4l2:width=320:height=240:norm=NTSC:input=1:device=/dev/video1:alsa:adevice=hw.2,0:amode=1:audiorate=48000:forceaudio:volume=100:immediatemode=0'"> <br />
<br />
The above line is one complete and uninterrupted line but it is just too long to show it in one line here.<br />
Please remember to change the "NTSC" with "PAL" if you do not use the NTSC video system (if your airborne camera is PAL for example). <br />
This will load the mplayer, select the composite video input of the tuner and enable the sound input.<br />
Read the mplayer documentation so you can tweak the resolution etc. later to suit your particular setup.<br />
The resolution above is set to 320x240 here but you can set it to 640x480 by replacing the numbers in the command line above.<br />
<br />
Finally you have to add the plugin widget to your GCS layout configuration file.<br />
If you noticed the GCS command line in the "control_panel.xml" file, it has a part that reads "-layout horizontal.xml" <br />
so our layout configuration file is the "horizontal.xml" which is located always in "/Your Paparazzi directory/conf/gcs/" <br />
(mine is in "/paparazzi/conf/gcs/").<br />
Open the file and add or uncomment the below line (in "horizontal.xml" the plugin widget is there but commented out):<br />
<br />
<source lang="xml"><widget NAME="plugin" SIZE="300"/> </source><br />
<br />
Now the file should look like this:<br />
<br />
<source lang="xml"><br />
<rows><br />
<widget size="500" name="map2d"/><br />
<columns><br />
<rows size="375"><br />
<widget size="200" name="strips"/><br />
</rows><br />
<widget size="400" name="aircraft"/><br />
<widget name="alarms"/> <br />
<widget NAME="plugin" SIZE="300"/> <br />
</columns><br />
</rows><br />
</source><br />
<br />
That's it, Enjoy!<br />
<br />
Tested in Ubuntu 10.04 LTS but probably the same method should work fine on different versions too.<br />
<br />
See this [http://www.youtube.com/watch?v=7OCcMA4vluM screen capture] as an example of the resulting GCS (Y-UAV).<br />
<br />
<br />
The <tt>-plugin</tt> option is another way to use the plugin widget: the X subwindow id is given to the provided command:<br />
<tt>path_to_ground_segment/cockpit/gcs -plugin "mplayer video_stream -wid " -layout appropriate_layout.xml</tt><br />
<tt>path_to_ground_segment/cockpit/gcs -plugin "cvlc video_stream --drawable-xid=" -layout appropriate_layout.xml</tt><br />
The <tt>--vout-event=3</tt> option can be used for vlc to disable mouse and keyboard events handling<br />
<br />
== Altitude graph widget ==<br />
<center><br />
[[Image:altgraph.png|400px|The GCS with the altitude graph]]<br />
</center><br />
<br />
An altitude graph can be displayed in the GCS by adding the widget ''altgraph'' in the layout configuration (See the [[GCS_Configuration|GCS configuration]] page). An example is provided in conf/gcs/alt.xml. To use this layout add -layout alt.xml to the /conf/control_panel.xml file. This type of layout is more suited to a multi UAV set up. The Papget ruler is a much less intrusive and better tool when you are only flying a single aircraft.<br />
<br />
==Papgets==<br />
Graphical objects can be added to 2D maps: text, rule, gauge, buttons, .... These objects are named ''papgets''. The following snapshot<br />
shows an example with buttons (left side), gauges (lower left corner), text (upper right corner) and ruler (right side). This example<br />
has been produced with a layout file provided in the distribution:<br />
<br />
.../gcs -layout papgets.xml <br />
<br />
<center><br />
[[Image:papgets.png|516px|A 2D map augmented with papgets]]<br />
</center><br />
<br />
===Telemetry data report===<br />
The easiest way to create a papget displaying telemetry data is to drag&drop a message field from the Messages window onto the 2D map of the GCS. The default rendering is then a string of text. Clicking on it allows the user to change its type (currently text, ruler or gauge) and some of its attributes (color, size, range for a gauge, format for a text ...). A papget can be moved by simply dragging it.<br />
<br />
<center><br />
[[Image:papget_editor.png|Main characteristics of a papget can be dynamically edited]]<br />
</center><br />
<br />
Papgets can be saved in the layout of the GCS (from the Nav menu). The description is saved in an XML file (in <tt>conf/gcs/</tt> folder) which can be manually edited:<br />
<br />
<source lang="xml"><br />
<papget type="message_field" display="gauge" x="47" y="414"><br />
<property name="field" value="BAT:voltage"/><br />
<property name="scale" value="0.1"/><br />
<property name="min" value="0."/><br />
<property name="max" value="15."/><br />
<property name="size" value="50."/><br />
<property name="text" value="Bat(V)"/><br />
</papget><br />
</source><br />
<br />
The file is used later by giving it to the gcs process:<br />
<br />
<pre><br />
.../gcs -layout my_fancy_papgets.xml<br />
</pre><br />
<br />
===Buttons===<br />
In the same way, user buttons from the strip can be dragged&dropped on the 2D map. However, they currently cannot be directly edited, and<br />
attributes changes have to be done in the XML file. Two types of button are provided to jump to a block or to set a value:<br />
<source lang="xml"><br />
<papget type="goto_block" display="button" x="10" y="300"><br />
<property name="block_name" value="Standby"/><br />
<property name="icon" value="home.png"/><br />
</papget><br />
<papget type="variable_setting" display="button" x="10" y="250"><br />
<property name="variable" value="launch"/><br />
<property name="value" value="1."/><br />
<property name="icon" value="launch.png"/><br />
</papget><br />
</source><br />
<br />
===Video on Papget===<br />
A video stream can be rendered in a <tt>video_plugin</tt> papget, using the ''mplayer'' player:<br />
<source lang="xml"><br />
<papget type="video_plugin" display="mplayer" x="300" y="250"><br />
<property name="video_feed" value="my video source"/><br />
<property name="width" VALUE="320"/><br />
<property name="height" VALUE="240"/><br />
</papget><br />
</source><br />
or any video player which takes in option the X window id, here for example ''VLC'':<br />
<source lang="xml"><br />
<papget type="video_plugin" display="plugin" x="300" y="250"><br />
<property name="command" value="cvlc video_source --drawable-xid="/><br />
<property NAME="width" VALUE="320"/><br />
<property NAME="height" VALUE="240"/><br />
</papget><br />
</source><br />
<br />
===Papget Development===<br />
Graphical appearence of papgets is defined in <tt>sw/lib/ocaml/papget_renderer.ml</tt>. A renderer must implement the Papget_renderer.t class type interface (<tt>canvas_text</tt> is probably the simpler example) and listed in the <tt>renderers</tt> list to be available<br />
in the edit popup box.<br />
<br />
The XML configuration is parsed in <tt>sw/ground_segment/cockpit/papgets.ml</tt>: a new created papget identifier must listed here.<br />
<br />
== Alarms ==<br />
<br />
The alarm window displays a list of recent errors such as:<br />
* Low battery warning<br />
* Low altitude warning<br />
* Autopilot mode changes (i.e. Manual, Auto2)<br />
* Flight plan block changes<br />
<br />
These alarms can be provided via the speaker using the [[speech]] function.<br />
<br />
=Related Links=<br />
<br />
* [[GettingTheGCSRunningonAGumstixBoard | Getting the GCS running on a Gumstix board]]<br />
* [[RaspberryPi | Getting the GCS running on a Raspberry Pi board]]<br />
<br />
[[Category:Software]] [[Category:GCS]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Radio_Control&diff=16126Radio Control2013-10-08T09:52:24Z<p>Mbina: formatting</p>
<hr />
<div>== PPM Radio Configuration ==<br />
<br />
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 />
<span style="color:#FF0000">'''CAUTION!'''</span> <b>This is only used for PPM transmitters so it does not apply to DSM/DSM2/FASST/FHSS or other 2.4Ghz radios.</b><br />
<br />
The contents are an '''ordered''' sequence of elements describing each channel with its name and its range:<br />
<br />
<tt><source lang="xml"><!DOCTYPE radio SYSTEM "radio.dtd"><br />
<radio name="cockpitMM" data_min="900" data_max="2100" sync_min ="5000" sync_max ="15000" pulse_type="POSITIVE"><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></source></tt><br />
<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 />
<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 />
* <tt>pulse_type</tt>: the polarity of the PPM pulse. Can be either <tt>POSITIVE</tt> (FUTABA, Hitec, Multiplex etc) or <tt>NEGATIVE</tt> (JR, Graupner etc.).<br/>With <tt>POSITIVE</tt> it will trigger on the rising flank to measure the time of the positive pulse, with <tt>NEGATIVE</tt> on the falling flank (for a negative pulse width).<br />
<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 />
'''Wrong attributes of the "radio" element will prevent the decoder to recognize any PPM frame; same for a wrong number or channels.'''<br />
<br />
=== Number of channels ===<br />
<br />
Note that the number of channels in your radio file <b>must exactly match</b> the number of channels in the ppm sum signal the autopilot receives.<br><br />
Also the ''function'' names must be unique.<br />
<br />
* in case of analog 35MHz receivers it is the RC - TRANSMITTER that makes the pulse train (receiver only does RF part) <br />
** radio file depends on transmitter, you could swap to another receiver (and e.g. you can use a 4channel receiver to receive 9 pulses :-) )<br />
* in case of digital receivers it is not the transmitter but the receiver that makes the pulses<br />
** e.g. Futaba Fasst 6017: you can use any compatible transmitter without need to change the radio file<br />
* in case of an encoder it is the encoder that makes the summed pulse<br />
** if the encoder software makes 8 pulses, even with a 5 channel RC connected paparazzi will get 8: so the radio file should read 8<br />
<br />
This means if your transmitter sends for example a PPM18 (Graupner/JR) signal you have nine (9) different servo channels. Even if you use a receiver with less channels you must set up <b>all</b> transmitting servos, even if you do not use them then you must use "bogus switches" related to functions. For example a six (6) servo channels out receiver with five (5) functions used in combination with a nine (9) servo channels transmitter would need four (4) bogus entries. (5 + 4 = 9)<br />
<br />
<source lang="xml"><br />
...<br />
<channel ctl="NoneA" function="NOTUSEDA" min="1100" neutral="1500" max="1900" average="0"/><br />
<channel ctl="NoneB" function="NOTUSEDB" min="1100" neutral="1500" max="1900" average="0"/><br />
<channel ctl="NoneC" function="NOTUSEDC" min="1100" neutral="1500" max="1900" average="0"/><br />
<channel ctl="NoneD" function="NOTUSEDD" min="1100" neutral="1500" max="1900" average="0"/><br />
...<br />
</source><br />
<br />
<br />
=== Averaging ===<br />
<br />
The <tt>average</tt> attribute must be set to '''1..x''' 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. Note that averaging a channel gives the output an additional small delay.<br />
<br />
== Direction ==<br />
<br />
The following signs have been used in the radio configuration files distributed in <tt>conf/radios</tt>:<br />
<br />
* '''ROLL''': The <tt>min</tt> attribute value stands for the right position of the stick (turning right)<br />
* '''PITCH''': The <tt>max</tt> attribute value stands for the up position of the stick (pitching up)<br />
<br />
''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''<br />
* '''ROLL''': The <tt>max</tt> attribute value stands for the right position of the roll stick (banking right)<br />
* '''PITCH''': The <tt>max</tt> attribute value stands for the "up" position of the pitch stick pulled towards you (pitching up)<br />
* '''YAW''': The <tt>max</tt> attribute value stands for the right position of the yaw stick (yawing clock-wise)<br />
<br />
=== Practical test ===<br />
In the RC message:<br />
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to -MAX_PPRZ (-9600) in the ROLL channel<br />
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel<br />
<br />
''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''<br />
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to MAX_PPRZ (9600) in the ROLL channel<br />
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel<br />
* When the YAW stick is pulled to the right (aircraft yawing clock-wise), you should see a value close to MAX_PPRZ (9600) in the YAW channel<br />
<br />
This works with all kind of radios (PPM, USB, 2.4GHz)<br />
<br />
== Example ==<br />
<br />
Below you find an example of a radio file.<br />
<br />
<br />
<source lang="xml"><br />
<?xml version="1.0"?><br />
<br />
<!--<br />
-- Attributes of root (Radio) tag :<br />
-- name: name of RC<br />
-- min: min width of a pulse to be considered as a data pulse<br />
-- max: max width of a pulse to be considered as a data pulse<br />
-- sync: min width of a pulse to be considered as a synchro pulse<br />
-- min, max and sync are expressed in micro-seconds<br />
--><br />
<br />
<!--<br />
-- Attributes of channel tag :<br />
-- ctl: name of the command on the transmitter - only for displaying<br />
-- function: logical command<br />
-- average: (boolean) channel filtered through several frames (for discrete commands)<br />
-- min: minimum pulse length (micro-seconds)<br />
-- max: maximum pulse length (micro-seconds)<br />
-- neutral: neutral pulse length (micro-seconds)<br />
Note: a command may be reversed by exchanging min and max values<br />
--><br />
<br />
<radio name="GraupnerMC20" data_min="950" data_max="2150" sync_min="5000" sync_max="15000" pulse_type="NEGATIVE"><br />
<channel ctl="A" function="THROTTLE" min="1100" neutral="1100" max="1900" average="0"/> <!-- left stick up/down --><br />
<channel ctl="B" function="ROLL" min="1100" neutral="1500" max="1900" average="0"/> <!-- right stick left/right --><br />
<channel ctl="C" function="PITCH" min="1900" neutral="1500" max="1100" average="0"/> <!-- right stick up/down --><br />
<channel ctl="D" function="YAW" min="1100" neutral="1500" max="1900" average="0"/> <!-- left stick left/right--><br />
<channel ctl="E" function="MODE" min="1100" neutral="1500" max="1900" average="1"/> <!-- left middle 3-pos switch --><br />
<channel ctl="F" function="GAIN1" min="1100" neutral="1500" max="1900" average="0"/> <!-- left slider prop channel --><br />
<channel ctl="G" function="GAIN2" min="1100" neutral="1500" max="1900" average="0"/> <!-- right slider prop channel --><br />
<channel ctl="H" function="SWITCH1" min="1100" neutral="1500" max="1900" average="1"/> <!-- switch (channel 8) --><br />
<channel ctl="I" function="UNUSED" min="1100" neutral="1500" max="1900" average="1"/> <!-- channel 9 is transmitted but cannot be controlled --><br />
</radio><br />
</source><br />
<br />
<br />
== PPM input to output chain ==<br />
The chain from ppm input to servo output has intermediate steps and roughly looks like this:<br />
<br />
ppm input --(radio.xml)--> ppm_pulses[] --(radio.xml)--> radio_control.values[] --([[Fixedwing_Configuration#Manual|rc_commands]])--> commands[] --([[Fixedwing_Configuration#Servos|command_laws,servos]])--> actuators_pwm_values[] ppm out<br />
<br />
Written in parenthesis is where you configure how to transform one value into the other.<br />
<br />
So in a simple case without fancy mixing, e.g. looking at the roll command / aileron servo while in MANUAL mode:<br />
#PPM sum signal is read and split into channels as specified in your radio xml file.<br/>It does some sanity checking on the pulse length and frame lenght according to the top attributes in that file.<br/>This is written to the ppm_pulses array, where you now have the length of the pulse in system ticks.<br />
#Now these get converted to radio_control.values array according to the channels in your radio xml file.<br/>They get scaled to MAX_PPRZ (9600), meaning what you specified as max is 9600, neutral is 0, etc.<br/>radio_control.values[RADIO_ROLL] now has the value 9600 if the pulse width of that channels was "max"<br />
#Mapping of RC commands to the actual commands as specified in rc_commands section.<br/>In your case simply copy radio_control.values[RADIO_ROLL] to commands[COMMAND_ROLL]<br />
#Applying command_laws (mixing) to get the commands for each servo.<br/>Again just copying in your case...<br />
#Scaling from commands with MAX_PPRZ scale to the actual pwm output signal according to the servos section.<br />
<br />
== Measuring the PPM time values ==<br />
<br />
[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|R/C receiver timing diagram]]<br />
<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.<br />
<br />
With the default telemetry configuration file (<tt>conf/telemetry/default_fixedwing.xml</tt>), this message is '''not''' sent in the '''default''' fbw telemetry mode (numbered 0).<br />
<br />
There are two ways to enable this message:<br />
* Use the settings mechanism to change the FBW telemetry mode while the autopilot is already running:<br/>In the GCS: Settings -> telemetry -> tele_FBW -> set to debug (1)<br />
* This mode can be permanently changed to '''debug''' (numbered 1) in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant in your firmware section: <br />
<source lang="xml"><define name="TELEMETRY_MODE_FBW" value="1"/></source><br />
<br />
'''Since "v3.9" the values in the PPM message are in µs.'''<br />
<br />
Before "v3.9" the time unit used in this '''PPM''' message was 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/arch/lpc21/mcu_periph/sys_time_arch.h</tt>) !!!)<br />
<br />
== Tips ==<br />
<br />
If one has a good servo tester the output values at the receiver side can be measured<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Sensors/GPS&diff=16125Sensors/GPS2013-10-08T09:48:27Z<p>Mbina: formatting</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Sensors</categorytree><br />
<div style="float:left; clear:left; margin-right:2ex; padding: 0.7ex;">__TOC__</div><br />
<br />
[[Image:U-blox_color_warm_60.gif|100px]]<br />
<br />
The recommended GPS' for Paparazzi autopilots from the popular [http://www.u-blox.com u-blox] brand of receivers.<br />
<br />
*Features:<br />
**Small size<br />
**Excellent performance<br />
**up to 10Hz update rate<br />
**large amount of different modules<br />
<br />
The '''[[Tiny]]''' series features an onboard LEA series GPS receiver and patch antenna, while most other boards boards require an external receiver+antenna such as the [[#Paparazzi_Stand-alone_GPS_Receivers|Paparazzi GPS]] or [[#u-Blox_SAM-LS_GPS_Smart_Antenna|SAM-LS]]. Please note that the receivers must be configured (prior to use with the autopilot) as indicated below. Both modules have proven reliable and robust. <br />
<br />
{|align = center<br />
|-<br />
|[[Image:Lea big.jpg|200px|thumb|center|u-blox LEA GPS Receiver]]<br />
|[[Image:Ublox_SAM-LS.jpg|200px|thumb|center|u-Blox SAM-LS GPS receiver (w/built-in Smart Antenna)]]<br />
|[[Image:UBlox_LEA-6H_Sarantel_Helix_s.jpg|200px|thumb|center|u-Blox LEA-6H GPS receiver with Sarantel Helix Antenna]]<br />
|}<br />
<br />
'''Note:''' The proprietary UBX protocol is used as it offers more information and efficiency than the universal NMEA protocol. The protocol is parsed in <tt>sw/airborne/subsystems/gps/gps_ubx.c</tt>.<br />
<br />
==GPS Receivers==<br />
<br />
===u-Blox LEA Series Receivers===<br />
<!-- [[Image:Lea big.jpg|100px|thumb|right|u-blox LEA]] --><br />
[[Image:Lea5htiny13.jpg|thumb|left|250px|LEA-5H installed on the Tiny]]<br />
The '''[[Lisa]]''' series, '''[[Twog_v1|TWOG]]''', '''[[Classix]]''' and '''[[Previous_Autopilots|AVR-based]]''' boards require an external GPS module and antenna. The '''[[Tiny]]''' features an integrated receiver and antenna. Either type is designed for [http://www.u-blox.com/ u-blox] 4, 5 and 6 series GPS receivers and the proprietary UBX binary protocol. An external battery or capacitor is typically used to enable the GPS to retain data while powered off for significantly faster signal re-aquisition. Any of the LEA-4, LEA-5 and LEA-6 series receivers can be used including the less expensive LEA-4A, 4S, 5A and 5S and similar low cost 6-series models as the special boot configuration code required for these models is already written as a [[Module/GPS_UBlox_UCenter|module]].<br />
<br />
<source lang="xml"><br />
<!-- autobaud - runtime configuration of - ROM-only modules: use ucenter-module to configure your UBlox with no cable nor windows u-center --><br />
<load name="gps_ubx_ucenter.xml" /><br />
</source><br />
<br />
*4Hz Position update rate<br />
*Supports active or passive antennas<br />
*Supports [http://en.wikipedia.org/wiki/DGPS DGPS], [http://en.wikipedia.org/wiki/WAAS WAAS], [http://en.wikipedia.org/wiki/EGNOS EGNOS], and [http://en.wikipedia.org/wiki/MSAS MSAS]<br />
*Low position noise figure<br />
<br />
<br style="clear:both"><br />
<br />
===Paparazzi Stand-alone GPS Receivers===<br />
<gallery><br />
Image:Ppzgps13med01.jpg|Top<br />
Image:Ppzgps13_lrg_02.jpg|Bottom<br />
</gallery><br />
<p>Paparazzi source provides a design for an external GPS board. An external GPS board is required for Lisa, TWOG and Classix Autopilot board.<br />
Programming it is similar to the Tiny2.11 GPS configuration. If you build your own you will want to upload the latest u-blox firmware before you configure. See [[Get Hardware]] for sources of assembled boards.</p><br />
<p><br />
The Paparazzi design in https://github.com/paparazzi/paparazzi-hardware/tree/master/sensors/gps/gps_13. The board is very small and light as it has only the components required. It is powered from the 5v line on the "downloads" connector of a TWOG. Also note it is a 4-layer PCB that means better noise resistance. The board has pins for USB connection but requires a different cable and a solder jumper to be move from the ground (default) to 3.3v input to enable the USB port on the module. <br />
</p><br />
<p><br />
[http://paparazzi.enac.fr/wiki_images/Gps_13_BOM.xls V1 BOM.xls]<br><br />
[http://paparazzi.enac.fr/wiki_images/TinygpsBOM.txt Eagle Parts List Output.txt]<br><br />
See [[Get_Hardware|Get Hardware]] page for suppliers.<br />
</p><br />
==== Wiring Diagram ====<br />
<br />
{|align = none<br />
|-<br />
|[[Image:TWOG to GPS.jpg|200px|thumb|center|TWOG to Standalone GPS Cable Schematic]]<br />
|[[Image:gps13v09FTDIcable.jpg|200px|thumb|center|GPS13 v0.9 Ucenter cable (ftdi)]]<br />
|[[Image:booz gps.jpg|200px|thumb|center|BoozGPS (quadrotor gps V1.1 2009/5) Ucenter cable (ftdi)]]<br />
|}<br />
<br />
===3rd Party u-blox Reference Design Boards===<br />
<p><br />
[[Image:LEA5HExternalModulePinout.jpg|thumb|left|LEA-5H Full Board Pinout]]<br />
The only other GPS board in use seems to be u-blox reference designs or similar to it. They have LEA-4H, LEA-5H and LEA-6H (typically) and several interfaces. Often a larger antenna as well. <br />
</p><br />
<p><br />
The board in the photo is a [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Receiver-Boards.asp RF DESIGN] LEA-5H-SMART. <br />
</p><br />
<p><br />
The jumpers adjacent to the TTL interface connectors need to be closed with low value resistors for paparazzi uart port use. Also a [http://nz.element14.com/jsp/search/productdetail.jsp?SKU=1514218 battery] has to be added with an appropriate charging resistor to enable RTC functionality.<br />
</p> <br />
<br />
<br style="clear:both;" /><br />
<br />
===NAVILOCK NL-507ETTL===<br />
[[Image:Navilock NL-507ETTL.jpg|thumb|left|NAVILOCK NL-507TTL]]<br />
The NAVILOCK NL-507TTL u-blox TTL Modul 60416 features an LEA-4 series receiver and 25mm patch antenna on a 30mm x 30mm board.<br />
* Datasheet: [http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481 http://www.navilock.de/download/Dokumente_SLASH_Sonstiges/60415_-_Datenblatt_u-blox_GPS_Module/481]<br />
* Purchase: Available for 28€ at [http://www.amazon.de/Navilock-NL-507TTL-u-blox-TTL-Modul/dp/B0011E6VQG www.amazon.de]<br />
<br style="clear:both;" /><br />
<br />
===SPK GS406 (Discontinued)===<br />
[[Image:GS406.jpg|thumb|left|SPK GS406 with LEA-5]]<br />
[http://www.sparkfun.com/commerce/product_info.php?products_id=8889 Sparkfun] sells a nice small module featuring the newer 5-series receiver (6-series in the GS407) and the highly rated Sarantel antenna for about $90. The design is based around the active version of the Sarantel instead of the more appropriate passive model and there's some potentially tricky soldering involved to get around the ribbon cable but the price is great for this hardware.<br />
<br />
[http://store.diydrones.com/ProductDetails.asp?ProductCode=BR-0008-01 DIYDrones] has build a adapter board for this GPS module. It looks like a great solution to use this GPS module with Paparazzi.<br />
<br style="clear:both;"/><br />
<br />
===SPK GS407===<br />
[[Image:GS407.jpg|thumb|left|SPK GS407]]<br />
[https://www.sparkfun.com/products/11466 This] is the model Sparkfun recommends as a replacement for the old GS406. It's essentially the same, but uses the newer 6-series receiver, and is not using a ribbon cable as an interface. Unfortunately, it still uses [http://www.sarantel.com/products/sl1206 Sarantels] SL1206 active antenna.<br />
It's recommended to buy [https://www.sparkfun.com/products/574 This extension cable] to use with it. The price is the same at $90USD.<br />
<br style="clear:both;"/><br />
<br />
===u-blox NEO-6M===<br />
[[Image:Hk neo gps.jpg|thumb|left|Hobbyking NEO 6M back]]<br />
This is one of the cheapest complete modules with antenna for around 22$.<br />
[http://www.hobbyking.com/hobbyking/store/__31135__NEO_6M_GPS_Module.html Hobbyking]<br />
<br />
They come with different (sized) patch antenna, mounted on a seperate PCB. The main PCB and antenna PCB are fixed with hot glue together and can be seperated by hand.<br />
<br style="clear:both;"/><br />
<br />
===Navilock NL-652ETTL===<br />
Nice module with u-blox 6 chip and without the annoying cable that the HK NEO-6m has.<br />
[http://www.navilock.de/produkte/G_61846/merkmale.html?setLanguage=en Navilock NL-652ETTL]<br />
<br />
===u-Blox C04-6H Reference Design===<br />
[[Image:abavimage.jpg|thumb|left|u-blox C04-5H]]<br />
u-Blox sells a complete module with antenna for around $200 and will also provide complete schematics, BOM, and PCB files for free if you wish to make your own. Two versions are offered, one with an 18mm patch antenna and the other with the Sarantel P2 helical antenna.<br />
See [http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html http://www.ublox.com/en/evaluation-tools-a-software/reference-designs/for-gps-chips/c04-6h.html] for more info.<br />
<br style="clear:both;" /><br />
<br />
====Connecting external receivers====<br />
For Classix, 1.2.1, Lite, and RoboStix boards.<br />
The u-blox receivers require 3.3v power and all current models have 5V tolerant data lines. The best way to connect to the SAM-LS is to remove the bottom case and solder the 4 wires directly to the TIM-LL module (GND (pin 1) ,VCC (pin 2),TX (Pin 5),RX (pin 4)) check the TIM-LL datasheet for pinout diagrams.[http://www.u-blox.com/products/Data_Sheets/TIM-LL_Data_Sheet(GPS.G3-MS3-04035).pdf] The Classix and Lite boards feature a 3.3V regulator to power the GPS.<br />
To open the casing on a SAM-LS, remove the bottom of the casing by pulling gently, then work around popping off the solder joints (they are fairly weak) by pressing a small screwdriver against each tab in turn until it pops off. You should then be able to access the GPS chip directly.<br />
<br />
===LS20031 GPS Receiver===<br />
[[Image:ls20031.jpg|100px|thumb|left|LS20031]]<br />
Sparkfun sells the LS20031 GPS module which uses NMEA (Paparazzi support for NMEA is BETA right now.) This Locosys GPS module supports WAAS (U.S. DGPS), EGNOS (EU DGPS), and MSAS (Japanese DGPS).<br />
<br />
More information on configuring the GPS via PMTK can be found [http://dallasmakerspace.org/wiki/LS20031_GPS here]<br />
<br style="clear:both;" /><br />
<br />
==GPS configuration using U-Center==<br />
<br />
[[Image:U-center_screencap.jpg|thumb|u-center configuration software]]<br />
[http://www.u-blox.com/products/u_center.html U-Center] is a very comprehensive freeware program intended for the configuration and evaluation of u-blox receivers. <br />
* [http://www.u-blox.com/en/evaluation-tools-a-software/u-center/u-center.html Download u-center]<br />
<br />
* Note 1: You must [[tunnel|install the UART tunnel firmware]] to enable direct access to the built-in GPS on the [[Tiny|Tiny]].<br />
<br />
* Note 2: You will need a driver for your FTDI cable if you run u-center on Windows, which can be found [http://www.ftdichip.com/Drivers/D2XX.htm here].<br />
<br />
* Note 3: You can run u-center on Linux by installing "Wine" ([http://www.winehq.org/site/download-deb Installation of Wine]) and set up COM1 as /dev/ttyUSB0. You need to create a symbolic link from the COM device to TTY like this:<br />
mkdir -p ~/.wine/dosdevices<br />
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/COM1<br />
<br />
or what worked in Ubuntu 9.10<br />
<br />
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1<br />
This command will create the symbolic link from ttyUSB0 to COM1. See Info on Wine for "dosdevices" setup. Just download the u-setup.exe and run it with Wine, follow prompts. This has been tested with Ubuntu7.10 and Ubuntu 8.04 so far.<br />
<br />
The u-blox and Tiny UARTs both operate at 3.3V TTL levels and are 5V TTL tolerant. You must use a level shifter such as the common MAX232 to connect these devices to a standard PC serial port. The easiest and most recommended method is to connect to a USB port instead of serial with the $20 [http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm FTDI USB-TTL converter cable] available from Digikey, Mouser, or direct from FTDI. Other similar converters are available from [http://www.pololu.com/products/pololu/0391/ pololu] / [http://www.sparkfun.com/commerce/product_info.php?products_id=199 sparkfun]. A stand-alone GPS such as the SAM-LS will require clean 3.3V/50mA power and a common ground with the TTL converter.<br />
<br />
* U-blox occasionally releases firmware updates. Log on to the u-blox website using ''paparazzi'' for username & password to view or download the latest firmware images. There have 'never' been any updates released for the Antaris-4 series used in the Tiny.<br />
<br />
Start U-center and choose your com port from the pull down list under the connect button near the top left corner of the window. Choose your baudrate from the pull down box to the right of the connect button or select the auto-baud button to the right of that. U-blox default is 9600 baud. This must be changed to 19200 or higher to accomodate the 4Hz update rate.<br />
<br>[[Image:U-center_buttons.jpg|connect, baud, and autobaud buttons]]<br />
<br style="clear:both"><br />
<br />
===Uploading the Configuration File===<br />
<br />
Download the appropriate configuration file below and use u-center to load in onto your receiver. Under the ''Tools'' menu, choose ''GPS configuration''. Be sure the box 'Store configuration into BBR/Flash' is checked and hit the button ''File>>GPS''. A few errors and retries are normal, but a significant number of errors may indicate a poor connection and the software will notify you if it is unable to send all the data successfully.<br />
* [[Media:Tiny_LEA-4P-v6.zip|LEA-4P]]<br />
* [[Media:Tim-LL-V5.zip|TIM-LL]]<br />
* [[Media:Tiny_LEA-5H-v5.zip|LEA-5H (For Use w/ Firmware V5 ONLY!)]]<br />
<br />
===Automatic Configuration at Startup===<br />
You can also use the [[Module/GPS_UBlox_UCenter|u-blox UCenter module]] which will take over the task of initializing the GPS for you when you power your autopilot.<br />
<br />
===Manual Configuration===<br />
<br />
If you prefer to setup your receiver manually or have a model not listed above, here are instructions to configure your receiver in u-center.<br />
Open the message window (menu View->messages view) to start the configuration process by changing the following settings:<br />
<br />
====LEA-4P====<br />
<br />
# Right Click on the '''NMEA''' Icon and choose '''disable child'''<br />
# Choose UBX->CFG->NAV2(Navigation 2) - set it to use '''Airborne 4G''' (tells the Kalman filter to expect significant changes in direction)<br />
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])<br />
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point<br />
# UBX->CFG->RXM(Receiver Manager) - change '''GPS Mode''' to '''3 - Auto''' (Enabling faster bootup only if signal levels are very good)<br />
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' (4 Hz position updates)<br />
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)<br />
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSUTM, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black<br />
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver <br />
<br />
<br />
====LEA-5H====<br />
<br />
# Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''<br />
# Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction. <p> Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better</p><br />
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])<br />
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point<br />
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.<br />
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)<br />
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black<br />
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver<br />
<br />
<br />
* Cycle the power and verify that the new configuration was saved<br />
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.<br />
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.<br />
* To update the firmware on a LEA-5H get u-center >= 5.03, revert the GPS receiver to the default configuration, get an appropriate image from u-Blox (fitting your receivers serial number), find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.<br />
<br />
#NOTE: If you have a Tiny with LEA-5H module you must use u-center and manually setup the parameters as shown above (at least switch to 38400 baud manually before transferring the configuration file).<br />
#NOTE: POSUTM is not available on LEA-5H. Instead, use POSLLH.<br />
<br />
====LEA-6H====<br />
<br />
We use the same configuration as for version 5<br />
<br />
# Right Click on the '''NMEA''' Text on top of the tree and choose '''disable child messages'''<br />
# Choose UBX->CFG->NAV5(Navigation 5) - set it to use '''Airborne 8 <4G'''. This tells the Kalman filter to expect significant changes in direction. <p> Note that this setting is only good for faster moving airplanes. For a fixed position hovering heli, 'pedestrian' setting is better </p><br />
# UBX->CFG->PRT - set '''USART1''' to '''38400bps''' (must match the value in your [[Airframe_Configuration#GPS|Airframe file]])<br />
# Change the baudrate of U-Center to 38400bps if the connection is lost at this point<br />
# UBX->CFG->RATE(Rates) - change the '''Measurement Period''' to '''250ms''' This gives a 4 Hz position update since 4 x 250ms is one second.<br />
# UBX->CFG->SBAS : '''Disable''' (SBAS appears to cause occasional severe altitude calcuation errors)<br />
# UBX->NAV (not UBX->CFG->NAV): double click on '''POSLLH, SOL, STATUS, SVINFO, VELNED.''' They should change from grey to black<br />
# UBX->CFG->CFG : '''save current config''', click '''"send"''' in the lower left corner to permanently save these settings to the receiver.<p> Make sure you activate '''"2 - I2C-EEPROM"''' if using a ROM-based NEO chipset with external EEPROM (like [http://www.hobbyking.com/hobbyking/store/__31135__neo_6m_gps_module.html HK 31135])</p><br />
<br />
<br />
* Cycle the power and verify that the new configuration was saved<br />
* To reset the receiver to the factory defaults go to ''UBX->CFG->CFG'', select 'Revert to default configuration', and click ''Send'' at the bottom left corner. To permanently save these values choose 'Save current configuration' and click ''Send''.<br />
* To backup the configuration to a file on your PC: under the tools menu, choose GPS configuration, then click GPS>>file. This file can be re-loaded in a similar manner to configure additional identical receivers. Be sure the box 'Store configuration into BBR/Flash' is checked when reloading a configuration file to make the changes permanent.<br />
* To update the firmware on a LEA-6H get u-center >= 6.21, revert the GPS receiver to the default configuration, get an appropriate firmaware file from u-Blox, find the flash identification flash.txt file in the u-center install directory and be prepared to wait a long time.(seriously)<br />
<br />
===Reset to Default Settings===<br />
The GPS module can be reset to its original default settings by pulling BOOT_INT high(3.3V) during a power cycle ([http://www.u-blox.com/customersupport/gps.g4/ANTARIS4_Modules_SIM(GPS.G4-MS4-05007).pdf Antaris Manual, p. 122]). It may be required after a wrong firmware upgrade or a bad configuration change.<br />
<br />
===DGPS (Differential GPS)===<br />
Differential GPS is any method of improving GPS accuracy by comparing the GPS-indicated position of a nearby location to the known value and transmitting any error to the mobile unit. DGPS was originally created as a means of bypassing the deliberately introduced inaccuracies in civilian GPS signals. The original method used low frequency ground radios to relay correction data to the mobile unit and is still used today at airports, shipping ports, and even individual farms. Satellite Based Augmentation System (SBAS) is a modern form of DGPS where the ground stations relay correction data to a GEO-Stationary satellite, which then relays it to the mobile unit on standard GPS frequencies eliminating the need for a separate radio reciever. SBAS is currently available in 3 regions, [http://www.esa.int/esaNA/ESAF530VMOC_egnos_1.html WAAS, EGNOS, and MSAS regions] though only WAAS and EGNOS are officially operational. U-blox receivers support all common varieties of DGPS [http://www.u-blox.com/customersupport/gps.g3/ENGOS_Issues(GPS.G3-CS-04009).pdf read the u-blox SBAS application note].<br />
* It is important to note that DGPS methods only improve the ''accuracy'' of the position calculation, not the ''precision''. Since Paparazzi navigation is typically performed relative to the power-on location, any static error that could be corrected with DGPS is irrelevant.<br />
<br />
====WAAS issues====<br />
<br />
WAAS has been officially operational and "suitable for safety-of-life applications" since 2003. The default setting of all u-blox receivers ignores WAAS correction data and only uses the WAAS satellites for regular navigation like any other satellite. U-blox recommends further limiting this setting to exclude any stray EGNOS/MSAS satellites in North America, and completely disabling all SBAS functions for use outside North America. In 2006 one formerly reliable Paparazzi aircraft began having great GPS problems and displaying very erratic altitude calculations, disabling WAAS immediately resolved the issue and this phenomenon was recreated several times for verification. Turns out a new WAAS satellite was being added to the system and the others were being moved that week for better distribution. Our advice is to completely disable WAAS.<br />
<br />
====EGNOS ====<br />
<br />
EGNOS augments the GPS satellite navigation system and makes it suitable for safety critical UAS applications. EGNOS became operational on 1 October 2009. ESA claims that it can determine position to within 2 meters compared with about 20 meters for GPS alone. Note that the service is currently provided only in western Europe. For further information take a look on the [http://www.esa.int/esaNA/egnos.html ESA EGNOS website].<br />
<br />
For the latest update about functionality of EGNOS please check the website: [http://www.gsa.europa.eu European GNSS Supervisory Authority]"<br />
<br />
===Troubleshooting===<br />
<br />
Problem: I keep getting this error with my nice shiny Tiny v2.1 with a LEA-5H: Invalid_argument("Latlong.of_utm")<br />
<br />
Solution: Select the correct [[Subsystem/gps|GPS subsystem]].<br />
<br />
== Antenna options for the Tiny and Paparazzi GPS units ==<br />
See [[GPS/Antenna]].<br />
<br />
<br />
<br />
[[Category:Hardware]] [[Category:Sensors]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=STM32F4_Discovery&diff=16124STM32F4 Discovery2013-10-08T09:40:17Z<p>Mbina: Formatting; fixed typos</p>
<hr />
<div>[[Image:Stm32f4-discovery.jpg|right|300px]]<br />
<span style="color:#FF0000">'''CAUTION!'''</span> '''This page is for the STM32F4 Discovery board with STM32F407VGT6, a familiar board is available with STM32F401VCT6 but this is NOT exactly the same! Do not use the other board with files build for this one!'''<br />
==Overview==<br />
* STMicroelectronics STM32F4VGT6 Cortex M4 MCU, up to 168Mhz with floating point unit (FPU), 192 KB RAM, 1024KB Flash<br />
* on-board stlinkv2 with SWD header (capable of programming itself or an external MCU)<br />
* ob-board power regulator for the MCU (3V or 5V Input)<br />
* 1 x user push button<br />
* 4(5) x LED (orange, green, blue, red, green) <br />
* 6 x UART (UART1, UART2, UART3, UART4, UART5, UART6)<br />
* 3 x SPI (SPI1, SPI2, SPI3)<br />
* 2(3) x I2C (I2C1, I2C2, (I2C3))<br />
* 1 x PPM input<br />
* 4 x ADC input, which one is used for bat voltage<br />
* 97 x 66 mm PCB<br />
* 4 x status LED (USB OTG, stlink red, stlink green, USB power)<br />
* LIS302DL MEMS 3 axis accelerometer (currently not supported)<br />
<br />
==Pinout==<br />
The Discovery has a male 100 pin (2x25pin on both sides) pinout. <br />
<br />
===LED===<br />
LED_3 PD13 orange, above LIS302DL<br />
<br />
LED_4 PD12 green, left of LIS302DL<br />
<br />
LED_5 PD14 red, right of LIS302DL<br />
<br />
LED_6 PD15 blue, below LIS302DL<br />
<br />
LED_9 PA9, same as USB power (VBUS), needs to be enabled in stm32f4_discovery.h<br />
<br />
===UART===<br />
* UART1<br />
** TX PB6<br />
** RX PB7<br />
<br />
* UART2<br />
** TX PD5<br />
** RX PD6<br />
<br />
* UART3<br />
** TX PD8<br />
** RX PD9<br />
<br />
* UART4<br />
** TX PC10<br />
** RX PC11<br />
Can not be used if SPI3 is active !<br />
<br />
* UART5<br />
** TX PC12<br />
** RX PD2<br />
Can not be used if SPI3 is active !<br />
<br />
* UART6<br />
** TX PC6<br />
** RX PC7<br />
<br />
===SPI===<br />
* SPI1<br />
** SCK PB3<br />
** MISO PB4<br />
** MOSI PB5<br />
<br />
* SPI2<br />
** SCK PB13<br />
** MISO PB14<br />
** MOSI PB15<br />
Can not be used if PWM10 & PWM11 are active !<br />
<br />
* SPI3<br />
** SCK PC10<br />
** MISO PC11<br />
** MOSI PC12<br />
Can not be used if UART4 & UART5 are active !<br />
<br />
* SPI select Slave 0 PE2<br />
* SPI select Slave 1 PE7<br />
<br />
===I2C===<br />
* I2C1<br />
** SCL PB8<br />
** SDA PB9<br />
<br />
* I2C2<br />
** SCL PB10<br />
** SDA PB11<br />
<br />
* I2C3<br />
** SCL PA8<br />
** SDA PC9<br />
I2C3 needs to be enabled in stm32f4_discovery.h<br />
<br />
===ADC===<br />
* ADC_1 PB1<br />
* ADC_2 PC1<br />
* ADC_3 PC4<br />
* ADC_4 PA4 (used for BAT Voltge with voltage divider)<br />
<br />
===PWM===<br />
# PWM0 PE9<br />
# PWM1 PE11<br />
# PWM2 PE13<br />
# PWM3 PE14<br />
# PWM4 PE5<br />
# PWM5 PE6<br />
# PWM6 PA3<br />
# PWM7 PA2<br />
# PWM8 PA1<br />
# PWM9 PA0<br />
# PWM10 PB14 (can not be ised if SPI2 is active !)<br />
# PWM11 PB15 (can not be ised if SPI2 is active !)<br />
<br />
===PPM Input===<br />
PA8<br />
===Spektrum===<br />
bind pin PA8<br/><br />
input UART2 PA10<br />
===Jumper===<br />
====pin jumper====<br />
* JP1 current consumption of the MCU can be measured here<br />
* CN3 set: stlinkv2 is connected to onboard MCU, unset: stlinkv2 is connected to SWD header to program external MCU<br />
<br />
====solder jumper====<br />
* SB17 bypass for JP1<br />
<br />
<br />
<br />
<br />
==Firmware Flashing==<br />
'''FLASH_MODE=DFU''' is set as default <br/><br />
stm32f4-discovery can be programmed in two different ways:<br />
<br />
*with the MCU native (embedded in rom) DFU USB bootloader over the micro usb ab connector<br />
**required hardware: usb to micro and usb to mini usb cable <br />
**required software: dfu_util tool (present <br />
**put MCU in DFU mode: connect mini and usb to pc, connect pin BOOT0 with 3V, press reset button(LED LD7 should light up now), disconnect BOOT0 to 3V<br />
<br />
*with onboard stlinkv2 over SWD<br />
**required hardware: usb to mini usb cable<br />
**required software: st_flash and st_util<br />
**more information: [[STLink]] page<br />
<br />
<br />
<br />
[[Category:Autopilots]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Lisa/M_v2.0&diff=16050Lisa/M v2.02013-09-30T19:14:08Z<p>Mbina: /* R/C Receivers */ ; fixed typos and formatting</p>
<hr />
<div><div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div><br />
<div style="float: right; width: 45%; overflow: hidden">[[Image:LisaM_V2_0_TopView.JPG|right|500px|Lisa/M V2.0 top view]]</div><br />
<div style="float: right; width: 40%">__TOC__</div><br />
<br />
Lisa/M is a small, general purpose autopilot designed with flexibility across multiple applications in mind. Small weight and size, with (optional) integrated [[AspirinIMU | Aspirin IMU]] and full size 0.1" servo headers make the Lisa/M suitable for both fixed-wing and rotorcraft vehicles. This autopilot is based on a STM32 processor for extensive peripheral connection and faster processing.<br />
<br />
A number of tutorials are being prepared for getting started with Lisa/M:<br />
* [[Lisa/M/Tutorial/FixedWing|Fixedwing tutorial]]<br />
* [[Lisa/M/Tutorial/RotorCraft|Rotorcraft tutorial]]<br />
<br />
Please join us in our quest to make the getting started information even more, eh... informative, by adjusting those pages with your own improvements.<br />
<br />
== Features ==<br />
<br />
Lisa/M is based on the 64 pins STM32F105RCT6 [http://www.st.com/internet/mcu/product/221023.jsp connectivity line family] processor featuring 64k of RAM and 256k of FLASH. All the pins are exposed, providing access to the complete set of the STM32 peripherals.<br />
NOTE: This MCU is different from LISA/L. Lisa/L is based on the 64 pins STM32F103RE processor featuring 64k of RAM and 512k of FLASH, which is part of the [http://www.st.com/internet/mcu/product/164485.jsp high-density performance line family].<br />
<br />
* STM32 microcontroller [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf STM32F105RCT6 datasheet] with 256kB flash and 64kB RAM<br />
* Pressure sensor [http://www.bosch-sensortec.com/content/language1/html/3477.htm BMP085] (optional as of 08/2012)<br />
* 7 x Analog input channels<br />
* 3 x Generic digital in-/out-puts<br />
* 2 x 3.3V TTL UART (5V tolerant)<br />
* 8 x Servo PPM outputs (only 6 if second I2C (I2C1) bus in use)<br />
* 1 x CAN bus<br />
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus<br />
* 1 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus (2 x when using only the first 6 Servo PPM outputs)<br />
* 1 x Micro USB<br />
* 4 x status LEDs with attached test point<br />
* 10.8 grams (0.4 oz) (with Aspirin IMU mounted)<br />
* 9.9 grams (0.35 oz) (without Aspirin IMU mounted)<br />
* ~34mm x ~60mm x ~10mm<br />
* 4 layers PCB design<br />
<br />
With mounted Aspirin IMU has the following additional sensors on board:<br />
<br />
* 3 Axis Gyroscope<br />
* 3 Axis Accelerometer<br />
* 3 Axis Magnetometer<br />
* Barometer MS5611 (as of Aspirin v2.1)<br />
<br />
NOTE:<br />
'''Lisa/M has pads for the BMP085 pressure sensor. Lias/M 2 boards made before August 2012 had the BMP085 sensor mounted. Boards made after August 2012 do not have the sensor mounted as they are designed to be used with Aspirin 2.1 which has the new MS5611-01BA03 barometric pressure sensor.'''<br />
<br />
The drivers for the MS5611-01BA03 are '''work in progress''' and are available in the master branch of the Paparazzi codebase. All '''help''' with testing and improving the driver are '''very welcome'''!<br />
<br />
So, except for a GPS unit you have all necessary sensors for full attitude and altitude stabilization in an extremely small package.<br />
<br />
<gallery widths=200px heights=200px><br />
Image:LisaM_V2_0_TopView.JPG|Lisa/M V2.0 top view<br />
Image:LisaM_V2_0_BottomView.JPG|Lisa/M V2.0 bottom view<br />
</gallery><br />
<br />
== Pinout ==<br />
Pins Name and Type are specified with respect to the Autopilot Board.<br />
<br />
<div style="float: right; width: 100%"><br />
[[Image:LisaM_V2_0_top_labeled.png|900px]]<br />
[[Image:LisaM_warning_label.png|200px]]<br />
</div><br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''SERVO1/2/3/4/5/6/7/8'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||SERVOx||OUT||Servo signal (PWM)(See Note 1 below)||style="background:Yellow; color:black"|Yellow<br />
|-<br />
|2||SV||PWR||Servo Bus Voltage Rail (conf w/ JP1)||style="background:red; color:white"|Red<br />
|-<br />
|3||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''JTAG'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||N/A||N/A||JTAG Debug Header (Pin 1 is +3V3)||style="background:white; color:black"|None<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''UART3'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2||V_IN||PWR||UART Voltage (conf w/ JP6 and JP7)||style="background:Red; color:white"|Red<br />
|-<br />
|3||TX||OUT||USART3 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow<br />
|-<br />
|4||RX||IN||USART3 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''UART1/5'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red<br />
|-<br />
|3||RX1||IN||USART1 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange<br />
|-<br />
|4||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|5|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red<br />
|-<br />
|6||RX5||IN||UART5 Serial Input (3.3V level)(Pullup to Pin 5 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''GPIO'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red<br />
|-<br />
|4||PC12||I/O||GPIO, connected to PC12 (5V tolerant)||style="background:#FDC579; color:black"|Dark Tan<br />
|-<br />
|5||TRST||I/O||JTAG_TRST (also connected to LED1 cathode)||style="background:#FED6B1; color:black"|Light Tan<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''ANALOG2'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red<br />
|-<br />
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red<br />
|-<br />
|4||ADC4||I/O||by default connected to LED_4 cathode (Remove LED/resistor to use as ADC4)||style="background:magenta; color:white"|Magenta<br />
|-<br />
|5||ADC6||I/O||by default connected to LED_3 cathode (Remove LED/resistor to use as ADC6)||style="background:#FFA1B2; color:black"|Pink<br />
|-<br />
|6||BOOT0||I/O||BOOT0||style="background:grey; color:black"|Grey<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''USB'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||N/A||N/A||USB (The USB connections are also available as 0.05" (1.27mm) through hole pads underneath the GPIO header)||style="background:white; color:black"|None<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''I2C1 CAN'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| V_BATT||PWR||V_BATT Bus on autopilot, voltage divider for V_BAT_MEAS, (conf w/ JP2 to connect to V_IN)||style="background:Red; color:white"|Red<br />
|-<br />
|3|| V_IN||PWR||Connected to autopilot voltage regulator inputs (conf w/ JP1, JP2 and JP3)||style="background:Red; color:white"|Red<br />
|-<br />
|4||CANL||I/O||CANL (5V level)||style="background:orange; color:white"|Orange<br />
|-<br />
|5||CANH||I/O||CANH (5V level)||style="background:yellow; color:black"|Yellow<br />
|-<br />
|6||SCL||I/O||SCL (5V level)(See Note 1 below)||style="background:green; color:white"|Green<br />
|-<br />
|7||SDA||I/O||SDA (5V level)(See Note 1 below)||style="background:blue; color:white"|Blue<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''SPI1'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red<br />
|-<br />
|3||MOSI||Out||MOSI||style="background:orange; color:white"|Orange<br />
|-<br />
|4||MISO||In||MISO||style="background:yellow; color:black"|Yellow<br />
|-<br />
|5||SCK||Out||SCK||style="background:green; color:white"|Green<br />
|-<br />
|6||SS||Out||SS||style="background:blue; color:white"|Blue<br />
|-<br />
|7||DRDY||I/O||DRDY||style="background:#FDC579; color:black"|Dark Tan<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''ANALOG1'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red<br />
|-<br />
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red<br />
|-<br />
|4||ADC1||In||ADC1 (or LED_6 if populated)||style="background:green; color:white"|Green<br />
|-<br />
|5||ADC2||In||ADC2 (or LED_7 if populated)||style="background:blue; color:white"|Blue<br />
|-<br />
|6||ADC3||In||ADC3 (or LED_8 if populated)||style="background:#FED6B1; color:black"|Light Tan<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''UART2'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| +3V3||PWR||UART Voltage (conf w/ JP4 and JP5)||style="background:Red; color:white"|Red<br />
|-<br />
|3||TX||OUT||USART2 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow<br />
|-<br />
|4||RX||IN||USART2 Serial Input (3.3V level)('''NOT 5V TOLERANT''')(Pullup to Pin 2 voltage)||style="background:Orange; color:white"|Orange<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''I2C2'''<br />
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''<br />
|-<br />
|1||GND||PWR||common ground||style="background:black; color:white"|Black<br />
|-<br />
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red<br />
|-<br />
|3||SCL||I/O||SCL (3.3V level)||style="background:green; color:white"|Green<br />
|-<br />
|4||SDA||I/O||SDA (3.3V level)||style="background:blue; color:white"|Blue<br />
|}<br />
<br />
<br />
'''NOTE 1''': SERVO7 and SERVO8 are directly connected to I2C1_SCL and I2C1_SDA lines. Therefore one has to choose, either use SERVO7 and SERVO8 '''OR''' have the I2C1 bus available, if that one needs to be used for whatever reason alongside the I2C2 bus. To use the servos 7 and 8 just set the <define name="USE_SERVOS_7AND8"/> in your airframe file and you are good to go. For this to work one must make sure to have the latest Paparazzi sourcecode.<br />
<br />
=== LEDs ===<br />
Lisa/M 2.0 has 5 LEDS (+1 power LED). There are 3 additional LEDs (LED_6, LED_7, LED_8) that are not populated by default (in favor of using ADC1-3 on the ANALOG1 connector).<br />
By default the LEDs are use for:<br />
; LED_1, red: ''SYS_TIME_LED'': blinks with 1Hz<br />
; LED_2, green : ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on<br />
; LED_3, green : ''GPS_LED'': blinking if trying to get a fix, on if 3D fix<br />
; LED_4, red : ''RADIO_CONTROL_LED'': on if RC signal is ok<br />
; LED_5, green : not set to anything by default<br />
<br />
=== Jumper Configuration ===<br />
There are a number of jumpers on Lisa/M used to configure voltage levels and power input.<br />
<br />
The default configuration is UART3 VCC at V_IN, UART1/2/5 VCC at +3V3, with the V_SERVO servo voltage rail NOT connected to the autopilot V_IN rail, allowing one to power the autopilot and servos separately. The +5V regulator is NOT bypassed, allowing a regulated +5V on listed headers and for the CAN transceiver and I2C level shifter. The V_BATT connector is NOT connected to V_IN, so one can attach a battery voltage to the V_BATT pin to measure the battery voltage, if so desired.<br />
<br />
<gallery widths=380px heights=205px><br />
Image:LisaM_V2_0_top_jumpers_and_leds.png | Lisa/M v2.0 Top Jumpers and LEDs<br />
Image:LisaM_V2_0_bottom_jumpers.png | Lisa/M v2.0 Bottom Jumpers<br />
</gallery><br />
<br style="clear:both"><br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''Power Jumper Configuration'''<br />
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''<br />
|-<br />
|JP1||SERVO_BUS to V_IN||OPEN||Connects servo header voltage rail SERVO_BUS to autopilot input voltage V_IN rail<br />
|-<br />
|JP2||V_BATT to V_IN||OPEN||Connects I2C1/CAN rail V_BATT to autopilot input voltage V_IN rail<br />
|-<br />
|JP3||V_IN to +5V||OPEN||Connects autopilot input voltage V_IN rail to autopilot +5V rail, bypassing onboard 5V supply<br />
|}<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''UART3 VCC Configuration'''<br />
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''<br />
|-<br />
|JP6||UART3_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART3 connector VCC to autopilot input voltage V_IN rail<br />
|-<br />
|JP7||UART3_VCC to +3V3||OPEN||Connects UART3 connector VCC to autopilot +3V3 rail<br />
|}<br />
'''WARNING: UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting!!!'''<br />
<br />
'''WARNING: DO NOT CLOSE BOTH JP6 AND JP7 SIMULTANEOUSLY!!!'''<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''UART2 VCC Configuration'''<br />
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''<br />
|-<br />
|JP4||UART2_VCC to V_IN||OPEN||Connects UART2 connector VCC to autopilot input voltage V_IN rail '''SEE WARNING BELOW'''<br />
|-<br />
|JP5||UART2_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART2 connector VCC to autopilot +3V3 rail<br />
|}<br />
'''WARNING: UART2 RX is NOT 5V TOLERANT. Thus, while possible to connect UART2_VCC to V_IN, DO NOT ATTEMPT THIS. Only use JP5 (the default).<br />
<br />
'''WARNING: DO NOT CLOSE BOTH JP4 AND JP5 SIMULTANEOUSLY!!!'''<br />
<br />
<br />
{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"<br />
|+'''UART1 and UART5 VCC Configuration'''<br />
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''<br />
|-<br />
|JP8||UART1&5_VCC to V_IN||OPEN||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail<br />
|-<br />
|JP9||UART1&5_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail<br />
|}<br />
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''<br />
<br />
There are additional jumpers on the board for expert or developer configurations, please see [[Lisa/M_v20#Schematic|schematic]] and [[Lisa/M_v20#Downloads|layout]] for more information.<br />
<br />
=== Powering the Board ===<br />
<br />
[[Image:LisaM_warning_label.png|right|200px]]<br />
<br />
The 3.3V regulator on Lisa/M is a [http://www.micrel.com/page.do?page=/product-info/products/mic5209.shtml MIC5209-3.3YM] capable of delivering up to 500mA. While it is possible to power this regulator with up to 16V, '''DO NOT''' do this. By default, the UART3 RX pin is pulled up to the input voltage V_IN. For this reason, 5V is the maximum input voltage. Note that the UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting. If one desires to have V_IN at a higher voltage, the jumpers should be adjusted accordingly. As noted, this regulator can handle up to 16V, though experience has shown that this regulator can become very hot in operation with high input voltages, resulting in potential thermal shutdown while in flight. Depending on the expected current draw, it is best to power this regulator with a lower voltage. 5V is the perfect choice. <br />
<br />
The onboard 5V regulator on Lisa/M is a [http://www.national.com/pf/LP/LP2992.html LP2992], a low-noise, low-dropout linear regulator capable of delivering up to 250mA. This regulator can be bypassed with JP3, connecting the autopilot V_IN bus directly to the autopilot 5V bus if, for example, one is using an external 5V regulated supply, and a higher current is needed. Unless external use of 5V is required on the ANALOG1 and ANALOG2 headers, the only 5V usage onboard is for the CAN transceiver and the I2C1 level shifter.<br />
<br />
When measuring the supply voltage of a battery with the V_BATT pin (could be connected to V_IN through JP2), it is important to note the maximum voltage limit. The voltage divider on the board for measuring with a 3.3V ADC is --'''V_BAT'''--/\/\'''10k'''/\/\--'''V_BAT_MEAS'''--/\/\'''2k2'''/\/\--'''GND'''--. This means that the maximum allowable voltage on V_BATT is<br />
<br />
<math>V\_BAT_{max} = 3.3V*\frac{10k}{2.2k} = 15V</math><br />
<br />
If a higher voltage measurement is desired, another voltage divider is required off-board. Alternatively, one could modify the existing voltage divider (e.g. change 10k resistor to 22k to get 33V maximum). When checking if voltage exceeds the maximum, make sure to consider maximum battery voltage, not nominal voltage (e.g. 4.22V or so for a single lithium cell, not 3.7V nominal, so the maximum number of cells in series is 3, like a 3S LiPo pack).<br />
<br />
== Schematic ==<br />
<gallery widths=250px heights=168px><br />
Image:Lisa_m_v2_0_sheet_1.png | LisaM V2.0 Schematic Sheet 1/3<br />
Image:Lisa_m_v2_0_sheet_2.png | LisaM V2.0 Schematic Sheet 2/3<br />
Image:Lisa_m_v2_0_sheet_3.png | LisaM V2.0 Schematic Sheet 3/3<br />
</gallery><br />
<br style="clear:both"><br />
<br />
== Examples of Airborne Equipment Electrical Connections ==<br />
<br />
=== Quadrocopter, Spektrum Satellite Receivers and PWM Motor Controllers (ESC) ===<br />
<br />
[[File:LisaM_v2_0_wiring_quadrocopter_spektrum_pwmesc.png|700px]]<br />
<br />
This configuration assumes the ESCs have a battery eliminator circuit (BEC) function and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.<br />
<br />
When using cheap ATMega or SiLabs-based PWM motor controllers consider replacing their firmware with either [https://github.com/sim-/tgy Simon Kirby] or [https://github.com/bitdump/BLHeli BLHeli] firmware respectively to get useful performance of your multicopter! You can find a firmware compatibility list [https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE here].<br />
<br />
=== Quadrocopter, Spektrum Satellite Receivers and I2C Motor Controllers (ESC) ===<br />
<br />
[[File:LisaM_V2_0_quadrocopter_spektrum_i2c_esc_wiring.png|700px]]<br />
<br />
This diagram "should" be the same for AscTec as well as Mikrokopter motor controller based airframes.<br />
<br />
=== Fixedwing, Spektrum Satellite Receivers and Elevons Only ===<br />
<br />
[[File:LisaM_V2_0_wiring_fixedwing_spektrum_elevons.png|700px]]<br />
<br />
This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.<br />
<br />
=== Fixedwing, Spektrum Satellite Receivers ===<br />
<br />
[[File:LisaM_V2_0_wiring_fixedwing_spektrum.png|700px]]<br />
<br />
This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.<br />
<br />
=== Transitioning [http://wiki.thequadshot.com Quadshot] Using Spektrum Receivers ===<br />
<br />
[[File:LisaM_V2_0_wiring_quadshot_spektrum.png|700px]]<br />
<br />
The ESCs have BECs and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.<br />
<br />
Still need: Large Fixed-wing with advanced power system and/or IC engine, PPM example<br />
<br />
== R/C Receivers ==<br />
<br />
One can use Spektrum DSM2 or compatible receivers as well as traditional PPM receivers. It is even possible to connect two Spectrum or compatible satellite receivers for better redundancy or to improve RC signal reception. Connecting a RC receiver for flying your aircraft in manual mode during setup and test phase is 99% of the cases a must. Therefore the Paparazzi team made it easy to connect one.<br />
<br />
=== Using a Spectrum DSM receiver ===<br />
<br />
==== Physically connecting ====<br />
<br />
Wiring up a Spektrum or compatible satellite receiver is not to difficult to do. <br />
It is very important to make absolutley sure the connectors are properly made. <br />
Not being precise in this step can mean full RC loss and loss of airframe in the first tuning testflights. <br />
<br />
The spektrum satellite receiver should be connected to the UART1 connector on the autopilot board. Make sure the voltage on the AP board UART1 + pin is not to high, or to low for your receiver.<br />
<br />
Steps:<br />
# Connect the minus(-) of the receiver to GND of UART1<br />
# The receiver plus(+) to the UART1 Plus(+) <br />
# Data out signal of the receiver to the RX pin on the UART1<br />
<br />
==== Binding ====<br />
<br />
To get a receiver and transmitter to work together you must perform a binding process. <br />
<br />
It is important to '''bind''' your Spectrum DSM receiver to your transmitter '''via''' your '''Lisa board''', not in any other way!<br />
<br />
The way to bind is by temporary connecting via fiddly small molex pins. <br />
It is advised to make a small bind plug out of a molex connector for this purpose. <br />
Before you start make sure you have your airframe configuration already uploaded either via USB or a JTAG cable.<br />
<br />
The bind procedure:<br />
<br />
# On the connector '''ANALOG1''' have a wire between the GND and ADC1 pin, located in the middle of the board<br />
# Power up your autopilot board<br />
# Hold the bind button on your '''transmitter''', while '''keeping it pressed''' switch on your transmitter<br />
#:Wait...! All lights of the receiver blink and then go steady<br />
# Let go of your transmitter bind button<br />
# Power off your Lisa Board<br />
# Remove the wire connecting the GND and ADC1 pins on the ANALOG1 connector<br />
# Repower your board, if you have servos connected and wiggle the RC transmitter sticks some servos should move<br />
<br />
That is all, you are done. <br />
The bind procedure only needs to be done '''once''' for your receiver.<br />
<br />
=== Using a PPM receiver ===<br />
<br />
Using a PPM receiver, a so called '''PPM sum stream''' input is possible. [[RC_Receivers_and_Radios#PPM_Based_Systems | To make it work, you need a PPM sum stream out capable receiver. Find out more following this link]] <br />
<br />
==== Connecting ====<br />
<br />
Connect the PPM out signal to the RX pin of UART1.<br />
<br />
Make sure put this in your airframe file in your AP target section.<br />
<source lang="xml"><br />
...<br />
<subsystem name="radio_control" type="ppm"><br />
<configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/><br />
</subsystem><br />
...<br />
</source><br />
<br />
===== Alternative =====<br />
<br />
However if in the case you want to use the UART1 port for something else, there is an option to connect the receiver to a servo pin. Yes, that's right, a servo connector is used for receiving a PPM stream '''input'''. If you want to walk that path, the default pin number to capture the PPM sum stream is via servo connector SERVO6<br />
<br />
If you connect the PPM ou capable receiver that way make sure to put this in your airframe file in your AP target section:<br />
<br />
<source lang="xml"><br />
...<br />
<subsystem name="radio_control" type="ppm"><br />
<configure name="RADIO_CONTROL_PPM_PIN" value="SERVO6"/><br />
</subsystem><br />
...<br />
</source><br />
<br />
If you do not have or cannot modify a receiver to a ''PPM out'' able receiver, a [[PPM_Encoder | PPM encoder board]] can be used to avoid opening your receiver for PPM out modification.<br />
<br />
== Extras ==<br />
<br />
=== UART I/O ===<br />
<br />
UART pins can also be used as general purpose I/O, this might come in handy in case all other inputs or your AP board are in use.<br />
<br />
=== USB as UART1TX + hardware flow control===<br />
<br />
[[File:Lisam-usb-uart1.jpg]]<br />
<br />
The USB_VBUS on the Lisa/M 2.0 can be used as UART1 TX. To do this, a diode has to be removed. Make sure to include a series resistor of 100-3000 Ohm to protect the microcontroller from overcurrents. The 2nd and 3th pin of the USB pads are CTS and RTS respactively. It is recommended to include a series resistor in the RTS line, as this is an outgoing line. <br />
<br />
If you want to enable flow control in the software, but don't want to use flow control when no cable is connected to the CTS/RTS, a pulldown resistor of 10 kOhm has to be added between the CTS and the GND. If you do this, take care when connecting UART devices that have a large series resistor in their RTS line. The combination of the pulldown resistor and the series resistor might cause the high-level voltage to drop under the high-level treshold of the microcontroller, causing strange behaviour.<br />
<br />
For Example the RTS , mostly a purple wire, is the '''pin 10''' on the Xtend module when set in the module with Hardware flow control (use X-CTU)<br />
CTS, most blue, on pin 9 of the Xtend<br />
<br />
<gallery widths=380px heights=205px><br />
Image:Lisam-diode.JPG | Remove this diode. After removing this diode you can not power the board via USB anymore.<br />
Image:Lisam-gpio-usb.JPG | Take care of the small distance between the GPIO pins and the USB pads.<br />
</gallery><br />
<br />
== PCB ==<br />
<br />
=== Gerber & Drill Files ===<br />
<br />
'''''Download Lisa/M v2.0 gerber & drill files (zip)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''<br />
<br />
== Assembly ==<br />
<br />
To create and assemble a board oneself is possible. It takes some skills however. <br />
<br />
For the Lisa/m v2.0 without the Aspirin sensor board a good soldering iron is enough.(smallest components are 0402) For the Aspirin Sensor board you need a hot air soldering station.<br />
<br />
In case you wan to follow that path you need the desing. You came to the right place here is the info to get the needed files;<br />
<br />
===Components Layout===<br />
<br />
''[[Lisa/M_v2.0#Get the design|Get the design]]''<br />
<br />
Need some top and bottom of board images and line drawings here.<br />
<br />
=== Bill Of Material ===<br />
<br />
'''''Download Lisa/M v2.0 Bill Of Material (zipped .xls file)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''<br />
<br />
Open .sch File in Eagle, execute UPL --> bom.ulp , save as .txt<br />
<br />
== PCB and assembled boards suppliers ==<br />
<br />
To difficult to creat your own AP board, understandable, thus pre made board available via [[Get_Hardware|Get Hardware]] page... hopefully :)<br />
<br />
== Mechanical Dimensions ==<br />
<br />
[[Image:LisaM_V2_0_top_mechanical.png|500px|Lisa/M v2.0 Mechanical Dimensions]]<br />
<br />
The overall height of the board including the servo connectors is 10mm. Note that the overall length includes the USB connector. The mounting holes are nominal 2mm diameter (with a bit of clearance).<br />
<br />
== Get the design ==<br />
<br />
'''Source files'''<br />
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/lisa_m/v2.0 Lisa/M v2.0 Cadsoft Eagle 6 Design]''<br />
'''Gerber & Drill files'''<br />
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files<br />
'''Assembly files'''<br />
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Components layouts (pdf)<br />
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Bill Of Material<br />
<br />
== Uploading new software ==<br />
New onboard software for the Lisa/M v2.0 can uploaded by connecting your PC via a micro-USB port to the autopilot board. For this the board need to contain the [[Luftboot]] bootloader. All Lisa/M 2.0 from Transition Robotics Inc. come with luftboot already in the board.<br />
<br />
An alternative to get your firmware in the board is by using a JTAG connector connected via the 10-pin Samtec connector that is available on the board.<br />
<br />
See the [[FirmwareFlashing]] page for an overview of different methods to upload new software to your autopilot.<br />
<br />
=== Using luftboot ===<br />
'''This is the default FLASH_MODE for Lisa/M v2.0''', it could be explicitly selected by adding<br />
:<source lang="xml"><configure name="FLASH_MODE" value="DFU"/></source><br />
to the firmware section of your airframe file. Make sure to set Lisa/M 2.0 as it's target board.<br />
<br />
Once USB is plugged in, the board automatically goes to bootloader mode and the status LEDs cycle up and down:<br />
<br />
[[File:Luftboot.gif|320px]]<br />
<br />
If you have trouble entering the bootloader mode or want to upload/update the bootloader itself, see the [[Luftboot]] page.<br />
<br />
=== Using JTAG ===<br />
You still can use a [[JTAG|JTAG adapter]] for [[FirmwareFlashing#JTAG|flashing]] and [[DevGuide/JTAG-Debug|debugging]] your paparazzi firmware. To use [[FirmwareFlashing#JTAG|JTAG flashing]] configure the ''FLASH_MODE'' in your firmware section:<br />
:<source lang="xml"><configure name="FLASH_MODE" value="JTAG"/></source><br />
Using JTAG will not overwrite the bootloader by default. To overwrite the luftboot bootloader configure<br />
:<source lang="xml"><configure name="NO_LUFTBOOT" value="1"/></source><br />
<br />
Then press upload as normal...<br />
<br />
=== Serial Firmware Upload ===<br />
Firmware upload using the factory integrated bootloader can be useful e.g. if you have overwritten [[Luftboot]] accidentally and don´t have access to [[JTAG]].<br/><br />
Either set the flash mode in the target section of the airframe configuration:<br />
:<source lang="xml"><configure name="FLASH_MODE" value="SERIAL"/></source><br />
or add it to the commandline invocation:<br />
make AIRCRAFT=<aircraftname> ap.upload FLASH_MODE=SERIAL<br />
<br />
Due to hardware constraints, the board has to be modified to make use of the bootloader, which is only accessible on UART1:<br />
# Diode D3 has to be removed (the bigger black brick next to the USB connector). Attention, no more powering via USB after that.<br />
# BOOT1 has to be set to GND by connecting ACC_DRDY(unused) to GND at the Aspirin pads<br />
<br />
Now a boot sequence works as follows:<br />
#BOOT1 has to be set to 3.3V by use of a jumper cable<br />
#Connect a 3,3V serial cable (FTDI, MAX232...) to UART1, the TX pin is USB_VBUS<br />
#Power the board and activate the bootloader program<br />
<br />
== Detailed Hardware Revision History ==<br />
<br />
=== Changes Between LISA v1.1 and v2.0 ===<br />
<br />
* Lots of silkscreen improvements<br />
* Added attributes to all parts to make the usage of bom-ex ulp possible.<br />
* Improved routing to allow teardropping<br />
* Fixed stm32f1, f2 and f4 compatibility circuit. (has to jump to ground not to 3v3)<br />
* Connected existing UART RX pullups to the respective connector power pins instead of 3v3. To prevent connecting 5V over IO pin to the 3v3 power rail.<br />
* Added pullups on all UART RX lines to prevent undesired floatation.<br />
* LED's are connected to 3v3 now. To make sure we don't have an issue with voltage tolerance on the gpio pins.<br />
* ...<br />
<br />
== Hardware Change Requests ==<br />
<br />
If you have a Lisa/M 2.0 and in the process of using it you come up with something you find annoying, dangerous, or restricting, add your hardware update requests here. Better still, modify the Lisa schematics yourself and show your new improvements if you are skilled enough to do this.<br />
<br />
* REQ: Replace BMP085 with MS5611 (the MS5611 seems to be better in performance then the BMP but it is more expensive and seems to be more difficult to obtain. <br />
** A: Using a MS5611 is possible through using a Aspirin v2.1 board<br />
<br />
* REQ: Replace 7 Pin CAN with molex with something less risky to be inserted in 7 Pin SPI in relation to powering the board via CAN molex.<br />
<br />
* REQ: Separate spot for external power if powered via separate battery. Realizing we can via Servo ports by Bridge J1 but still like to measure board voltage then and have a way to add power without mistakenly insert I2CCAN Molex conector into SPI Molex on board connector. Thus a separate CAN and Power plug. Power on regular four pin molex with GND, V+5, , V_BATT, V_I (Current sense). Option to have thicker wire to be soldered to the board, for power hungry setups and other issues connectors for power are not a good idea.<br />
<br />
* REQ: Replace Aspirin IMU board with InvenSense MPU-9150 and bring the MS5611 back onto the Lisa/M board to reduce footprint, mass, and manufacturing cost once the 9150 becomes readily available(if at al with SPI) and is tested to perform well.<br />
[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=15967Airframe Configuration2013-09-24T20:52:58Z<p>Mbina: Merged with Airframe/Template;</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree><br />
== About ==<br />
The airframe file is the most important configuration file and contains all the hardware and software settings for your airframe. It describes what hardware you have and which firmware, sensors, algorithms, etc. you want to use and also holds your configuration parameters. All gains, trims, and behavior settings are defined with standard XML elements.<br />
<br />
The XML airframe configuration file is located in <tt>conf/airframes/<yourairframe>.xml</tt> and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line and should look like this<br />
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml"><br />
<!DOCTYPE airframe SYSTEM "airframe.dtd"><br />
<airframe name="yourairframe"><br />
<!-- The airframe configuration goes here. --><br />
</airframe><br />
</source>}}<br />
<br />
<b>Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|rotorcraft specific configuration]].</b><br />
<br />
== Creating a new Aircraft ==<br />
While the airframe file is where you configure most aspects of your aircraft, a fully specified aircraft needs several XML configuration files:<br />
* Airframe (what this page is about)<br />
* [[Flight_Plans|Flight Plan]]<br />
* [[Settings]]<br />
* [[Radio_Control|Radio]] (if you use a PPM based R/C system)<br />
* [[Telemetry]]<br />
Each aircraft is assigned a name, unique ID and the associated configuration files in [[Conf.xml|<tt>conf/conf.xml</tt>]]. To create a new Aircraft, click new in the menu A/C in the [[Paparazzi_Center|Paparazzi Center]] and select your new airframe file, etc. (or specify it by hand in [[Conf.xml|<tt>conf/conf.xml</tt>]]).<br />
<br />
== Firmware and Hardware definitions ==<br />
First you should specify which firmware you want to use, that is if you have a <tt>[[Fixedwing_Configuration|fixedwing]]</tt> aircraft or a <tt>[[Rotorcraft_Configuration|rotorcraft]]</tt>:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
</firmware><br />
</source><br />
}}<br />
=== Select your Board ===<br />
To specify autopilot hardware you are using and it's low-level settings you have to add a ''target''-tag.<br />
Each ''target'' has two attributes, which are ''name'' and a corresponding ''board'' attribute.<br />
The ''name'' attribute is either "ap" (autopilot) or "sim" (simulation).<br />
<br />
Select the appropriate hardware autopilot board you are going to use in your airframe:<br />
"booz_1.0", <br />
"classix", <br />
"hb_1.1", <br />
"lisa_l_1.0", <br />
"lisa_l_1.1", <br />
"lisa_m_1.0", <br />
"lisa_m_2.0", <br />
"logom_2.6", <br />
"navgo_1.0", <br />
"pc", <br />
"sdlog_1.0", <br />
"tiny_0.99", <br />
"tiny_1.1", <br />
"tiny_2.1", <br />
"tiny_2.11", <br />
"twog_1.0", <br />
"yapa_2.0",<br />
"umarim_1.0",<br />
"umarim_lite_2.0"<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
<target name="sim" board="pc"/> <!-- For simulation. --><br />
<target name="ap" board="lisa_m_1.0"/> <!-- Select your board here --><br />
...<br />
</firmware><br />
</source><br />
}}<br />
<br />
Note that the "pc" is a special kind of "board", and is mostly used only for simulation flights of an autopilot via your computer.<br />
<br />
==== Direct Makefile ====<br />
Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile Makefile] section. This is only needed in very advanced setups. For example when testing newly developed hardware.<br />
<br />
=== LEDs ===<br />
You can configure the LEDs on the autopilot to be used for different status indicators:<br />
; ''SYS_TIME_LED'': blinks with 1Hz<br />
; ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on<br />
; ''GPS_LED'': blinking if trying to get a fix, on if 3D fix<br />
; ''RADIO_CONTROL_LED'': on if RC signal is ok<br />
; ''BARO_LED'' : only on booz and navgo boards: blinks until baro offset is initialized and then stays on<br />
<br />
Depending on your board some of the LEDs on it are already assigned to some indicators by default, check the appropriate autopilot board page for the defaults.<br />
Use a configure node in the firmware section to assign an indicator to a LED number or disable that with ''none'':<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<configure name="SYS_TIME_LED" value="1"/><br />
<configure name="RADIO_CONTROL_LED" value="2"/><br />
<configure name="GPS_LED" value="none"/><br />
</firmware><br />
</source><br />
}}<br />
Beware that you can only assign '''one''' indicator to a LED number. So if the LED you want to use is already in use because another indicator is set to that number by default you have to disable that other indicator by setting it to ''none''.<br />
<br />
== Subsystems ==<br />
<br />
Each autopilot features certain [[Subsystems|subsystems]] which need to be configured properly.<br />
The most important ones are described below.<br />
<br />
=== IMU ===<br />
Add the [[Subsystem/imu|imu subsystem]] with the type you are using.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="imu" type="aspirin_v1.5"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
See the [[Subsystem/imu|imu subsystem]] page for more details.<br />
Also see the [[ImuCalibration|IMU calibration]] page.<br />
<br />
=== AHRS ===<br />
The [[Subsystem/ahrs|AHRS subsystem]] specifies which attitude estimation filter you are using, e.g. for the complementary filter:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_euler"/><br />
</firmware><br />
</source><br />
}}<br />
All AHRS algorithms depend on an imu subsystem, except for the ahrs_infrared which depends on the infrared module.<br />
See the [[Subsystem/ahrs|AHRS subsystem page]] for more details.<br />
<br />
=== Radio Control ===<br />
<br />
Supported types are:<br />
* ''ppm''<br />
* ''spektrum''<br />
* ''datalink''<br />
<br />
Just specify the appropriate [[Subsystem/radio_control|radio control subsystem]] in your firmware section, e.g.:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="radio_control" type="ppm"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
=== Telemetry (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 your [[Telemetry|telemetry file]], e.g. <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 />
The [[Subsystem/telemetry|telemetry subsystem]] 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 />
<br />
Just specify the appropriate [[Subsystem/telemetry|telemetry subsystem]] in your firmware section. You can currently choose between the types ''transparent'', ''transparent_usb'' and ''xbee_api''.<br />
<br />
'''The default baudrate is 57600 baud, see the [[Subsystem/telemetry|telemetry subsystem]] page for more details and configuration options.'''<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><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 />
Just specify the appropriate [[Subsystem/gps|gps subsystem]] in your firmware section. You can currently choose between the types '''ublox''' and '''ublox_utm''' for the older series 4 modules which still provide a UTM message.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="gps" type="ublox"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
The correct UART is already defined by default according to your board.<br />
The default GPS baudrate is 38400baud.<br />
<br />
If you need to set different baud rates or UART see the [[Subsystem/gps]] page for the options.<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 through the [[tunnel|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]<br />
<br />
== XML Parameters ==<br />
'''When defining parameters you can use [[Units|automatic unit conversion]] to conveniently set it in e.g. degrees.'''<br />
<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In a simple fixed-wing example, we have only three:<br />
<source lang="xml"><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><br />
</source><br />
For rotorcraft, it is usually:<br />
<source lang="xml"><br />
<commands><br />
<axis name="PITCH" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="YAW" failsafe_value="0"/><br />
<axis name="THRUST" failsafe_value="0"/><br />
</commands><br />
</source><br />
<br />
Each command is also associated with a failsafe value which will be used if no controller is active, for example during initialization of the autopilot board. The range of these values is [-9600:9600]. For <tt>"THROTTLE"</tt>, the range is [0, 9600] and in the corresponding <b><tt>servo</tt></b> definition the <b><tt>neutral</tt></b> and <b><tt>min</tt></b> are usually the same for PWM based servos (see below). Note that these commands do not necessarily match the servo actuators. For example, the <tt>"ROLL"</tt> command is typically linked to two aileron actuators.<br />
<br />
=== Servos ===<br />
<br />
The above commands get translated to the <b><tt>servos</tt></b> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <b><tt>servos</tt></b> section:<br />
<source lang="xml"><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos><br />
</source><br />
Names are associated to the corresponding '''real physical connector''' to which a servo is connected '''on the autopilot board'''. For example no="2" means connector two on the board. Also the servo neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds. The direction of travel can be reversed by exchanging min with max (as in <tt>"ELEVON_LEFTSIDE"</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. Absolute servo 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>.<br />
<br />
The attribute <b><tt>driver</tt></b> for <b><tt>servos</tt></b> node tells which actuators' driver is associated the the listed servos. After the version '''v4.9_devel-164-gdb0d004''', multiple servos sections can be defined and used together, if the correct [[Subsystem/actuators| actuators subsystems]] are loaded. Some boards are automatically loading a default driver, the one used when no <b><tt>driver</tt></b> attribute is specified.<br />
<br />
Note the following important tips:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymmetrical 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 />
* Board connector numbering starts with <b>zero (0)</b> not with one<br />
* Servos are also known under the synonym <b>actuators</b><br />
* (after version '''v4.9_devel-164-gdb0d004''') For I2C based motor speed control using the [[Rotorcraft_Configuration#Motor_Mixing|motor mixing]]:<br />
** min: command to stop the motor<br />
** neutral: motor idle command<br />
** max: max thrust command<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<source lang="xml"><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="ELEVON_LEFTSIDE" value="$elevator + $aileron"/><br />
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/><br />
</command_laws><br />
</source><br />
<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. Elevon 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 />
After '''v4.9_devel-164-gdb0d004''', the <b><tt>command_laws</tt></b> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.<br />
<br />
=== Battery === <br />
This section gives characteristics for monitoring the main power battery.<br />
<br />
<b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. Note that when flying the current typically is significantly lower than in static tests at home on your workbench. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the energy recharged into the battery is only 2000 mAh, you could reduce the <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> value by 20% to match your in-flight current consumption. This tweaking is most precise if you fly full throttle only (respectively no throttle to glide down again).<br />
<br />
The <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> can be added to tweak the energy estimation for non full throttle cruise. As the current consumption is nonlinear, at 50% throttle it is likely to be substantially less than 50%. A superellipse is used to approximate this nonlinearity. The default setting is 1.2 and is used if the <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> is not defined in your airframe file. A value 1 corresponds to linear behaviour, 1.5 corresponds to strong nonlinearity. The tweaking is done same as decribed above for <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b>, but only partial throttle (cruise throttle) should be applied in flight.<br />
<br />
If both <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> and <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> are tweaked well, you get precise energy estimations with less than 5% error independant of your flight pattern without even requiring a [[Current_sensor|current sensor]].<br />
<br />
The <b><tt>CATASTROPHIC_BAT_LEVEL</tt></b> (was previously <b><tt>LOW_BATTERY</tt></b>) value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode (kill_throttle mode). This value is also used by the ground server to issue a '''CATASTROPHIC''' alarm message on the bus (this message will be displayed in the console of the GCS). <b><tt>CRITIC</tt></b> and <b><tt>LOW</tt></b> values will also used as threshold for '''CRITIC''' and '''WARNING''' alarms. They are optional and the respective defaults are 10.0 and 10.5V.<br />
<br />
The <b><tt>MAX_BAT_LEVEL</tt></b> may be specified to improve the display of the battery gauge in the strip or in "papgets". Note that this definition is optional, with a default value of 12.5V.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="BAT"><br />
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" /><br />
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/><br />
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/><br />
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/><br />
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/><br />
</section><br />
</source><br />
}}<br />
<br />
The conversion of ADC measurements to Voltage is already defined for the different autopilot boards, if you need to override these defaults you can use the <b><tt>VoltageOfAdc(adc)</tt></b> define and also specify offsets or anything else you might need, e.g.:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="BAT"><br />
...<br />
<define name="VOLTAGE_ADC_SCALE" value="0.0177531"/><br />
<define name="VOLTAGE_OFFSET" value="0.5" unit="V"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_SCALE * adc + VOLTAGE_OFFSET)"/><br />
</section><br />
</source><br />
}}<br />
<br />
=== Modules ===<br />
The [[Modules|modules]] allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.<br />
<br />
<source lang="xml"><br />
<modules main_freq="60"><br />
<load name="demo_module.xml"/><br />
</modules><br />
</source><br />
<br />
* The main_freq parameter (in Hz) allows to specify the frequency of the main loop. Default is 60 Hz<br />
<br />
=== GCS ===<br />
Use this <b>optional</b> section to help customize parts of the GCS for a specific airframe:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="GCS"><br />
...<br />
<define name="ALT_SHIFT_PLUS_PLUS" value="30"/><br />
<define name="ALT_SHIFT_PLUS" value="5"/><br />
<define name="ALT_SHIFT_MINUS" value="-5"/><br />
<define name="SPEECH_NAME" value="Quad"/><br />
</section><br />
</source><br />
}}<br />
<br />
* <tt>ALT_SHIFT_PLUS_PLUS</tt> sets the number of metres the target altitude will change when the double up arrow button is pressed on the [[GCS#Strips|strip]]<br />
* <tt>ALT_SHIFT_PLUS</tt> sets the number of metres the target altitude will change when the up arrow button is pressed on the [[GCS#Strips|strip]]<br />
* <tt>ALT_SHIFT_MINUS</tt> sets the number of metres the target altitude will change when the down arrow button is pressed on the [[GCS#Strips|strip]]<br />
* <tt>SPEECH_NAME</tt> a string ([a-zA-Z0-9_]) that will be used in place of the aircraft name specified in <tt>conf.xml</tt> for the [[Speech|speech]] and [[GCS#Alarms|alarms]] functionality. Set this to "_" to prevent the speech function from saying the aircraft name. Useful if your aircraft name takes a long time to say (i.e. "UAV1-A_with_spektrum" can be shortened to "Plane").<br />
<br />
[[Category:User_Documentation]] [[Category:Airframe_Configuration]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Tuning&diff=15966Tuning2013-09-24T19:52:43Z<p>Mbina: /* Other Misc things before flying */ ; adding hyperref</p>
<hr />
<div>== Intro ==<br />
<br />
This page provides guidelines for tuning a new aircraft and additional practical tips. Be sure to familiarize yourself with the theory of [[Theory_of_Operation#PID|PID Controllers]] before you begin tuning your airframe. Use of the [[RTPlotter|real time plotter]] may help to visualize and understand the behavior of the control loops. Review [http://paparazzi.enac.fr/w/images/Users_manual.pdf User Manual] as well. Also reading [http://www.av8n.com/how/ See How It Flies, by John S. Denker] is very beneficial to get your airframe tuned well.<br />
<br />
==Energy Control==<br />
<br />
If you came to this page and want to learn about how to perform your [[Tuning_energy_control_loops | Energy control tuning]], this is '''not''' the page to read, go to [[Tuning_energy_control_loops | tuning energy control loops]].<br />
<br />
==Quickstart==<br />
<br />
'''Here is the sub-minimal ultra-quick-start guide: note that point 1 and 3 should ALWAYS be performed every time you reflash your plane!!!'''<br />
<br />
# Before take-off [[Tuning#Directions|check]] (beware: do not skip a test as it is not because 2 are good that the third will also be good)<br />
## RC-left is aileron-left and up is up in [[AutopilotModes|MANUAL]].<br />
## RC-left is aileron-left and up is up in [[AutopilotModes|AUTO1]].<br />
## [[Tuning#Directions|turning the plane-left is aileron-right]] and nose-up is elevator-down with RC in neutral in [[AutopilotModes|AUTO1]]. (to check the [[GCS#PFD|Artificial horizon]] in the [[GCS|GCS]]: use the words: right wing sees the ground to not mess up left and right if uncertain.)<br />
# Fly manual<br />
## [[Tuning#Neutrals|trim your plane]]<br />
## check [[Fixedwing_Configuration#Servos|servo deflections]] are good (sufficient but not aerobatic)<br />
## remember the cruise throttle. (and max/min throttle if you will use aggressive-climb)<br />
# On the ground, after trimming: <br />
## Check with plane flat/cruise attitude on the ground that the ailerons/elevator do not move when you switch from MANUAL to AUTO1. This checks your IMU/Thermopiles are properly aligned and that [[Tuning#Trim|your trim values are in the airframe file and not the RC-transmitter]] <br />
# Test [[Tuning#Auto_1|try AUTO1]]<br />
## When entering AUTO1, make sure you try to turn before your plane is too far away since [[Fixedwing_Configuration#Auto1|AUTO1 circles are usually much larger than manual circles]].<br />
## Make a [[RTPlotter|graph]] on the groundstation of DESIRED->phi/theta and ATTITUDE-phi/theta to see if they match. <br />
## When flying with IMU pay special attention here if after several left turns the plane still turns right too. Plot the IMU_ACC->ax,ay,az to see the average vibration in your plane. If the vibration level is lower than half of gravity (5m/s2) than usually you are OK. If it is much more, you should dampen your IMU more. (in foam, or mounted on your heavy battery, ...)<br />
# Only when AUTO1 works fine you can [[Tuning#Auto_1|go to AUTO2]]<br />
## check that your throttle is not killed (RED) in the groundstation<br />
## check that your cruise throttle is correct if you have a powerful motor <br />
## if tuning the altitude loop seems difficult try the [[Tuning#Sample.2FSimple_Altitude_and_Throttle_Loop|simple 3 gain auto_throttle_loop]]<br />
<br />
== Sensors ==<br />
<br />
=== Neutrals ===<br />
* Put the aircraft in a styrofoam container or completely seal the IR sensors with styrofoam or similar blocks and get a reading of the neutrals for each axis. Also take the gyro neutrals at this time. Update your airframe file, flash the AP and re-check the neutrals.<br />
<br />
Using the roll gyro as a worked example: Run up your GCS and ensure it <br />
is communicating with your airframe. Make sure your airframe is roughly <br />
level and that it cannot move. Now run the Messages Tool and the [[RTPlotter|real time plotter]] tool. The messages tool will have lots of flashing lights <br />
indicating when it receives various telemetry packets. In the Messages <br />
tool, Click on Gyro Rates and you should see a list of variables. Click <br />
on Roll_ADC and drag and drop in onto the main window of the Real Time plotter. Now give it a while to build a stable graph.<br />
<br />
Once things have been running this way for a while, in the Real Time <br />
Plotter, click on Curves in the menu and select the <br />
1:telemetry:GYRO_RATES:Roll_ADC entry. As you select it, you should see <br />
the average and standard deviation values. We need the average value. <br />
Jot down the number you have. I have -24.536.<br />
<br />
Now go edit your airframe file and look for the ADC_ROLL_NEUTRAL value. <br />
In my airframe file the value is 520. As my average value from the Plotter is a <br />
negative figure, it indicates that the roll Neutral is too high, subtract the average value from the present setting. So I edited my airframe file to be 495.464 (520-24.536).<br />
<br />
Recompile and reflash (Don't worry about restarting the GCS, The <br />
messages program or the other running processes - they will catch up just <br />
fine after flashing). Once the Board is back up and the plotter continues, reset it from the menu to get rid of the average. Watch it for a while and check that the line and acculmulated average is on or around 0. You are done. Use the same process for the IR sensors!<br />
<br />
=== Directions ===<br />
* Reverse any servos and make sure no mechanical binding occurs at the limits of travel in Manual mode.<br />
* Take the plane outside and engage AUTO1. Bank and pitch the plane and verify that the controls respond in the correct direction AND that the PFD in the notebook responds correctly. Note that your body will have a tremendous impact on the measured angles if using IR sensors. If using an IMU, there is no need to be outside. See note.<br />
* Verify that AUTO1 stick movements respond in the correct direction - important! See note.<br />
* Move the plane rapidly to ensure the gyro response resists motion - increase the gain if needed for better visualization.<br />
NOTE: If the PFD responds in the wrong direction to the motion, you should adjust parameters in the INFRARED or IMU parts of the airframe file. If the control surfaces respond in the wrong direction to counteract motion (stabilize the aircraft, bring it back to neutral), reverse the servos in the airframe file. If the manual input from R/C causes the control surfaces to respond in the wrong direction (want them to force motion, not counteract motion), then you must reverse the channel on the R/C transmitter. Be sure to recheck surface neutrals and endpoints after doing such modifications. Also double check the gain signs, make sure none are positive that should be negative.<br />
<br />
== R/C, Modem, and GPS ==<br />
* Make sure the GPS signal is strong (outdoors) - you should have a 3-D fix in less than 1 minute and at least some satellite signals above 40dB. The plane should not drift on the map by more than 10 meters.<br />
* Perform a range test of R/C and modem signals.<br />
* Ensure that two way communications are in place. Check that the motor starts up when launch is commanded or move a waypoint and check that it's updated in the autopilot.<br />
<br />
== Trim ==<br />
<b>Important: You must never keep any trim, mixers, or rates in your R/C transmitter.</b> R/C trim can be applied in flight but must be corrected and removed on the ground before attempting autonomous flight. Exponential can be useful and will not adversely affect AUTO1 flight but if "low rates" are needed they should be programmed on the same transmitter switch with AUTO1 so that you always have full travel in AUTO1.<br />
* Fly the plane at what you feel is a suitable "cruise" throttle setting and set the trims. Note that setting in the GCS and try to return to that exact setting in subsequent tests. Enter that throttle setting in your airframe file.<br />
* Check maximum pitch and roll response and adjust the mixer parameters or mechanical linkages after landing.<br />
* Land and adjust the linkages. If necessary, the PPM values can be read from the GCS and servo neutrals adjusted electronically, but manual adjustment will produce far better results.<br />
* Fly again to verify trim and control response. If satisfactory, check for any significant throttle-dependent roll. Again, this is best to correct mechanically but can be addressed with the ''AILERON_OF_THROTTLE'' mixer in the autopilot. Check also for any odd behavior at full throttle.<br />
* Make sure that GPS and modem data is reliable during these test flights. Note particularly any tendency for the aircraft to appear to fly sideways on the map - this is an indication of weak GPS signals.<br />
<br />
== Auto 1 ==<br />
* Engage Auto1 and ''immediately'' make sure you can turn both left and right!<br />
* Fly at your "cruise" throttle and adjust the ''ROLL_PGAIN'' until the plane doesn't quite oscillate<br />
* Adjust the IR roll neutral as needed<br />
* Verify adequate pitch response and adjust PITCH_PGAIN as needed<br />
* Experiment with different throttle settings and tune P and D gains as needed<br />
<br />
If you are alone in the field while tuning, setting values via your RC transmitter may come in handy, see [[Telemetry#R.2FC_Transmitter_Data_Uplink|RC reveiver data uplink]]<br />
<br />
== Auto 2 ==<br />
* Engage [[AutopilotModes|AUTO2]] and you're done! Make sure you keep a finger on the Mode switch to take over just in case.<br />
<br />
==Alternate Tuning Procedure==<br />
Danstah wrote up a tuning procedure on this website http://www.engr.usu.edu/wiki/index.php/OSAMtuning<br />
<br />
==Sample/Simple Altitude and Throttle Loop==<br />
<br />
The dash button changes the NOMINAL_CRUISE_THROTTLE to the MAX_CRUISE_THROTTLE while the loiter button changes it to MIN_CRUISE_THROTTLE. <br />
<br />
This makes it easy to suddenly make the UAV fly a bit slower or a bit faster. However, when changing the throttle, you also need to change the elevator trim in order not to climb/descend too much. This it what AUTO_THROTTLE_LOITER_TRIM and AUTO_THROTTLE_DASH_TRIM are for. (I think the unit is MAX_PPRZ = 9600 = full deflection?) <br />
<br />
The auto-throttle loop is actually the most difficult loop to tune as it has both the speed and altitude that are correlated. Controlling both speed and altitude with high performance is very hard. It is way easier to control 1 entity (e.g. altitude) with higher performance and let the speed change a bit, or have an airspeed controller but then do the altitude slowly... <br />
<br />
Sample altitude controller:<br />
---------------------<br />
<br />
Step1: outerloop: if altitude is not good -> compute a climb/descend rate. (including ALTITUDE_MAX_CLIMB)<br />
<br />
climb_command = altitude_error x alt_pgain<br />
<br />
e.g. 10 m too low x 0.1 alt gain = climb_command at 1 m/s<br />
e.g. 50 m too low x 0.1 alt gain = climb at 5 m/s > ALTITUDE_MAX_CLIMB(2) -> climb_command = 2m/s<br />
<br />
---------------------<br />
<br />
Step2: innerloop: [many many options here, but since you ask for simple I'll only give one robust and simple:]<br />
<br />
too low -> pitch up and extra throttle (if you only apply throttle, airspeed will increase and might even start to dive with full throttle if the nose is a bit heavy, if you only apply pitch airspeed will decrease and could lead to stall, with proper tuning you can get a pretty constant speed even while climbing and descending) <br />
<br />
pitch_command = climb_command x pitch_of_vz<br />
throttle_command = nominal_cruise_trim_throttle + climb_command x throttle_climb_increment<br />
<br />
e.g. climb_command at 1 m/s x pitch_of_vz 0.15 = 0.15 radians pitch = 9 degrees pitch up<br />
<br />
e.g. climb_command at 1 m/s x throttle_climb_increment 0.25 with nominal_cruise_trim_throttle 0.5 = 75% throttle<br />
<br />
-------------------<br />
<br />
If you use AGRESSIVE_CLIMB then if the altitude error is larger than the chosen threshold a precomputed pitch and throttle will be applied. <br />
<br />
AUTO_PITCH is for constant throttle and control height with elevator only<br />
<br />
auto_throttle_p/i/d_gains are to regulate the climb rate more precisely<br />
<br />
==Other Misc things before flying==<br />
<br />
It's very important to address the issue of low voltage cut-off before flying (LVC). <br />
There's a good chance that the LVC will kick in on the brushless ESC before the Paparazzi detects it. <br />
If this happens, the ESC cut's off throttle, and there's no way the autopilot knows this, the plane keeps loosing altitude, <br />
the autopilot tries to increase throttle, but the ESC does not respond, almost always leading to a mishap. <br />
To avoid this, either turn off the LVC on the ESC, OR, make sure the autopilot kills throttle first, <br />
by programming the CATASTROPHIC_BAT_LEVEL to something higher than the ESC LVC. <br />
For example, set CATASTROPHIC_BAT_LEVEL to 9.5V, and the ESC LVC at 9V. <br />
Don't ask how we know, it was a safe landing into a small tree :) No damage. BUT you cant get lucky always!<br />
<br />
Have a look at the [[Failsafe|failsafe]] and [[Airframe_Configuration#Battery|battery configuration]] for more details.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Tuning&diff=15965Tuning2013-09-24T19:48:09Z<p>Mbina: /* Auto 2 */</p>
<hr />
<div>== Intro ==<br />
<br />
This page provides guidelines for tuning a new aircraft and additional practical tips. Be sure to familiarize yourself with the theory of [[Theory_of_Operation#PID|PID Controllers]] before you begin tuning your airframe. Use of the [[RTPlotter|real time plotter]] may help to visualize and understand the behavior of the control loops. Review [http://paparazzi.enac.fr/w/images/Users_manual.pdf User Manual] as well. Also reading [http://www.av8n.com/how/ See How It Flies, by John S. Denker] is very beneficial to get your airframe tuned well.<br />
<br />
==Energy Control==<br />
<br />
If you came to this page and want to learn about how to perform your [[Tuning_energy_control_loops | Energy control tuning]], this is '''not''' the page to read, go to [[Tuning_energy_control_loops | tuning energy control loops]].<br />
<br />
==Quickstart==<br />
<br />
'''Here is the sub-minimal ultra-quick-start guide: note that point 1 and 3 should ALWAYS be performed every time you reflash your plane!!!'''<br />
<br />
# Before take-off [[Tuning#Directions|check]] (beware: do not skip a test as it is not because 2 are good that the third will also be good)<br />
## RC-left is aileron-left and up is up in [[AutopilotModes|MANUAL]].<br />
## RC-left is aileron-left and up is up in [[AutopilotModes|AUTO1]].<br />
## [[Tuning#Directions|turning the plane-left is aileron-right]] and nose-up is elevator-down with RC in neutral in [[AutopilotModes|AUTO1]]. (to check the [[GCS#PFD|Artificial horizon]] in the [[GCS|GCS]]: use the words: right wing sees the ground to not mess up left and right if uncertain.)<br />
# Fly manual<br />
## [[Tuning#Neutrals|trim your plane]]<br />
## check [[Fixedwing_Configuration#Servos|servo deflections]] are good (sufficient but not aerobatic)<br />
## remember the cruise throttle. (and max/min throttle if you will use aggressive-climb)<br />
# On the ground, after trimming: <br />
## Check with plane flat/cruise attitude on the ground that the ailerons/elevator do not move when you switch from MANUAL to AUTO1. This checks your IMU/Thermopiles are properly aligned and that [[Tuning#Trim|your trim values are in the airframe file and not the RC-transmitter]] <br />
# Test [[Tuning#Auto_1|try AUTO1]]<br />
## When entering AUTO1, make sure you try to turn before your plane is too far away since [[Fixedwing_Configuration#Auto1|AUTO1 circles are usually much larger than manual circles]].<br />
## Make a [[RTPlotter|graph]] on the groundstation of DESIRED->phi/theta and ATTITUDE-phi/theta to see if they match. <br />
## When flying with IMU pay special attention here if after several left turns the plane still turns right too. Plot the IMU_ACC->ax,ay,az to see the average vibration in your plane. If the vibration level is lower than half of gravity (5m/s2) than usually you are OK. If it is much more, you should dampen your IMU more. (in foam, or mounted on your heavy battery, ...)<br />
# Only when AUTO1 works fine you can [[Tuning#Auto_1|go to AUTO2]]<br />
## check that your throttle is not killed (RED) in the groundstation<br />
## check that your cruise throttle is correct if you have a powerful motor <br />
## if tuning the altitude loop seems difficult try the [[Tuning#Sample.2FSimple_Altitude_and_Throttle_Loop|simple 3 gain auto_throttle_loop]]<br />
<br />
== Sensors ==<br />
<br />
=== Neutrals ===<br />
* Put the aircraft in a styrofoam container or completely seal the IR sensors with styrofoam or similar blocks and get a reading of the neutrals for each axis. Also take the gyro neutrals at this time. Update your airframe file, flash the AP and re-check the neutrals.<br />
<br />
Using the roll gyro as a worked example: Run up your GCS and ensure it <br />
is communicating with your airframe. Make sure your airframe is roughly <br />
level and that it cannot move. Now run the Messages Tool and the [[RTPlotter|real time plotter]] tool. The messages tool will have lots of flashing lights <br />
indicating when it receives various telemetry packets. In the Messages <br />
tool, Click on Gyro Rates and you should see a list of variables. Click <br />
on Roll_ADC and drag and drop in onto the main window of the Real Time plotter. Now give it a while to build a stable graph.<br />
<br />
Once things have been running this way for a while, in the Real Time <br />
Plotter, click on Curves in the menu and select the <br />
1:telemetry:GYRO_RATES:Roll_ADC entry. As you select it, you should see <br />
the average and standard deviation values. We need the average value. <br />
Jot down the number you have. I have -24.536.<br />
<br />
Now go edit your airframe file and look for the ADC_ROLL_NEUTRAL value. <br />
In my airframe file the value is 520. As my average value from the Plotter is a <br />
negative figure, it indicates that the roll Neutral is too high, subtract the average value from the present setting. So I edited my airframe file to be 495.464 (520-24.536).<br />
<br />
Recompile and reflash (Don't worry about restarting the GCS, The <br />
messages program or the other running processes - they will catch up just <br />
fine after flashing). Once the Board is back up and the plotter continues, reset it from the menu to get rid of the average. Watch it for a while and check that the line and acculmulated average is on or around 0. You are done. Use the same process for the IR sensors!<br />
<br />
=== Directions ===<br />
* Reverse any servos and make sure no mechanical binding occurs at the limits of travel in Manual mode.<br />
* Take the plane outside and engage AUTO1. Bank and pitch the plane and verify that the controls respond in the correct direction AND that the PFD in the notebook responds correctly. Note that your body will have a tremendous impact on the measured angles if using IR sensors. If using an IMU, there is no need to be outside. See note.<br />
* Verify that AUTO1 stick movements respond in the correct direction - important! See note.<br />
* Move the plane rapidly to ensure the gyro response resists motion - increase the gain if needed for better visualization.<br />
NOTE: If the PFD responds in the wrong direction to the motion, you should adjust parameters in the INFRARED or IMU parts of the airframe file. If the control surfaces respond in the wrong direction to counteract motion (stabilize the aircraft, bring it back to neutral), reverse the servos in the airframe file. If the manual input from R/C causes the control surfaces to respond in the wrong direction (want them to force motion, not counteract motion), then you must reverse the channel on the R/C transmitter. Be sure to recheck surface neutrals and endpoints after doing such modifications. Also double check the gain signs, make sure none are positive that should be negative.<br />
<br />
== R/C, Modem, and GPS ==<br />
* Make sure the GPS signal is strong (outdoors) - you should have a 3-D fix in less than 1 minute and at least some satellite signals above 40dB. The plane should not drift on the map by more than 10 meters.<br />
* Perform a range test of R/C and modem signals.<br />
* Ensure that two way communications are in place. Check that the motor starts up when launch is commanded or move a waypoint and check that it's updated in the autopilot.<br />
<br />
== Trim ==<br />
<b>Important: You must never keep any trim, mixers, or rates in your R/C transmitter.</b> R/C trim can be applied in flight but must be corrected and removed on the ground before attempting autonomous flight. Exponential can be useful and will not adversely affect AUTO1 flight but if "low rates" are needed they should be programmed on the same transmitter switch with AUTO1 so that you always have full travel in AUTO1.<br />
* Fly the plane at what you feel is a suitable "cruise" throttle setting and set the trims. Note that setting in the GCS and try to return to that exact setting in subsequent tests. Enter that throttle setting in your airframe file.<br />
* Check maximum pitch and roll response and adjust the mixer parameters or mechanical linkages after landing.<br />
* Land and adjust the linkages. If necessary, the PPM values can be read from the GCS and servo neutrals adjusted electronically, but manual adjustment will produce far better results.<br />
* Fly again to verify trim and control response. If satisfactory, check for any significant throttle-dependent roll. Again, this is best to correct mechanically but can be addressed with the ''AILERON_OF_THROTTLE'' mixer in the autopilot. Check also for any odd behavior at full throttle.<br />
* Make sure that GPS and modem data is reliable during these test flights. Note particularly any tendency for the aircraft to appear to fly sideways on the map - this is an indication of weak GPS signals.<br />
<br />
== Auto 1 ==<br />
* Engage Auto1 and ''immediately'' make sure you can turn both left and right!<br />
* Fly at your "cruise" throttle and adjust the ''ROLL_PGAIN'' until the plane doesn't quite oscillate<br />
* Adjust the IR roll neutral as needed<br />
* Verify adequate pitch response and adjust PITCH_PGAIN as needed<br />
* Experiment with different throttle settings and tune P and D gains as needed<br />
<br />
If you are alone in the field while tuning, setting values via your RC transmitter may come in handy, see [[Telemetry#R.2FC_Transmitter_Data_Uplink|RC reveiver data uplink]]<br />
<br />
== Auto 2 ==<br />
* Engage [[AutopilotModes|AUTO2]] and you're done! Make sure you keep a finger on the Mode switch to take over just in case.<br />
<br />
==Alternate Tuning Procedure==<br />
Danstah wrote up a tuning procedure on this website http://www.engr.usu.edu/wiki/index.php/OSAMtuning<br />
<br />
==Sample/Simple Altitude and Throttle Loop==<br />
<br />
The dash button changes the NOMINAL_CRUISE_THROTTLE to the MAX_CRUISE_THROTTLE while the loiter button changes it to MIN_CRUISE_THROTTLE. <br />
<br />
This makes it easy to suddenly make the UAV fly a bit slower or a bit faster. However, when changing the throttle, you also need to change the elevator trim in order not to climb/descend too much. This it what AUTO_THROTTLE_LOITER_TRIM and AUTO_THROTTLE_DASH_TRIM are for. (I think the unit is MAX_PPRZ = 9600 = full deflection?) <br />
<br />
The auto-throttle loop is actually the most difficult loop to tune as it has both the speed and altitude that are correlated. Controlling both speed and altitude with high performance is very hard. It is way easier to control 1 entity (e.g. altitude) with higher performance and let the speed change a bit, or have an airspeed controller but then do the altitude slowly... <br />
<br />
Sample altitude controller:<br />
---------------------<br />
<br />
Step1: outerloop: if altitude is not good -> compute a climb/descend rate. (including ALTITUDE_MAX_CLIMB)<br />
<br />
climb_command = altitude_error x alt_pgain<br />
<br />
e.g. 10 m too low x 0.1 alt gain = climb_command at 1 m/s<br />
e.g. 50 m too low x 0.1 alt gain = climb at 5 m/s > ALTITUDE_MAX_CLIMB(2) -> climb_command = 2m/s<br />
<br />
---------------------<br />
<br />
Step2: innerloop: [many many options here, but since you ask for simple I'll only give one robust and simple:]<br />
<br />
too low -> pitch up and extra throttle (if you only apply throttle, airspeed will increase and might even start to dive with full throttle if the nose is a bit heavy, if you only apply pitch airspeed will decrease and could lead to stall, with proper tuning you can get a pretty constant speed even while climbing and descending) <br />
<br />
pitch_command = climb_command x pitch_of_vz<br />
throttle_command = nominal_cruise_trim_throttle + climb_command x throttle_climb_increment<br />
<br />
e.g. climb_command at 1 m/s x pitch_of_vz 0.15 = 0.15 radians pitch = 9 degrees pitch up<br />
<br />
e.g. climb_command at 1 m/s x throttle_climb_increment 0.25 with nominal_cruise_trim_throttle 0.5 = 75% throttle<br />
<br />
-------------------<br />
<br />
If you use AGRESSIVE_CLIMB then if the altitude error is larger than the chosen threshold a precomputed pitch and throttle will be applied. <br />
<br />
AUTO_PITCH is for constant throttle and control height with elevator only<br />
<br />
auto_throttle_p/i/d_gains are to regulate the climb rate more precisely<br />
<br />
==Other Misc things before flying==<br />
<br />
It's very important to address the issue of low voltage cut-off before flying (LVC). There's a good chance that the LVC will kick in on the brushless ESC before the Paparazzi detects it. If this happens, the ESC cut's off throttle, and there's no way the autopilot knows this, the plane keeps loosing altitude, the autopilot tries to increase throttle, but the ESC does not respond, almost always leading to a mishap. To avoid this, either turn off the LVC on the ESC, OR, make sure the autopilot kills throttle first, by programming the CATASTROPHIC_BAT_LEVEL to something higher than the ESC LVC. For example, set CATASTROPHIC_BAT_LEVEL to 9.5V, and the ESC LVC at 9V. Don't ask how we know, it was a safe landing into a small tree :) No damage. BUT you cant get lucky always!<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Tuning&diff=15964Tuning2013-09-24T19:47:44Z<p>Mbina: /* Quickstart */ ; adding links</p>
<hr />
<div>== Intro ==<br />
<br />
This page provides guidelines for tuning a new aircraft and additional practical tips. Be sure to familiarize yourself with the theory of [[Theory_of_Operation#PID|PID Controllers]] before you begin tuning your airframe. Use of the [[RTPlotter|real time plotter]] may help to visualize and understand the behavior of the control loops. Review [http://paparazzi.enac.fr/w/images/Users_manual.pdf User Manual] as well. Also reading [http://www.av8n.com/how/ See How It Flies, by John S. Denker] is very beneficial to get your airframe tuned well.<br />
<br />
==Energy Control==<br />
<br />
If you came to this page and want to learn about how to perform your [[Tuning_energy_control_loops | Energy control tuning]], this is '''not''' the page to read, go to [[Tuning_energy_control_loops | tuning energy control loops]].<br />
<br />
==Quickstart==<br />
<br />
'''Here is the sub-minimal ultra-quick-start guide: note that point 1 and 3 should ALWAYS be performed every time you reflash your plane!!!'''<br />
<br />
# Before take-off [[Tuning#Directions|check]] (beware: do not skip a test as it is not because 2 are good that the third will also be good)<br />
## RC-left is aileron-left and up is up in [[AutopilotModes|MANUAL]].<br />
## RC-left is aileron-left and up is up in [[AutopilotModes|AUTO1]].<br />
## [[Tuning#Directions|turning the plane-left is aileron-right]] and nose-up is elevator-down with RC in neutral in [[AutopilotModes|AUTO1]]. (to check the [[GCS#PFD|Artificial horizon]] in the [[GCS|GCS]]: use the words: right wing sees the ground to not mess up left and right if uncertain.)<br />
# Fly manual<br />
## [[Tuning#Neutrals|trim your plane]]<br />
## check [[Fixedwing_Configuration#Servos|servo deflections]] are good (sufficient but not aerobatic)<br />
## remember the cruise throttle. (and max/min throttle if you will use aggressive-climb)<br />
# On the ground, after trimming: <br />
## Check with plane flat/cruise attitude on the ground that the ailerons/elevator do not move when you switch from MANUAL to AUTO1. This checks your IMU/Thermopiles are properly aligned and that [[Tuning#Trim|your trim values are in the airframe file and not the RC-transmitter]] <br />
# Test [[Tuning#Auto_1|try AUTO1]]<br />
## When entering AUTO1, make sure you try to turn before your plane is too far away since [[Fixedwing_Configuration#Auto1|AUTO1 circles are usually much larger than manual circles]].<br />
## Make a [[RTPlotter|graph]] on the groundstation of DESIRED->phi/theta and ATTITUDE-phi/theta to see if they match. <br />
## When flying with IMU pay special attention here if after several left turns the plane still turns right too. Plot the IMU_ACC->ax,ay,az to see the average vibration in your plane. If the vibration level is lower than half of gravity (5m/s2) than usually you are OK. If it is much more, you should dampen your IMU more. (in foam, or mounted on your heavy battery, ...)<br />
# Only when AUTO1 works fine you can [[Tuning#Auto_1|go to AUTO2]]<br />
## check that your throttle is not killed (RED) in the groundstation<br />
## check that your cruise throttle is correct if you have a powerful motor <br />
## if tuning the altitude loop seems difficult try the [[Tuning#Sample.2FSimple_Altitude_and_Throttle_Loop|simple 3 gain auto_throttle_loop]]<br />
<br />
== Sensors ==<br />
<br />
=== Neutrals ===<br />
* Put the aircraft in a styrofoam container or completely seal the IR sensors with styrofoam or similar blocks and get a reading of the neutrals for each axis. Also take the gyro neutrals at this time. Update your airframe file, flash the AP and re-check the neutrals.<br />
<br />
Using the roll gyro as a worked example: Run up your GCS and ensure it <br />
is communicating with your airframe. Make sure your airframe is roughly <br />
level and that it cannot move. Now run the Messages Tool and the [[RTPlotter|real time plotter]] tool. The messages tool will have lots of flashing lights <br />
indicating when it receives various telemetry packets. In the Messages <br />
tool, Click on Gyro Rates and you should see a list of variables. Click <br />
on Roll_ADC and drag and drop in onto the main window of the Real Time plotter. Now give it a while to build a stable graph.<br />
<br />
Once things have been running this way for a while, in the Real Time <br />
Plotter, click on Curves in the menu and select the <br />
1:telemetry:GYRO_RATES:Roll_ADC entry. As you select it, you should see <br />
the average and standard deviation values. We need the average value. <br />
Jot down the number you have. I have -24.536.<br />
<br />
Now go edit your airframe file and look for the ADC_ROLL_NEUTRAL value. <br />
In my airframe file the value is 520. As my average value from the Plotter is a <br />
negative figure, it indicates that the roll Neutral is too high, subtract the average value from the present setting. So I edited my airframe file to be 495.464 (520-24.536).<br />
<br />
Recompile and reflash (Don't worry about restarting the GCS, The <br />
messages program or the other running processes - they will catch up just <br />
fine after flashing). Once the Board is back up and the plotter continues, reset it from the menu to get rid of the average. Watch it for a while and check that the line and acculmulated average is on or around 0. You are done. Use the same process for the IR sensors!<br />
<br />
=== Directions ===<br />
* Reverse any servos and make sure no mechanical binding occurs at the limits of travel in Manual mode.<br />
* Take the plane outside and engage AUTO1. Bank and pitch the plane and verify that the controls respond in the correct direction AND that the PFD in the notebook responds correctly. Note that your body will have a tremendous impact on the measured angles if using IR sensors. If using an IMU, there is no need to be outside. See note.<br />
* Verify that AUTO1 stick movements respond in the correct direction - important! See note.<br />
* Move the plane rapidly to ensure the gyro response resists motion - increase the gain if needed for better visualization.<br />
NOTE: If the PFD responds in the wrong direction to the motion, you should adjust parameters in the INFRARED or IMU parts of the airframe file. If the control surfaces respond in the wrong direction to counteract motion (stabilize the aircraft, bring it back to neutral), reverse the servos in the airframe file. If the manual input from R/C causes the control surfaces to respond in the wrong direction (want them to force motion, not counteract motion), then you must reverse the channel on the R/C transmitter. Be sure to recheck surface neutrals and endpoints after doing such modifications. Also double check the gain signs, make sure none are positive that should be negative.<br />
<br />
== R/C, Modem, and GPS ==<br />
* Make sure the GPS signal is strong (outdoors) - you should have a 3-D fix in less than 1 minute and at least some satellite signals above 40dB. The plane should not drift on the map by more than 10 meters.<br />
* Perform a range test of R/C and modem signals.<br />
* Ensure that two way communications are in place. Check that the motor starts up when launch is commanded or move a waypoint and check that it's updated in the autopilot.<br />
<br />
== Trim ==<br />
<b>Important: You must never keep any trim, mixers, or rates in your R/C transmitter.</b> R/C trim can be applied in flight but must be corrected and removed on the ground before attempting autonomous flight. Exponential can be useful and will not adversely affect AUTO1 flight but if "low rates" are needed they should be programmed on the same transmitter switch with AUTO1 so that you always have full travel in AUTO1.<br />
* Fly the plane at what you feel is a suitable "cruise" throttle setting and set the trims. Note that setting in the GCS and try to return to that exact setting in subsequent tests. Enter that throttle setting in your airframe file.<br />
* Check maximum pitch and roll response and adjust the mixer parameters or mechanical linkages after landing.<br />
* Land and adjust the linkages. If necessary, the PPM values can be read from the GCS and servo neutrals adjusted electronically, but manual adjustment will produce far better results.<br />
* Fly again to verify trim and control response. If satisfactory, check for any significant throttle-dependent roll. Again, this is best to correct mechanically but can be addressed with the ''AILERON_OF_THROTTLE'' mixer in the autopilot. Check also for any odd behavior at full throttle.<br />
* Make sure that GPS and modem data is reliable during these test flights. Note particularly any tendency for the aircraft to appear to fly sideways on the map - this is an indication of weak GPS signals.<br />
<br />
== Auto 1 ==<br />
* Engage Auto1 and ''immediately'' make sure you can turn both left and right!<br />
* Fly at your "cruise" throttle and adjust the ''ROLL_PGAIN'' until the plane doesn't quite oscillate<br />
* Adjust the IR roll neutral as needed<br />
* Verify adequate pitch response and adjust PITCH_PGAIN as needed<br />
* Experiment with different throttle settings and tune P and D gains as needed<br />
<br />
If you are alone in the field while tuning, setting values via your RC transmitter may come in handy, see [[Telemetry#R.2FC_Transmitter_Data_Uplink|RC reveiver data uplink]]<br />
<br />
== Auto 2 ==<br />
* Engage Auto2 and you're done! Make sure you keep a finger on the Mode switch to take over just in case.<br />
<br />
==Alternate Tuning Procedure==<br />
Danstah wrote up a tuning procedure on this website http://www.engr.usu.edu/wiki/index.php/OSAMtuning<br />
<br />
==Sample/Simple Altitude and Throttle Loop==<br />
<br />
The dash button changes the NOMINAL_CRUISE_THROTTLE to the MAX_CRUISE_THROTTLE while the loiter button changes it to MIN_CRUISE_THROTTLE. <br />
<br />
This makes it easy to suddenly make the UAV fly a bit slower or a bit faster. However, when changing the throttle, you also need to change the elevator trim in order not to climb/descend too much. This it what AUTO_THROTTLE_LOITER_TRIM and AUTO_THROTTLE_DASH_TRIM are for. (I think the unit is MAX_PPRZ = 9600 = full deflection?) <br />
<br />
The auto-throttle loop is actually the most difficult loop to tune as it has both the speed and altitude that are correlated. Controlling both speed and altitude with high performance is very hard. It is way easier to control 1 entity (e.g. altitude) with higher performance and let the speed change a bit, or have an airspeed controller but then do the altitude slowly... <br />
<br />
Sample altitude controller:<br />
---------------------<br />
<br />
Step1: outerloop: if altitude is not good -> compute a climb/descend rate. (including ALTITUDE_MAX_CLIMB)<br />
<br />
climb_command = altitude_error x alt_pgain<br />
<br />
e.g. 10 m too low x 0.1 alt gain = climb_command at 1 m/s<br />
e.g. 50 m too low x 0.1 alt gain = climb at 5 m/s > ALTITUDE_MAX_CLIMB(2) -> climb_command = 2m/s<br />
<br />
---------------------<br />
<br />
Step2: innerloop: [many many options here, but since you ask for simple I'll only give one robust and simple:]<br />
<br />
too low -> pitch up and extra throttle (if you only apply throttle, airspeed will increase and might even start to dive with full throttle if the nose is a bit heavy, if you only apply pitch airspeed will decrease and could lead to stall, with proper tuning you can get a pretty constant speed even while climbing and descending) <br />
<br />
pitch_command = climb_command x pitch_of_vz<br />
throttle_command = nominal_cruise_trim_throttle + climb_command x throttle_climb_increment<br />
<br />
e.g. climb_command at 1 m/s x pitch_of_vz 0.15 = 0.15 radians pitch = 9 degrees pitch up<br />
<br />
e.g. climb_command at 1 m/s x throttle_climb_increment 0.25 with nominal_cruise_trim_throttle 0.5 = 75% throttle<br />
<br />
-------------------<br />
<br />
If you use AGRESSIVE_CLIMB then if the altitude error is larger than the chosen threshold a precomputed pitch and throttle will be applied. <br />
<br />
AUTO_PITCH is for constant throttle and control height with elevator only<br />
<br />
auto_throttle_p/i/d_gains are to regulate the climb rate more precisely<br />
<br />
==Other Misc things before flying==<br />
<br />
It's very important to address the issue of low voltage cut-off before flying (LVC). There's a good chance that the LVC will kick in on the brushless ESC before the Paparazzi detects it. If this happens, the ESC cut's off throttle, and there's no way the autopilot knows this, the plane keeps loosing altitude, the autopilot tries to increase throttle, but the ESC does not respond, almost always leading to a mishap. To avoid this, either turn off the LVC on the ESC, OR, make sure the autopilot kills throttle first, by programming the CATASTROPHIC_BAT_LEVEL to something higher than the ESC LVC. For example, set CATASTROPHIC_BAT_LEVEL to 9.5V, and the ESC LVC at 9V. Don't ask how we know, it was a safe landing into a small tree :) No damage. BUT you cant get lucky always!<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=FAQ&diff=15963FAQ2013-09-24T19:28:31Z<p>Mbina: /* What do MANUAL/AUTO1/AUTO2 stand for? */</p>
<hr />
<div><noinclude><br />
{| width="100%" style="border: solid 2px #A3B1BF; background: #F5FAFF" |<br />
|-<br />
| <br />
<h2 style="background-color:#cedff2; border-bottom:0px; border: 1px solid #a3b0bf; text-align:center; padding-top:4px;">General Paparazzi FAQ<br />
</h2></noinclude><br />
<br/><!--TOC spacing--><br />
__NOTOC__ __TOC__<br />
<br />
==Is it possible to __________?==<br />
:Yes, of course! That's the beauty of an open-source system - virtually any feature or function you want can be added to the hardware and/or software.<br />
<br />
==How can I contribute?==<br />
:See the [[Contributing| how to contribute]] wiki page.<br />
<br />
==How do I check which Paparazzi Version I'm using==<br />
: Run ./paparazzi_version from you paparazzi directory.<br />
: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v3.9.2_testing-1-g72f4b21''.<br />
: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.<br />
: If you have an older version of Paparazi that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt><br />
<br />
==What equipment and components are suggested==<br />
:Linux (Debian or Ubuntu) compatible or Apple Macintosh notebook computer, preferably with a very bright screen for outdoor use.<br />
:Most any airframe that will accommodate IR sensors and some extra weight and wiring - ''brushless motors are strongly suggested.'' See the [[Gallery|User's Gallery]] for some airframe examples.<br />
:[[Autopilots|Tiny]] autopilot from one of the [[Get_Hardware|Paparazzi vendors]] or build your own from the downloadable plans/gerbers<br />
:[[Infrared_Sensors|IR sensor (x-y)]] board from one of the [[Get_Hardware|Paparazzi vendors]]<br />
:[[Infrared_Sensors|IR sensor (z)]] board from one of the [[Get_Hardware|Paparazzi vendors]]<br />
:R/C Transmitter with a 3-position switch for selecting Manual/Stabilized/Auto. Some common models are listed in [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/conf/radios/ conf/radios]<br />
:R/C Receiver with an accessible PPM signal to tap. See: [[Other_Hardware#R.2FC_Receiver|Suggested R/C receivers]]<br />
:A pair of [[Modems]] along with any enclosures and antennas<br />
:[http://www.mouser.com/search/ProductDetail.aspx?R=TTL-232R-3V3virtualkey62620000virtualkey626-DLP-TTL-232R-3V3 FTDI USB-TTL] cable for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver<br />
:A standard [http://www.mouser.com/search/ProductDetail.aspx?R=68806-0019virtualkey53830000virtualkey538-68806-0019 Mini-B USB cable] and [http://www.mouser.com/search/productdetail.aspx?R=500075-0517virtualkey53810000virtualkey538-500075-0517 receptacle] for uploading firmware to the autopilot<br />
:Lots of [[Other_Hardware#Wiring|very durable wire, crimpers, and molex pins or pre-crimped wire.]]<br />
<br />
==Are internal combustion engines supported?==<br />
:Yes, not relying solely on inertial measurement, the Paparazzi system is very well suited for aircraft with high vibration levels. Care must be taken to prevent oily exhaust residue buildup on the IR sensors and a simple variable must be added to properly address the special idle/kill needs of an IC engine.<br />
<br />
==Can Paparazzi fly a glider?==<br />
:Sure. Paparazzi uses throttle and pitch to control climb rate by default. You can fit an airspeed sensor and adjust your airframe configuration to maintain airspeed instead.<br />
<br />
==Will the autopilot provide enough 5V power for many/large/digital servos as well as a modem, video TX, etc.?==<br />
:The [[Tiny]] includes a high capacity and high efficiency switching voltage regulator intended to power servos, modems, video systems and other payloads. This regulator should be preferred to power the servos rather than a linear regulator. While linear regulators may be rated for several amps, they require a great deal of cooling and can easily overheat with only a few hundred milliamps of continuous current without cooling. By comparison, the switching regulator included on the Tiny can work continuously at 2A with little or no cooling. Be careful using high power or digital servos consuming a lot of current. If you use four or more of them on your airframe it is recommended to supply them separately. It is important to realize that the servos in any stabilized aircraft will operate continuously. Therefore a power supply that powers the servos reliably in manual flight may easily overheat or produce critical voltage drops in autonomous flight.<br />
<br />
==Do I need a separate battery or regulator to isolate the autopilot, servos, video, modem, etc. from one another?==<br />
:The autopilot processor and sensors are powered by a 3.3V regulator and therefore are rather isolated from voltage fluctuations on the battery or 5V bus.<br />
<br />
==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==<br />
:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox is one of the most expensive receivers on the market but offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature. If you find a more capable receiver, let the group know about it, but this is not the place to save $40.<br />
<br />
==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==<br />
:Most modern GPS receivers have the ability to process serial data sent from an external DGPS receiver, but the advent of WAAS/EGNOS has made the early ground-based DGPS transmitters nearly obsolete. The u-Blox GPS receiver supports all common SBAS systems (WAAS, EGNOS, and MSAS), as well as any standard form of external DGPS. It's important to understand that DGPS merely improves the ''accuracy'' of the position estimate by subtracting any static error. The only way to improve the ''precision'' of the GPS is by improving the antenna or the GPS module itself. See [http://en.wikipedia.org/wiki/Accuracy_and_precision Wikipedia:Accuracy and Precsion] for a detailed explanation of these terms.<br />
<br />
==How does the R/C receiver interface with the autopilot?==<br />
:Standard hobby R/C transmitters multiplex up to 9 channels of PWM servo data into a single PPM signal which is encoded onto an FM wave for transmission, this signal is then decoded by the RF section of the R/C receiver back into the original PPM signal containing 9 servo position PWM values. This signal is normally then sent to a demultiplexer (i.e. 4017) where it is separated into 9 individual servo signals on 9 individual pins. The Paparazzi autopilot intercepts the signal between the RF section and the demultiplexer and does its own demultiplexing, filtering, and processing before multiplexing the manual or autonomous servo commands back into a single signal and passing them to the 4017 to be distributed to the servos.<br />
<br />
==Why does Paparazzi tap directly into the R/C receiver instead of using individual servo signals?==<br />
:By connecting directly to the RF section of the R/C receiver we are able to obtain up to 9 channels of R/C servo data from a small, lightweight inexpensive 4 channel receiver with only 3 wires needed to connect the components. Furthermore, the autopilot then has direct access to the raw R/C signal where it can be filtered, evaluated, and assessed for quality. The autopilot can then alert the user of any loss of R/C signal as well as perform any pre-configured autonomous commands in response to a loss of signal.<br />
<br />
==Are PCM or 2.4GHz R/C systems compatible with Paparazzi?==<br />
:Yes. Some receivers have the signal available for tapping into the input pin with success and can thus be modified to get the required PPM signal. A general rule of thumb is that if you see any type of demultiplexer on your R/C receiver, you can look up the data sheet for it and likely tap into the input pin with success. Some information on compatible R/C receivers and how to find the PPM signal of your own receiver is given in the [[Other_Hardware#R.2FC_Receiver|RC receiver]] section.<br />
<br />
:If that's not possible, you can use the available PPM encoder board, to re-multiplex the servo channels into one PPM signal. This seems to be a common solution.<br />
<br />
==What R/C transmitters are compatible?==<br />
:No mixing or programming is done in the transmitter so even the simplest models will suffice but one important requirement is a 3-position switch to select among the three autopilot modes: manual, stabilized only, and fully autonomous. Those handy with electronics can replace a dial with a switch and resistor if needed. The transmitter's PPM values need to be recorded and the channel used to control the autopilot mode must be stated. Some commonly used transmitter configuration files are provided in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/conf/radios/ conf/radios] folder and the syntax of these files is easy to follow for those using other brands or models.<br />
<br />
==Can a gamepad/joystick be used to control the aircraft through the modem?==<br />
:Yes, the code to do this was written some time ago though it was not tested in flight due to latency concerns with the primitive [[Modems#Coronis_WaveCard|Coronis]] modems used at the time. Any of the [[modems]] currently recommended should work well in this manner but the theoretical reliability is still questionable due to the fact that no interrupt or prioritization structure exists for the telemetry data so any manual control inputs would be lumped in with the rest of the data to be lost or delayed as needed.<br />
<br />
==What do MANUAL/AUTO1/AUTO2 stand for?==<br />
<br />
:Those are the three modes that Paparazzi can operate in. Confer to [[AutopilotModes]] for more information.<br />
<br />
==What Electronic Speed Controllers (ESC) are compatible?==<br />
:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around 1200ms) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as 1500ms to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-1850ms but can be set at different values where needed.<br />
<br />
==Can traditional throttle stick programming be done on the ESC once connected to the autopilot?==<br />
:Yes. If the transmitter is on with the throttle at full or whatever is required for your ESC when the autopilot is first booted, the autopilot will immediately see the manual control signal and the throttle position and pass that along to the ESC as the first value, triggering the programming mode.<br />
<br />
==Does Paparazzi support digital servos?==<br />
:Of course. Digital servos use exactly the same electrical interface as their analog counterparts, the only difference being in the way they control the motor. Analog servos use a '''P'''roportional feedback loop, meaning the voltage sent to the motor is proportional to the difference between the measured and intended position of the arm. Digital servos use a '''P'''roportional + '''D'''erivative ('''PD''') feedback loop. The derivative term considers the current speed and direction of the servo as well as the speed and direction of the pilot's stick command. The derivative term will increase power to the motor if the servo is moving the wrong direction (providing faster direction changes) and will reduce/reverse power if the servo is near it's desired position but moving too fast (reducing overshoot). The net effect of this is that a digital servo can use a much stronger '''P''' term without risk of oscillation and overshoot because the '''D''' term is there to intelligently dampen it as needed and boost it whenever it can.<br />
:How does the inclusion of a '''D''' term make an analog servo become digital? Analog servos use a simple opamp to linearly relate the motor voltage to the difference between the potentiometer reading and PWM signal, whereas digital servos use a microprocessor to analyze the potentiometer position and velocity as well as the current and recent PWM signals to calculate the optimum voltage to send to the motor. <br />
:'''Important:''' Please be aware that autonomous flight involves ''continuous'' movement of all servos. Make sure your power supply is capable of handling this and that your servos are capable of continuous operation without overheating - especially if you use digital servos.<br />
<br />
==Can I solder wires directly to the autopilot instead of using the molex connectors?==<br />
:Yes. All of the molex headers are thru-hole and you can easily solder small gauge wire directly to the pins that protrude from these headers on the back of the board. It's important to note that '''standard servo wire cannot be soldered reliably''' in this fashion - you must use only high-grade wire intended for soldering (no vinyl insulation!). Direct soldering is not recommended, but it is possible ofcourse. See the [[Other_Hardware#Wiring|Wiring]] section for suggested wire types and sources. If you want to go the direct soldering path, be sure to you have '''excellent soldering skills''' and use high quality wiring.<br />
<br />
==What are the paparazzi failsafe features and how do I configure them?==<br />
See [[Failsafe]]<br />
<br />
==Why do I only get a blank (black) GCS==<br />
:The GCS stays blank until you get telemetry messages (either from the real aircraft or simulated) with the correct MD5 checksum meaning the autopilot has the correct and up to date flightplan/airframe/... programmed in it (in case of an MD5 problem you constantly get a lot of warnings in paparazzi center). <br />
:'''Solution''': Probably your telemetry is not set up correctly, this is most likely a [[XBee configuration]] issue.[[Subsystem/telemetry#Configure_Options|Configure the baudrate for your XBee connected to the autopilot]] and [[Subsystem/telemetry#Set_GCS_baud_rate|set the baudrate for the link to the one the ground XBee uses]] (They don't need to be the same). Also make sure your xbee cable is correct, transmit (tx) of xbee goes to receive (rx) on the autopilot and vice versa.<br />
<br />
==Why do I get a Failure("#of_world:no georef") when trying to load map tiles==<br />
:You get the georef error because the location is not initialized (probably GCS still blank and no aircraft are present). You can't get map tiles for nowhere...<br />
:'''Solution''': Set up your telemetry properly so you get messages from the aircraft OR start a simulation with the appropriate coordinates then load the map tiles.<br />
<br />
==How do I check if my telemetry is working?==<br />
:'''Solution''': Launch the link and messages tools in the Paparazzi Center. You should see the the messages coming in (blinking green) in the messages window.<br />
: If you get an the error ''Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")'' from ''link'', your modem is either not connected at all, or just available under a different device name. Check if you set the [[Installation#Setting_access_rights_for_USB_download|udev rules]] and if your modem becomes available under the device you set.<br />
: You might need to adjust the device and baud-rate of the link according to your setup, e.g. <tt>link -d /dev/ttyUSB0 -s 57600</tt><br />
: If you're stuck you can make ''link'' very verbose by setting the ''PPRZ_DEBUG'' environment variable to '' '*' ''<br />
<br />
==Why don't I get a GPS position?==<br />
:'''Problem''': Your GPS seems to be working, but you cannot get a valid position fix. Speed and course are displayed correctly, though. Possibly you also see Invalid_argument("Latlong.of_utm") errors on the GCS log.<br />
<br />
This may happen if you have configured the wrong GPS subsystem for your Tiny board.<br />
If you have the LEA-5H module on your Tiny board, but have configured<br />
<tt><subsystem name="gps" type="ublox_utm"/></tt><br />
in your airframe file, this will occur because the 5H module does not support UTM position.<br />
<br />
:'''Solution''': Make sure your GPS is [[GPS#GPS_configuration_using_U-Center|configured]] correctly and change the gps type to "<tt>ublox</tt>" if applicable.<br />
<br />
==Why do I get a CRITICAL **: murrine_style_draw_box: assertion `width >= -1' failed error message on starting the GCS==<br />
:'''Solution''': This error is not critical at all and can be safely ignored. <br />
It is triggered by a bug in the Murrine GTK engine in combination with the default theme which Ubuntu uses, as detailed here:<br />
https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/538499<br />
<br />
==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==<br />
:Currently, writing to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance. For this reason, no onboard datalogging is supported on current autopilots. If logging is needed on the aircraft (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed. Support for this is available in Paparazzi. For information, see [[Data Logger]].<br />
<br />
==Telemetry not working==<br />
:If you are receiving the error "Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")" <br />
:'''Solution''': You might need to add your user to the modems group (dialout), then log out and in again.<br />
:write in terminal:$ sudo adduser <user> dialout<br />
:it will be effective after your next login or simply write:<br />
:$newgrp dialout<br />
:hopefully this helps.<br />
|}<br />
<br />
[[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=FAQ&diff=15961FAQ2013-09-23T09:59:14Z<p>Mbina: /* What do MANUAL/AUTO1/AUTO2 stand for? */ => Add link</p>
<hr />
<div><noinclude><br />
{| width="100%" style="border: solid 2px #A3B1BF; background: #F5FAFF" |<br />
|-<br />
| <br />
<h2 style="background-color:#cedff2; border-bottom:0px; border: 1px solid #a3b0bf; text-align:center; padding-top:4px;">General Paparazzi FAQ<br />
</h2></noinclude><br />
<br/><!--TOC spacing--><br />
__NOTOC__ __TOC__<br />
<br />
==Is it possible to __________?==<br />
:Yes, of course! That's the beauty of an open-source system - virtually any feature or function you want can be added to the hardware and/or software.<br />
<br />
==How can I contribute?==<br />
:See the [[Contributing| how to contribute]] wiki page.<br />
<br />
==How do I check which Paparazzi Version I'm using==<br />
: Run ./paparazzi_version from you paparazzi directory.<br />
: This simple script will run ''git describe'' to find the next reachable tag and print something like ''v3.9.2_testing-1-g72f4b21''.<br />
: The output contains the most recent reachable tag, number of commits since then, SHA1 of that commit and whether the working directory was dirty.<br />
: If you have an older version of Paparazi that does not contain that script you can just run <tt>git describe --match "v[0-9].[0-9]*" --dirty --always --long</tt><br />
<br />
==What equipment and components are suggested==<br />
:Linux (Debian or Ubuntu) compatible or Apple Macintosh notebook computer, preferably with a very bright screen for outdoor use.<br />
:Most any airframe that will accommodate IR sensors and some extra weight and wiring - ''brushless motors are strongly suggested.'' See the [[Gallery|User's Gallery]] for some airframe examples.<br />
:[[Autopilots|Tiny]] autopilot from one of the [[Get_Hardware|Paparazzi vendors]] or build your own from the downloadable plans/gerbers<br />
:[[Infrared_Sensors|IR sensor (x-y)]] board from one of the [[Get_Hardware|Paparazzi vendors]]<br />
:[[Infrared_Sensors|IR sensor (z)]] board from one of the [[Get_Hardware|Paparazzi vendors]]<br />
:R/C Transmitter with a 3-position switch for selecting Manual/Stabilized/Auto. Some common models are listed in [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/conf/radios/ conf/radios]<br />
:R/C Receiver with an accessible PPM signal to tap. See: [[Other_Hardware#R.2FC_Receiver|Suggested R/C receivers]]<br />
:A pair of [[Modems]] along with any enclosures and antennas<br />
:[http://www.mouser.com/search/ProductDetail.aspx?R=TTL-232R-3V3virtualkey62620000virtualkey626-DLP-TTL-232R-3V3 FTDI USB-TTL] cable for connecting the modem to your USB port and/or for serial flashing of bootloader code or tunnel access to the GPS receiver<br />
:A standard [http://www.mouser.com/search/ProductDetail.aspx?R=68806-0019virtualkey53830000virtualkey538-68806-0019 Mini-B USB cable] and [http://www.mouser.com/search/productdetail.aspx?R=500075-0517virtualkey53810000virtualkey538-500075-0517 receptacle] for uploading firmware to the autopilot<br />
:Lots of [[Other_Hardware#Wiring|very durable wire, crimpers, and molex pins or pre-crimped wire.]]<br />
<br />
==Are internal combustion engines supported?==<br />
:Yes, not relying solely on inertial measurement, the Paparazzi system is very well suited for aircraft with high vibration levels. Care must be taken to prevent oily exhaust residue buildup on the IR sensors and a simple variable must be added to properly address the special idle/kill needs of an IC engine.<br />
<br />
==Can Paparazzi fly a glider?==<br />
:Sure. Paparazzi uses throttle and pitch to control climb rate by default. You can fit an airspeed sensor and adjust your airframe configuration to maintain airspeed instead.<br />
<br />
==Will the autopilot provide enough 5V power for many/large/digital servos as well as a modem, video TX, etc.?==<br />
:The [[Tiny]] includes a high capacity and high efficiency switching voltage regulator intended to power servos, modems, video systems and other payloads. This regulator should be preferred to power the servos rather than a linear regulator. While linear regulators may be rated for several amps, they require a great deal of cooling and can easily overheat with only a few hundred milliamps of continuous current without cooling. By comparison, the switching regulator included on the Tiny can work continuously at 2A with little or no cooling. Be careful using high power or digital servos consuming a lot of current. If you use four or more of them on your airframe it is recommended to supply them separately. It is important to realize that the servos in any stabilized aircraft will operate continuously. Therefore a power supply that powers the servos reliably in manual flight may easily overheat or produce critical voltage drops in autonomous flight.<br />
<br />
==Do I need a separate battery or regulator to isolate the autopilot, servos, video, modem, etc. from one another?==<br />
:The autopilot processor and sensors are powered by a 3.3V regulator and therefore are rather isolated from voltage fluctuations on the battery or 5V bus.<br />
<br />
==Can I use a Sirf, Trimble, etc. instead of the u-Blox GPS receiver?==<br />
:Yes, but it would require a tremendous amount of work as some of the navigation code is dependent on some of the UBX messages. NMEA does not provide messages in the desired form and substantial calculation would be required for conversion. Any of the other proprietary protocols would work but you would need to write your own protocol handler. u-Blox is one of the most expensive receivers on the market but offers great performance, size, and speed as well as the ability to easily configure the internal Kalman filter parameters to expect significant acceleration in 3-D space - a very important feature. If you find a more capable receiver, let the group know about it, but this is not the place to save $40.<br />
<br />
==Does Paparazzi use DGPS, WAAS, EGNOS, or MSAS?==<br />
:Most modern GPS receivers have the ability to process serial data sent from an external DGPS receiver, but the advent of WAAS/EGNOS has made the early ground-based DGPS transmitters nearly obsolete. The u-Blox GPS receiver supports all common SBAS systems (WAAS, EGNOS, and MSAS), as well as any standard form of external DGPS. It's important to understand that DGPS merely improves the ''accuracy'' of the position estimate by subtracting any static error. The only way to improve the ''precision'' of the GPS is by improving the antenna or the GPS module itself. See [http://en.wikipedia.org/wiki/Accuracy_and_precision Wikipedia:Accuracy and Precsion] for a detailed explanation of these terms.<br />
<br />
==How does the R/C receiver interface with the autopilot?==<br />
:Standard hobby R/C transmitters multiplex up to 9 channels of PWM servo data into a single PPM signal which is encoded onto an FM wave for transmission, this signal is then decoded by the RF section of the R/C receiver back into the original PPM signal containing 9 servo position PWM values. This signal is normally then sent to a demultiplexer (i.e. 4017) where it is separated into 9 individual servo signals on 9 individual pins. The Paparazzi autopilot intercepts the signal between the RF section and the demultiplexer and does its own demultiplexing, filtering, and processing before multiplexing the manual or autonomous servo commands back into a single signal and passing them to the 4017 to be distributed to the servos.<br />
<br />
==Why does Paparazzi tap directly into the R/C receiver instead of using individual servo signals?==<br />
:By connecting directly to the RF section of the R/C receiver we are able to obtain up to 9 channels of R/C servo data from a small, lightweight inexpensive 4 channel receiver with only 3 wires needed to connect the components. Furthermore, the autopilot then has direct access to the raw R/C signal where it can be filtered, evaluated, and assessed for quality. The autopilot can then alert the user of any loss of R/C signal as well as perform any pre-configured autonomous commands in response to a loss of signal.<br />
<br />
==Are PCM or 2.4GHz R/C systems compatible with Paparazzi?==<br />
:Yes. Some receivers have the signal available for tapping into the input pin with success and can thus be modified to get the required PPM signal. A general rule of thumb is that if you see any type of demultiplexer on your R/C receiver, you can look up the data sheet for it and likely tap into the input pin with success. Some information on compatible R/C receivers and how to find the PPM signal of your own receiver is given in the [[Other_Hardware#R.2FC_Receiver|RC receiver]] section.<br />
<br />
:If that's not possible, you can use the available PPM encoder board, to re-multiplex the servo channels into one PPM signal. This seems to be a common solution.<br />
<br />
==What R/C transmitters are compatible?==<br />
:No mixing or programming is done in the transmitter so even the simplest models will suffice but one important requirement is a 3-position switch to select among the three autopilot modes: manual, stabilized only, and fully autonomous. Those handy with electronics can replace a dial with a switch and resistor if needed. The transmitter's PPM values need to be recorded and the channel used to control the autopilot mode must be stated. Some commonly used transmitter configuration files are provided in the [http://cvs.savannah.gnu.org/viewvc/paparazzi/paparazzi3/conf/radios/ conf/radios] folder and the syntax of these files is easy to follow for those using other brands or models.<br />
<br />
==Can a gamepad/joystick be used to control the aircraft through the modem?==<br />
:Yes, the code to do this was written some time ago though it was not tested in flight due to latency concerns with the primitive [[Modems#Coronis_WaveCard|Coronis]] modems used at the time. Any of the [[modems]] currently recommended should work well in this manner but the theoretical reliability is still questionable due to the fact that no interrupt or prioritization structure exists for the telemetry data so any manual control inputs would be lumped in with the rest of the data to be lost or delayed as needed.<br />
<br />
==What do MANUAL/AUTO1/AUTO2 stand for?==<br />
Documented at [[AutopilotModes]]<br />
<br />
:Those are the three modes that Paparazzi can operate in. MANUAL is for controling your airframe by your Transmitter yourself. Please note that any trims and deflections set in your airframe config file still apply. AUTO1 is stabilized flight, the autopilot will keep the airframe level and stabilized, but you need to steer the airframe youself where you want it to go. AUTO2 is fully autonomous stabilization and navigation, where you do not need steer or anything.<br />
<br />
==What Electronic Speed Controllers (ESC) are compatible?==<br />
:Any controller can be used, the exact PWM value that is sent to the controller for 0-100% throttle is completely configurable in the airframe file so all controllers are compatible and any controller will arm properly with or without the use of an R/C transmitter. Upon each boot, the autopilot immediately sends whatever you have defined as 0% throttle (typically around 1200ms) and maintains that signal until a manual or autonomous command is given. Most modern controllers are "auto calibrating" which is an undesirable feature for R/C pilots and even more so for autonomous systems but can be dealt with. The calibration is done by defining the PWM value at boot to be 0% power and then defining some initial arbitrary mid-range value such as 1500ms to be 100% until a higher value is seen. The net result of this behavior is that the motor is given full power at any command above 50% throttle until 100% throttle has actually been commanded at least once. This is not an issue for planes that routinely take off at 100% throttle but can disrupt the throttle tuning and altitude control on any flights where 100% throttle has never been commanded. [http://www.castlecreations.com/products/products_fly.html Castle Creations Electronic Speed Controllers] can be configured for "fixed endpoints" so the ESC does not need to "learn" the endpoints at first takeoff this providing a consistent and predictable throttle response. By default this range 1250-1850ms but can be set at different values where needed.<br />
<br />
==Can traditional throttle stick programming be done on the ESC once connected to the autopilot?==<br />
:Yes. If the transmitter is on with the throttle at full or whatever is required for your ESC when the autopilot is first booted, the autopilot will immediately see the manual control signal and the throttle position and pass that along to the ESC as the first value, triggering the programming mode.<br />
<br />
==Does Paparazzi support digital servos?==<br />
:Of course. Digital servos use exactly the same electrical interface as their analog counterparts, the only difference being in the way they control the motor. Analog servos use a '''P'''roportional feedback loop, meaning the voltage sent to the motor is proportional to the difference between the measured and intended position of the arm. Digital servos use a '''P'''roportional + '''D'''erivative ('''PD''') feedback loop. The derivative term considers the current speed and direction of the servo as well as the speed and direction of the pilot's stick command. The derivative term will increase power to the motor if the servo is moving the wrong direction (providing faster direction changes) and will reduce/reverse power if the servo is near it's desired position but moving too fast (reducing overshoot). The net effect of this is that a digital servo can use a much stronger '''P''' term without risk of oscillation and overshoot because the '''D''' term is there to intelligently dampen it as needed and boost it whenever it can.<br />
:How does the inclusion of a '''D''' term make an analog servo become digital? Analog servos use a simple opamp to linearly relate the motor voltage to the difference between the potentiometer reading and PWM signal, whereas digital servos use a microprocessor to analyze the potentiometer position and velocity as well as the current and recent PWM signals to calculate the optimum voltage to send to the motor. <br />
:'''Important:''' Please be aware that autonomous flight involves ''continuous'' movement of all servos. Make sure your power supply is capable of handling this and that your servos are capable of continuous operation without overheating - especially if you use digital servos.<br />
<br />
==Can I solder wires directly to the autopilot instead of using the molex connectors?==<br />
:Yes. All of the molex headers are thru-hole and you can easily solder small gauge wire directly to the pins that protrude from these headers on the back of the board. It's important to note that '''standard servo wire cannot be soldered reliably''' in this fashion - you must use only high-grade wire intended for soldering (no vinyl insulation!). Direct soldering is not recommended, but it is possible ofcourse. See the [[Other_Hardware#Wiring|Wiring]] section for suggested wire types and sources. If you want to go the direct soldering path, be sure to you have '''excellent soldering skills''' and use high quality wiring.<br />
<br />
==What are the paparazzi failsafe features and how do I configure them?==<br />
See [[Failsafe]]<br />
<br />
==Why do I only get a blank (black) GCS==<br />
:The GCS stays blank until you get telemetry messages (either from the real aircraft or simulated) with the correct MD5 checksum meaning the autopilot has the correct and up to date flightplan/airframe/... programmed in it (in case of an MD5 problem you constantly get a lot of warnings in paparazzi center). <br />
:'''Solution''': Probably your telemetry is not set up correctly, this is most likely a [[XBee configuration]] issue.[[Subsystem/telemetry#Configure_Options|Configure the baudrate for your XBee connected to the autopilot]] and [[Subsystem/telemetry#Set_GCS_baud_rate|set the baudrate for the link to the one the ground XBee uses]] (They don't need to be the same). Also make sure your xbee cable is correct, transmit (tx) of xbee goes to receive (rx) on the autopilot and vice versa.<br />
<br />
==Why do I get a Failure("#of_world:no georef") when trying to load map tiles==<br />
:You get the georef error because the location is not initialized (probably GCS still blank and no aircraft are present). You can't get map tiles for nowhere...<br />
:'''Solution''': Set up your telemetry properly so you get messages from the aircraft OR start a simulation with the appropriate coordinates then load the map tiles.<br />
<br />
==How do I check if my telemetry is working?==<br />
:'''Solution''': Launch the link and messages tools in the Paparazzi Center. You should see the the messages coming in (blinking green) in the messages window.<br />
: If you get an the error ''Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")'' from ''link'', your modem is either not connected at all, or just available under a different device name. Check if you set the [[Installation#Setting_access_rights_for_USB_download|udev rules]] and if your modem becomes available under the device you set.<br />
: You might need to adjust the device and baud-rate of the link according to your setup, e.g. <tt>link -d /dev/ttyUSB0 -s 57600</tt><br />
: If you're stuck you can make ''link'' very verbose by setting the ''PPRZ_DEBUG'' environment variable to '' '*' ''<br />
<br />
==Why don't I get a GPS position?==<br />
:'''Problem''': Your GPS seems to be working, but you cannot get a valid position fix. Speed and course are displayed correctly, though. Possibly you also see Invalid_argument("Latlong.of_utm") errors on the GCS log.<br />
<br />
This may happen if you have configured the wrong GPS subsystem for your Tiny board.<br />
If you have the LEA-5H module on your Tiny board, but have configured<br />
<tt><subsystem name="gps" type="ublox_utm"/></tt><br />
in your airframe file, this will occur because the 5H module does not support UTM position.<br />
<br />
:'''Solution''': Make sure your GPS is [[GPS#GPS_configuration_using_U-Center|configured]] correctly and change the gps type to "<tt>ublox</tt>" if applicable.<br />
<br />
==Why do I get a CRITICAL **: murrine_style_draw_box: assertion `width >= -1' failed error message on starting the GCS==<br />
:'''Solution''': This error is not critical at all and can be safely ignored. <br />
It is triggered by a bug in the Murrine GTK engine in combination with the default theme which Ubuntu uses, as detailed here:<br />
https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/538499<br />
<br />
==Do Paparazzi autopilots support onboard datalogging with an uSD or SD card?==<br />
:Currently, writing to an SD card takes a considerable amount of processor resources, enough to significantly impact critical timings and autopilot performance. For this reason, no onboard datalogging is supported on current autopilots. If logging is needed on the aircraft (say for use without a datalink) then a second board that "sniffs" the datalink telemetry is needed. Support for this is available in Paparazzi. For information, see [[Data Logger]].<br />
<br />
==Telemetry not working==<br />
:If you are receiving the error "Failure("Error opening modem serial device : fd < 0 (/dev/ttyUSB0)")" <br />
:'''Solution''': You might need to add your user to the modems group (dialout), then log out and in again.<br />
:write in terminal:$ sudo adduser <user> dialout<br />
:it will be effective after your next login or simply write:<br />
:$newgrp dialout<br />
:hopefully this helps.<br />
|}<br />
<br />
[[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=AutopilotModes&diff=15960AutopilotModes2013-09-23T09:56:31Z<p>Mbina: </p>
<hr />
<div>__TOC__<br />
<br />
<br />
This page describes the three modes paparazzi can operate in.<br />
The current mode paparazzi operates in can be changed via the [[GCS]].<br />
<br />
== Manual ==<br />
<br />
The '''MANUAL''' flight mode is for directly controling your airframe by your transmitter. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Please note that any trims and deflections set in your airframe config file still apply.<br />
<br />
When flying in Manual mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 1 ==<br />
<br />
The '''AUTO1''' is for controller stabilized flight. <br />
<br />
Although the autopilot will keep the airframe level and stabilized, you need to steer the airframe yourself, ie. where you want it to go.<br />
<br />
When flying in Auto 1 mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 2 ==<br />
<br />
In '''AUTO2''' your aircraft is fully autonomous in stabilization and navigation. <br />
<br />
You are not required to steer or stabilize the aircraft via your [[Radio_Control|radio]].<br />
<br />
In this mode the aircraft follows the [[Flight_Plans|flightplan]] and - as always - commands issued via the [[GCS]].</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=AutopilotModes&diff=15959AutopilotModes2013-09-23T09:55:47Z<p>Mbina: </p>
<hr />
<div><br />
__TOC__<br />
<br />
<br />
This page describes the three modes paparazzi can operate in.<br />
The current mode paparazzi operates in can be changed via the [[GCS]].<br />
<br />
== Manual ==<br />
<br />
The '''MANUAL''' flight mode is for directly controling your airframe by your transmitter. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Please note that any trims and deflections set in your airframe config file still apply.<br />
<br />
When flying in Manual mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 1 ==<br />
<br />
The '''AUTO1''' is for controller stabilized flight. <br />
<br />
Although the autopilot will keep the airframe level and stabilized, you need to steer the airframe yourself, ie. where you want it to go.<br />
<br />
When flying in Auto 1 mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 2 ==<br />
<br />
In '''AUTO2''' your aircraft is fully autonomous in stabilization and navigation. <br />
<br />
You are not required to steer or stabilize the aircraft via your [[Radio_Control|radio]].<br />
<br />
In this mode the aircraft follows the [[Flight_Plans|flightplan]] and commands issued via the [[GCS]].</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Simulation&diff=15958Simulation2013-09-23T09:55:21Z<p>Mbina: syntax highlighting</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Simulation</categorytree><br />
__TOC__<br />
<br />
This page describes the steps needed to run a simulated flight with an UAS.<br />
<br />
== Available Simulators ==<br />
<br />
Paparazzi currently has three different simulator "backends" for a '''F'''light '''D'''ynamic '''M'''odel (FDM) with varying degrees of realism and intended purpose:<br />
A FDM is a set of mathimatical equations used to calculate the physical forces acting on a simulated aircraft, such as thrust, lift, and drag.<br />
<br />
The three are: <br />
<br />
# '''sim''': The basic fixedwing simulator written in OCaml.<br />
# '''jsbsim''': More advanced fixedwing simulator using [[JSBSim]] for the FDM. More details [[Simulation#JSBSim|further down on this page]].<br />
# '''nps''': [[NPS]] is an advanced rotorcraft simulator with sensor models and currently also uses [[JSBSim]] as FDM. Other FDM's can be integrated easily.<br />
<br />
== Compiling and starting ==<br />
<br />
From the [[Paparazzi_Center|Paparazzi Center]] select the Microjet aircraft (from the '''A/C''' combo box) which is configured with the <tt>basic.xml</tt> flight plan. From the '''Target''' combo box, select <tt>sim</tt> and click the '''Build''' button to compile the airbone code to be run on your Linux box. From the '''Session''' combo box, select <tt>Simulation</tt> entry and click '''Execute''' to start the simulation. It will start <br />
three processes which are listed in the window below:<br />
* '''Microjet''' is the interface of a simulator program. It runs the same code as the one for the autopilot processor plus a rudimentary flight dynamic model. it allows you to test the interactions with the UAV and the flight plan execution.<br />
* '''GCS''' ([[GCS|Ground Control Station]]) is the main window. It displays the track of the aircraft, as well as informations about the execution of its flight plans. This program provide menus for the datalink functions and is able to edit a flight plan.<br />
* '''Server''' is a hidden process which won't be described here (see [[Overview|the architecture of the system]])<br />
<br />
== Start the Simulation ==<br />
<br />
The aircraft has automatically been booted, as if the autopilot board had been powered. Its position and its flight parameters are displayed in the GCS window. If you omit the -boot option of the sim the aircraft is not automatically booted and you can first place the aircraft where you want it to start from and then boot.<br />
<br />
The map widget is able use many map formats and display them according to many projections. To make things simple, we start by using images from [http://maps.google.com Google]. From the toolbar in the top right corner of the GCS, click the Google Earth icon ('''Google maps fill'''). The program attempts to download the required satellite images from the Google servers. If it succeeds, you should now see the nice countryside of Muret (a city close to Toulouse, France). Navigation and other features of the map are described on the [[GCS#map|GCS]] page.<br />
<br />
The lower part of the GCS displays the flight plan in a tree view. You see that the current flight plan is composed of several ''blocks'':<br />
* '''wait GPS''' and '''geo init''' which are instructions to run this flight plan anywhere in the world, by translating the waypoints around the current location of aircraft as soon as it is reported by the GPS.<br />
* '''Holding point''' (it should be the current active block) which instructs the autopilot to wait for launch. <br />
* '''Takeoff''' which will instruct the aircraft to climb full throttle to a security altitude<br />
* '''Standby''' which is a simple circle around the '''STDBY''' waypoint.<br />
<br />
Switch to the '''Takeoff''' block by a double click on the line or using the corresponding button (an icon figuring an airway) on the left side of the strip.<br />
<br />
== Fly ==<br />
<br />
In the Simulator ('''Microjet''' window), press the '''Launch''' button to simulate a hand launch or click the launch button in the GCS (the green aircraft icon). The autopilot detects the launch by monitoring the groundspeed. The flight time (in the aircraft label on the GCS) then starts to count.<br />
<br />
Position of the aircraft is displayed on the map: the aircraft goes to the '''CLIMB''' waypoint (to the norht-west) and then around the '''STDBY''' waypoint. Current block also changes accordingly in the flight plan display.<br />
<br />
The orange triangle (the carrot) on the map is the point that the aircraft is navigating toward.<br />
<br />
== Line ==<br />
<br />
Jump to this block with double-click on the <tt>Line 1-2</tt> line in the flight plan or using the corresponding button in the strip (figuring a blue line between two white points). The aircraft will try to follow a line joining the waypoints '''1''' and '''2''', doing nice U-turns at both ends.<br />
<br />
=== Move waypoints ===<br />
<br />
While the aircraft is flying (or here while the simulator is integrating differential equations), you can move the waypoints on the GCS interface by cliking and dragging (with the left button). When the mouse button is released, a popup window allows you to change the altitude of the waypoint. After validation, the waypoint changes are sent to the autopilot and the followed track is changed accordingly.<br />
<br />
=== Coming back around ===<br />
<br />
Select the '''Standby''' block (the ''home'' blue icon) to instruct the aircraft to fly around the '''STDBY''' waypoint.<br />
<br />
== Fly too far ==<br />
<br />
If you unzoom the map (using the PageDown key or he mouse wheel), you will see a large circle around the waypoints. This circle show the allowed flying zone that the autopilot must not leave or it will enter an emergency navigation mode and circles the '''HOME''' waypoint until the further direction is received.<br />
<br />
Move the waypoint '''2''' out of this circle (close to the circle in the north-east corner) and switch back to the 'Line 1-2''' block to force the plane to get out of this safety zone.<br />
<br />
The aircraft flies to the '''2''' waypoint, cross the protection enveloppe and switches to ''home'' mode: the AP mode in the aircraft strip switches from '''AUTO2''' to '''HOME'''.<br />
<br />
To get out of this mode and switch back to the default '''AUTO2''', click on the '''AUTO2''' button in the aircraft strip. The aircraft then flies again towards '''too far''' and again swithes to '''HOME''' mode.<br />
<br />
== Change the environment ==<br />
<br />
Launch the '''Environment Simulator''' from the '''Tools' menu in the '''Paparazzi Center'''.<br />
<br />
This interface (also called'''Gaia''') allows the user to change:<br />
* The wind: Set up a wind speed of 5m/s and observe the trajectory and the speed evolution (in the aircraft strip and in the '''PFD''' page of the notebook).<br />
* The GPS coverage: Shut down the GPS ('''GPS OFF''') and observe the resulting mode ('''NO_GPS''') and trajectory. In this mode, the autopilot uses the failsafe roll, pitch and throttle settings defined in the airframe file. Note that in a real flight, an aircraft without GPS won't be able to send its position ... The simulation is cheating here !<br />
* The time scale: If you are in a hurry ... Do not use a time higher than 2 for this first demonstration.<br />
<br />
== Other navigation patterns ==<br />
<br />
Using the buttons in the strip, you can play with other navigation patterns: figure of eights, oval, survey of a rectangle (with a north-south sweeping), ''Turn around here'' (which sets a waypoint to the current location of the plane and flies a circle around).<br />
<br />
== Landing ==<br />
<br />
To automatically land the aircraft:<br />
* Set the '''TD''' (Touch Down) waypoint where you want to land. Be sure that the waypoint is on the ground (185m in Muret)<br />
* Set the '''AF''' (Approach Fix) waypoint where you want to start the final descent (the ''glide''). If you have set some wind with Gaia, you probably want to fly '''AF-TD''' upwind (an estimation of the wind experienced by the aircraft is displayed in the left-upper corner of the map).<br />
* Switch to the '''Land right''' or the '''Land left''' block (icons in the strip) according to the direction of the last turn you want to do (for example, if '''AF''' is on the east side of '''TD''' and you want to maneuvre from the north, choose a '''Land right''') <br />
<br />
== Multiple UAV Simulation ==<br />
<br />
To simulate multiple aircrafts, you just have to launch a second simulator (tools->simulator, then -a yourairframe) and the server and the GCS should take care of the rest.<br />
<br />
== View the simulation in Flight Gear ==<br />
<br />
To view the simulation in [[FlightGear]], do the following:<br />
* [[FlightGear|install Flight Gear]]<br />
* In Paparazzi Center, add the option <tt>-fg 127.0.0.1</tt> (replace the IP address if FG is running on another host as appropriate) to the Simulator line and restart it:<br />
<path_to_paparazzi>/sw/simulator/launchsitl -a <your_ac_name> -boot -norc -fg 127.0.0.1<br />
* Launch Flight Gear with the following command:<br />
fgfs --fdm=null --native-gui=socket,in,30,,5501,udp<br />
<br />
For Flight Gear visualization, version 2.6 or greater is best. If you wish to use version 2.4 or lower, you must add the following to the firmware section of your airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<define name="FG_2_4" value="1"/><br />
...<br />
</firmware><br />
</source><br />
}}<br />
<br />
=== Why is it night in Flight Gear, if my sim is flying during the day? ===<br />
The time that is sent to Flight Gear is hard coded into the code, so if you try to view the output of the simulation and your simulated flight is located far from France, in Flight Gear, everything may be dark. If your simulated flight is in France, then you will always have daylight in Flight Gear. <br />
<br />
If you have flightgear 2.4 or higher adding the command line option<br />
<br />
--timeofday=noon<br />
<br />
to your flightgear options might solve your issue. <br />
<br />
If not, then fix this, do the following (you will need to have paparazzi-dev installed to do this):<br />
<br />
* Get the Unix time during your '''local daylight hours''' by running the following command in your terminal:<br />
date +%s<br />
* In the file: paparazzi/sw/simulator/fg.c find the line(line 44):<br />
msg.cur_time = 3213092700ul;//time(NULL);<br />
* Paste the output from "date +%s" in place of "3213092700"<br />
* Now you will have to rebuild paparazzi, so in the terminal change to the paparazzi directory and run:<br />
make clean<br />
make<br />
* In Paparazzi Center clean and rebuild your simulation<br />
* Launch the simulation and Flight Gear, and Flight Gear should be flying in daylight.<br />
<br />
== JSBSim ==<br />
Paparazzi can work with [http://jsbsim.sourceforge.net/ JSBSim], a great open source flight dynamics library.<br />
<br />
==== For a fixed wing aircraft: ====<br />
<br />
[[JSBSim|Install JSBSim]].<br />
<br />
In your airframe file add the following section:<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="SIMU"><br />
<define name="JSBSIM_MODEL" value="Malolo1"/><br />
<define name="JSBSIM_IR_ROLL_NEUTRAL" value="RadOfDeg(0.)"/><br />
<define name="JSBSIM_IR_PITCH_NEUTRAL" value="RadOfDeg(0.)"/><br />
</section><br />
</source><br />
}}<br />
<br />
In this case, the JSBSim model used is <tt>conf/simulator/Malolo1</tt>. To create your own model make a new directory under <tt>conf/simulator</tt> and put your JSBSim model there, and adapt the <tt>"JSBSIM_MODEL"</tt> in the <tt>SIMU</tt> section accordingly.<br />
<br />
Add another target to the <tt>"fixedwing"</tt> <tt>firmware</tt> section of your airframe file:<br />
<source lang="xml"><target name="jsbsim" board="pc" /></source><br />
<br />
Now you can can compile the airframe for the jsbsim target. Launch the simulator as normal, but add the option <tt>-jsbsim</tt>. Note that FlightGear visualization can be used in conjunction with the JSBSim simulation, just be sure to add the <tt>-fg 127.0.0.1</tt> option as described [[Simulation#View_the_simulation_in_Flight_Gear|above]]. Using both JSBSim and FlightGear, it would be:<br />
<source lang="xml"><paparazzi home directory>/sw/simulator/launchsitl -a <aircraft_name> -jsbsim -boot -norc -fg 127.0.0.1</source><br />
<br />
You will notice the default control parameters do not fly the Malolo1 airframe particularly well.<br />
<br />
The Microjet aircraft can be used as an example; it has the right target and <tt>"SIMU"</tt> section added.<br />
<br />
==== Using Optional Parameters ====<br />
<br />
There are a few optional parameters that can be used with a JSBSim simulation.<br />
<br />
The initial body-aligned forward speed of the aircraft in m/s can be specified in the <tt>"SIMU"</tt> section of the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="SIMU"><br />
...<br />
<define name="JSBSIM_LAUNCHSPEED" value="15.0"/><br />
...<br />
</section><br />
</source><br />
}}<br />
<br />
The '''i'''nitial '''c'''onditions for the simulation can be set with an initialization xml document. Add the following to the <tt>"SIMU"</tt> section of the airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="SIMU"><br />
...<br />
<define name="JSBSIM_INIT" value="Malolo1-IC"/><br />
...<br />
</section><br />
</source><br />
}}<br />
In this case, the initialization file for the Malolo1 used is <tt>conf/simulator/Malolo1/Malolo1-IC.xml</tt>. To create your own initialization file, use this file as an example, place the file into your JSBSim model directory, and adapt <tt>"JSBSIM_INIT"</tt> in the <tt>SIMU</tt> section accordingly.<br />
<br />
These options are demonstrated in the jsbsim.xml example airframe file in <tt>/conf/airframes/jsbsim.xml</tt>. The control parameters in this example are much better in controlling the Malolo1 airframe.<br />
<br />
[[Category:Simulation]] [[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=AutopilotModes&diff=15957AutopilotModes2013-09-23T09:48:20Z<p>Mbina: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilot Modes</categorytree><br />
__TOC__<br />
<br />
<br />
This page describes the three modes paparazzi can operate in.<br />
The current mode paparazzi operates in can be changed via the [[GCS]].<br />
<br />
== Manual ==<br />
<br />
The '''MANUAL''' flight mode is for directly controling your airframe by your transmitter. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Please note that any trims and deflections set in your airframe config file still apply.<br />
<br />
When flying in Manual mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 1 ==<br />
<br />
The '''AUTO1''' is for controller stabilized flight. <br />
<br />
Although the autopilot will keep the airframe level and stabilized, you need to steer the airframe yourself, ie. where you want it to go.<br />
<br />
When flying in Auto 1 mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 2 ==<br />
<br />
In '''AUTO2''' your aircraft is fully autonomous in stabilization and navigation. <br />
<br />
You are not required to steer or stabilize the aircraft via your [[Radio_Control|radio]].<br />
<br />
In this mode the aircraft follows the [[Flight_Plans|flightplan]] and commands issued via the [[GCS]].</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=AutopilotModes&diff=15956AutopilotModes2013-09-23T09:47:57Z<p>Mbina: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilot Modes</categorytree><br />
__TOC__<br />
<br />
<br />
This page describes the three modes paparazzi can operate in.<br />
The current mode paparazzi operates in can be changed via the [[GCS]].<br />
<br />
== Manual ==<br />
<br />
The '''MANUAL''' flight mode is for directly controling your airframe by your transmitter. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Please note that any trims and deflections set in your airframe config file still apply.<br />
<br />
When flying in Manual mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 1 ==<br />
<br />
The '''AUTO1''' is for controller stabilized flight. <br />
<br />
Although the autopilot will keep the airframe level and stabilized, you need to steer the airframe youself, ie. where you want it to go.<br />
<br />
When flying in Auto 1 mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 2 ==<br />
<br />
In '''AUTO2''' your aircraft is fully autonomous in stabilization and navigation. <br />
<br />
You are not required to steer or stabilize the aircraft via your [[Radio_Control|radio]].<br />
<br />
In this mode the aircraft follows the [[Flight_Plans|flightplan]] and commands issued via the [[GCS]].</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=AutopilotModes&diff=15955AutopilotModes2013-09-23T09:47:13Z<p>Mbina: Inital commit</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilot Modes</categorytree><br />
__TOC__<br />
<br />
<br />
This page describes the three modes paparazzi can operate in.<br />
The current mode paparazzi operates in can be changed via the [[GCS]].<br />
<br />
== Manual ==<br />
<br />
The '''MANUAL''' flight mode is for directly controling your airframe by your transmitter. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Please note that any trims and deflections set in your airframe config file still apply.<br />
<br />
When flying in Manual mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 1 ==<br />
<br />
The '''AUTO1''' is for controller stabilized flight. Although autopilot will keep the airframe level and stabilized, you need to steer the airframe youself, ie. where you want it to go.<br />
<br />
When flying in Auto 1 mode please consider the [[Failsafe#RC_link_failure_while_manual_or_AUTO1|failsafes]].<br />
<br />
== Auto 2 ==<br />
<br />
In '''AUTO2''' your aircraft is fully autonomous in stabilization and navigation. <br />
<br />
You are not required to steer or stabilize the aircraft via your [[Radio_Control|radio]].<br />
<br />
In this mode the aircraft follows the [[Flight_Plans|flightplan]] and commands issued via the [[GCS]].</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Failsafe&diff=15954Failsafe2013-09-23T09:28:04Z<p>Mbina: Added link for catastrophic battery level to battery config</p>
<hr />
<div>Paparazzi has several built-in failsafe features ranging from lowlevel to highlevel and from implied to optional.<br />
<br />
On the lowest level, precise timing of the transmitter pulses creates safety that goes beyond traditional switches enabling safer use of old RC equipment.<br />
On the highest level, the [[Flight_Plans#Exceptions|exceptions]] feature of the flight-plans allow for very flexible custom built failsafe features.<br />
<br />
<br />
== Fly By Wire (FBW) ==<br />
<br />
=== 'Failsafe Switch' ===<br />
<br />
The lowest level of paparazzi is the FBW (Fly By Wire) controller that reads the RC, reads the autopilot commands and drives the servos based on the lowlevel failsafe options.<br />
<br />
This is the 'switch' between '''manual''' or '''automatic''' modes. Therefore there is no need for another failsafe board. Indeed, the paparazzi FBW has evolved with so much intelligence that it is certainly safer than some and probably at least as safe as any other failsafe switches. This is amongst others (besides the highlevel validated code, separated process, ...) because paparazzi FBW unlike generic switches is given precise remote control information in its RC.xml. If you use a wrong type of transmitter (e.g. not the right amount of channels, or not the correct interval or sync pulse length) then even when on the same frequency the FBW will not listen to the commands. Also, if 2 transmitters are on the same frequency, then the chance of both signals together still being read as valid is very small. (This does NOT mean you can fly with 2 planes on the same frequency however. This only means that in this catastrophic scenario paparazzi does a pretty good job in delaying disaster from happening. )<br />
<br />
Be aware that there exist many failsafe switches that use a pulse of the RC (e.g. channel 5) to switch <br />
between autopilot or RC. When using analog RC equipment or any equipment that does not have correctly <br />
programmed failsafe servo values this is very unsafe as whenever the RC is out of range the switch will <br />
start switching back and forth putting the UAV out of control even if the autpilot is perfectly OK.<br />
<br />
<span style="color:#FF0000">'''CAUTION!'''</span> Common receivers today (especially 2.4GHz receivers) has own failsafe mode(s).<br />
Three modes are used in most cases:<br />
<br />
# No failsafe: the receiver will switch off servo sinals in case of RC connection lost.<br/>Paparazzi own failsafe will be activated in case of RC connection lost.<br />
# Last position: the receiver will keep the last valid servo positions in case of RC connection lost.<br/>Paparazzi own failsafe will NOT be activated. (The autopilot will not have information on RC signal lost.)<br />
# Preset servo positions: the receiver will switch servo sinals to a preset value in case of RC connection lost.<br/>This values should be set directly in the receiver. (Read manual.) Paparazzi own failsafe will not be activated.<br/>BUT! If you set the failsafe value of the channel used for Mode control(Manual/Auto1/Auto2) to the value which commands Auto2, then paparazzi will switch automaticaly to Auto2 mode in case of RC connection lost.<br />
<br />
=== FBW logic ===<br />
<br />
* RC GOOD: listen to the MODE switch on the Transmitter<br/>(this means whenever the remote control is close enough the pilot has the final word)<br />
* RC BAD: go to automatic mode (see further on for handling of automatic modes)<br />
* RC BAD AND AUTOPILOT DATA TIMEOUT: failsafe command values from airframe configuration XML<br/>(do not omit to fill in useful failsafe values in the command section; usually slight pitch up for minimal speed, ailerons neutral in order not to roll inverted and of course throttle down: it is not recommended to try to make turns here with aileron deflections. A small rudder deflection on the other hand is recommended when available )<br />
<br />
== AutoPilot (AP) ==<br />
<br />
=== Home mode ===<br />
<br />
The HOME mode is a failsafe mode where the standard navigation (own flightplan) is suspended and the aircraft <br />
flies a circle around the HOME waypoint at a safe altitude (''security_height'' attribute in your flight-plan). This mode is triggered on different events. <br />
Leaving this mode is done by clicking on the red HOME text in the GCS.<br />
<br />
==== Too far from HOME ====<br />
<br />
Home mode is triggered if the distance to the HOME waypoint is greater than a threshold ('''max_dist_from_home''' attribute) set in the <br />
fight-plan (displayed as a circle on the GCS map).<br />
<br />
==== RC link failure while manual or AUTO1 ====<br />
<br />
Home mode is triggered if the RC uplink is lost in '''MANUAL''' or '''AUTO 1''' modes.<br />
<br />
* When '''MANUAL''' the manual mode is restored as soon as the RC link is restored as expected.<br />
* However: In '''AUTO 1''' mode, one must manually leave the HOME mode using the GCS<br />
<br />
! Word of caution with respect to '''AUTO1''': <br />
When flying auto1 with a lot of RC interference (which is not recommended anyway), be prepared that the plane might enter HOME mode.<br />
Also, do not be tempted to fly far away in auto1 mode (possibly out of RC range) without a fully tuned auto2 autopilot or sufficient visual contact to allow manual control. As soon as you are so far that RC packets get lost, paparazzi will switch to HOME and will stay in HOME until you choose MANUAL of re-enable AUTO1 on the GCS !<br />
<br />
===== Setting RC lost mode =====<br />
<br />
By default when RC is lost (in Manual or Auto1) HOME mode is triggered, you can change this behaviour by setting the RC_LOST_MODE:<br />
<br />
<source lang="xml" ><br />
<define name="RC_LOST_MODE" value="PPRZ_MODE_AUTO2"/><br />
</source><br />
<br />
In this example RC_LOST_MODE is set to AUTO2, which can be useful if you experience glitches on your RC on the mode channel and want the aircraft to continue the mission instead of triggering HOME mode. '''BUT''' only use this if you have AUTO2 navigation set up properly and everything is initialized correctly! Another scenario to set this value is if you will fly out of your RC range in a long range mission.<br />
<br />
You can disable HOME mode locking by adding the following line in your airframe file:<br />
<br />
<source lang="xml"><br />
<define name="UNLOCKED_HOME_MODE" value="TRUE"/><br />
</source><br />
<br />
Then you can restore from HOME mode using the RC and do not need to do this on the GCS if in AUTO1.<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Use these two settings with care, as they might deteriorate the failsafe security of your aircraft.<br />
<br />
=== Kill mode ===<br />
<br />
In this mode the throttle is killed (this is the default mode when switching on the autopilot). You can enter this mode manually with the kill button (with confirmation). <br />
Kill mode is also triggered in the following cases:<br />
* Catastrophic battery level<br />
* Way too far from HOME<br />
<br />
<span style="color:#FF0000">'''TODO: '''</span> Complete the list. [MB]<br />
<br />
==== Catastrophic battery level ====<br />
<br />
If the battery level goes under the catastrophic low level (defined in the airframe file):<br />
{{Box Code|myairframefile.xml|<br />
<source lang="xml"><br />
<section name="BAT"><br />
...<br />
<define name="CATASTROPHIC_BAT_LEVEL" value="9.0" unit="V" /><br />
...<br />
</section><br />
</source><br />
}}<br />
<br />
More about battery related settings can be found at [[Airframe_Configuration#Battery]]<br />
<br />
==== Way too far from HOME ====<br />
<br />
The plane goes into kill mode if it is too far away from the HOME waypoint. You can configure this '''KILL_MODE_DISTANCE''' in your airframe file:<br />
<br />
<source lang="xml"><br />
<section name="MISC"><br />
...<br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
...<br />
</section><br />
</source><br />
<br />
In this example it is set to 1.5 times the '''max_dist_from_home''' (attribute set in your flight plan).<br />
<br />
=== GPS signal lost ===<br />
<br />
In this mode, the autopilot uses the failsafe roll, pitch and throttle settings defined in the airframe file. It is recommended to disable throttle and make a shallow turn at low flight speed. When barometric information is available and compass heading information, it is recommended to disable this safety mode and train the GCS operator to bring the plane home on heading and altitude only. <br />
<br />
Do not mix up the <commands> failsafe_value and the <section name="FAILSAFE" prefix="FAILSAFE_"> default values. The first result in fixed servo positions with the plane totally out of control, while the latter still involve the innerloop to stabilize the plane. <br />
<br />
=== Lost datalink communication (optional) ===<br />
<br />
This can be done via the a flight-plan exception, e.g. go to the Standby block after 30 seconds:<br />
{{Box Code|flightplan.xml|<br />
<source lang="xml"><br />
<header><br />
#include "subsystems/datalink/datalink.h"<br />
</header><br />
...<br />
<exceptions><br />
...<br />
<exception cond="datalink_time > 30" deroute="Standby"/><br />
</exceptions><br />
</source><br />
}}<br />
<br />
<br />
=== Outside mission boundary (optional) ===<br />
<br />
Also use exceptions and/or [[Flight_Plans#Call|function calls]] for this.<br />
<br />
For an example see ''EMAV2009_safety.xml'' in the directory ''conf/flight_plans'' is an example of a safety procedure that can be included in other flight-plans.<br />
It uses two [[Flight_Plans#Sectors|sectors]] defined in ''EMAV2009_data.xml'', a smaller Green "soft boundary" and a hard boundary defined by the Red sector.<br />
<br />
<source lang="xml"><br />
<procedure><br />
<exceptions><br />
<exception cond="Or(! InsideGreen(GetPosX(), GetPosY()), GetPosAlt() > ground_alt + 150)" deroute="Center"/><br />
</exceptions><br />
<br />
<blocks><br />
<block name="Center" pre_call="if (!InsideRed(GetPosX(), GetPosY())) NavKillThrottle();"><br />
<circle wp="_CENTER" radius="DEFAULT_CIRCLE_RADIUS"/><br />
</block><br />
</blocks><br />
</procedure><br />
</source><br />
<br />
The first exception deroutes the plane to the Center block below it, if it is outside the Green [[Flight_Plans#Sectors|sector]] or higher than 150m over ground.<br />
While in the Center block the statement in the pre_call function gets evaluated each time, if the plane is now also outside of the Red sector throttle is killed.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Airframe_Configuration&diff=15953Airframe Configuration2013-09-23T09:26:28Z<p>Mbina: Bat => Battery</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree><br />
== About ==<br />
The airframe file is the most important configuration file and contains all the hardware and software settings for your airframe. It describes what hardware you have and which firmware, sensors, algorithms, etc. you want to use and also holds your configuration parameters. All gains, trims, and behavior settings are defined with standard XML elements.<br />
<br />
The XML airframe configuration file is located in <tt>conf/airframes/<yourairframe>.xml</tt> and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line.<br />
<br />
<b>Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|rotorcraft specific configuration]].</b><br />
<br />
== Creating a new Aircraft ==<br />
While the airframe file is where you configure most aspects of your aircraft, a fully specified aircraft needs several XML configuration files:<br />
* Airframe (what this page is about)<br />
* [[Flight_Plans|Flight Plan]]<br />
* [[Settings]]<br />
* [[Radio_Control|Radio]] (if you use a PPM based R/C system)<br />
* [[Telemetry]]<br />
Each aircraft is assigned a name, unique ID and the associated configuration files in [[Conf.xml|<tt>conf/conf.xml</tt>]]. To create a new Aircraft, click new in the menu A/C in the [[Paparazzi_Center|Paparazzi Center]] and select your new airframe file, etc. (or specify it by hand in [[Conf.xml|<tt>conf/conf.xml</tt>]]).<br />
<br />
== Firmware and Hardware definitions ==<br />
First you should specify which firmware you want to use, i.e. if you have a <tt>[[Fixedwing_Configuration|fixedwing]]</tt> aircraft or a <tt>[[Rotorcraft_Configuration|rotorcraft]]</tt>:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
</firmware><br />
</source><br />
}}<br />
=== Select your Board ===<br />
To specify autopilot hardware you are using and it's low-level settings you have to add a ''target'' "ap" (autopilot) with ''board'' attribute.<br />
<br />
Select the appropriate hardware autopilot board you are going to use in your airframe:<br />
"booz_1.0", <br />
"classix", <br />
"hb_1.1", <br />
"lisa_l_1.0", <br />
"lisa_l_1.1", <br />
"lisa_m_1.0", <br />
"lisa_m_2.0", <br />
"logom_2.6", <br />
"navgo_1.0", <br />
"pc", <br />
"sdlog_1.0", <br />
"tiny_0.99", <br />
"tiny_1.1", <br />
"tiny_2.1", <br />
"tiny_2.11", <br />
"twog_1.0", <br />
"yapa_2.0",<br />
"umarim_1.0",<br />
"umarim_lite_2.0"<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
<target name="sim" board="pc"/><br />
<target name="ap" board="lisa_m_1.0"/><br />
...<br />
</firmware><br />
</source><br />
}}<br />
<br />
Note that the "pc" is a special kind of "board", and is mostly used only for simulation flights of an autopilot via your computer.<br />
<br />
==== Direct Makefile ====<br />
Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile Makefile] section. This is only needed in very advanced setups. For example when testing newly developed hardware.<br />
<br />
=== LEDs ===<br />
You can configure the LEDs on the autopilot to be used for different status indicators:<br />
; ''SYS_TIME_LED'': blinks with 1Hz<br />
; ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on<br />
; ''GPS_LED'': blinking if trying to get a fix, on if 3D fix<br />
; ''RADIO_CONTROL_LED'': on if RC signal is ok<br />
; ''BARO_LED'' : only on booz and navgo boards: blinks until baro offset is initialized and then stays on<br />
<br />
Depending on your board some of the LEDs on it are already assigned to some indicators by default, check the appropriate autopilot board page for the defaults.<br />
Use a configure node in the firmware section to assign an indicator to a LED number or disable that with ''none'':<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<configure name="SYS_TIME_LED" value="1"/><br />
<configure name="RADIO_CONTROL_LED" value="2"/><br />
<configure name="GPS_LED" value="none"/><br />
</firmware><br />
</source><br />
}}<br />
Beware that you can only assign '''one''' indicator to a LED number. So if the LED you want to use is already in use because another indicator is set to that number by default you have to disable that other indicator by setting it to ''none''.<br />
<br />
=== IMU ===<br />
Add the [[Subsystem/imu|imu subsystem]] with the type you are using.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="imu" type="aspirin_v1.5"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
See the [[Subsystem/imu|imu subsystem]] page for more details.<br />
Also see the [[ImuCalibration|IMU calibration]] page.<br />
<br />
=== AHRS ===<br />
The [[Subsystem/ahrs|AHRS subsystem]] specifies which attitude estimation filter you are using, e.g. for the complementary filter:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_euler"/><br />
</firmware><br />
</source><br />
}}<br />
All AHRS algorithms depend on an imu subsystem, except for the ahrs_infrared which depends on the infrared module.<br />
See the [[Subsystem/ahrs|AHRS subsystem page]] for more details.<br />
<br />
=== Radio Control ===<br />
<br />
Supported types are:<br />
* ''ppm''<br />
* ''spektrum''<br />
* ''datalink''<br />
<br />
Just specify the appropriate [[Subsystem/radio_control|radio control subsystem]] in your firmware section, e.g.:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="radio_control" type="ppm"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
=== Telemetry (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 your [[Telemetry|telemetry file]], e.g. <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 />
The [[Subsystem/telemetry|telemetry subsystem]] 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 />
<br />
Just specify the appropriate [[Subsystem/telemetry|telemetry subsystem]] in your firmware section. You can currently choose between the types ''transparent'', ''transparent_usb'' and ''xbee_api''.<br />
<br />
'''The default baudrate is 57600 baud, see the [[Subsystem/telemetry|telemetry subsystem]] page for more details and configuration options.'''<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="telemetry" type="transparent"/><br />
</firmware><br />
</source><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 />
Just specify the appropriate [[Subsystem/gps|gps subsystem]] in your firmware section. You can currently choose between the types '''ublox''' and '''ublox_utm''' for the older series 4 modules which still provide a UTM message.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing or rotorcraft"><br />
...<br />
<subsystem name="gps" type="ublox"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
The correct UART is already defined by default according to your board.<br />
The default GPS baudrate is 38400baud.<br />
<br />
If you need to set different baud rates or UART see the [[Subsystem/gps]] page for the options.<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 through the [[tunnel|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]<br />
<br />
== XML Parameters ==<br />
'''When defining parameters you can use [[Units|automatic unit conversion]] to conveniently set it in e.g. degrees.'''<br />
<br />
=== Commands ===<br />
<br />
The <b><tt>commands</tt></b> lists the abstract commands you need to control the aircraft. In a simple fixed-wing example, we have only three:<br />
<source lang="xml"><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><br />
</source><br />
For rotorcraft, it is usually:<br />
<source lang="xml"><br />
<commands><br />
<axis name="PITCH" failsafe_value="0"/><br />
<axis name="ROLL" failsafe_value="0"/><br />
<axis name="YAW" failsafe_value="0"/><br />
<axis name="THRUST" failsafe_value="0"/><br />
</commands><br />
</source><br />
<br />
Each command is also associated with a failsafe value which will be used if no controller is active, for example during initialization of the autopilot board. The range of these values is [-9600:9600]. For <tt>"THROTTLE"</tt>, the range is [0, 9600] and in the corresponding <b><tt>servo</tt></b> definition the <b><tt>neutral</tt></b> and <b><tt>min</tt></b> are usually the same for PWM based servos (see below). Note that these commands do not necessarily match the servo actuators. For example, the <tt>"ROLL"</tt> command is typically linked to two aileron actuators.<br />
<br />
=== Servos ===<br />
<br />
The above commands get translated to the <b><tt>servos</tt></b> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <b><tt>servos</tt></b> section:<br />
<source lang="xml"><br />
<servos><br />
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/><br />
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/><br />
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/><br />
</servos><br />
</source><br />
Names are associated to the corresponding '''real physical connector''' to which a servo is connected '''on the autopilot board'''. For example no="2" means connector two on the board. Also the servo neutral value, total range and direction are defined. Min/max/neutral values are expressed in milliseconds. The direction of travel can be reversed by exchanging min with max (as in <tt>"ELEVON_LEFTSIDE"</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. Absolute servo 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>.<br />
<br />
The attribute <b><tt>driver</tt></b> for <b><tt>servos</tt></b> node tells which actuators' driver is associated the the listed servos. After the version '''v4.9_devel-164-gdb0d004''', multiple servos sections can be defined and used together, if the correct [[Subsystem/actuators| actuators subsystems]] are loaded. Some boards are automatically loading a default driver, the one used when no <b><tt>driver</tt></b> attribute is specified.<br />
<br />
Note the following important tips:<br />
* Reverse the servo direction by exchanging min/max<br />
* Trim should always be adjusted mechanically if possible to avoid asymmetrical 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 />
* Board connector numbering starts with <b>zero (0)</b> not with one<br />
* Servos are also known under the synonym <b>actuators</b><br />
* (after version '''v4.9_devel-164-gdb0d004''') For I2C based motor speed control using the [[Rotorcraft_Configuration#Motor_Mixing|motor mixing]]:<br />
** min: command to stop the motor<br />
** neutral: motor idle command<br />
** max: max thrust command<br />
<br />
The <b><tt>servos</tt></b> are then linked to the commands in the <b><tt>command_laws</tt></b> section:<br />
<source lang="xml"><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="ELEVON_LEFTSIDE" value="$elevator + $aileron"/><br />
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/><br />
</command_laws><br />
</source><br />
<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. Elevon 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 />
After '''v4.9_devel-164-gdb0d004''', the <b><tt>command_laws</tt></b> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.<br />
<br />
=== Battery === <br />
This section gives characteristics for monitoring the main power battery.<br />
<br />
<b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> represents the actual current (in mA) when full THROTTLE is applied. Note that when flying the current typically is significantly lower than in static tests at home on your workbench. <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the energy recharged into the battery is only 2000 mAh, you could reduce the <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> value by 20% to match your in-flight current consumption. This tweaking is most precise if you fly full throttle only (respectively no throttle to glide down again).<br />
<br />
The <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> can be added to tweak the energy estimation for non full throttle cruise. As the current consumption is nonlinear, at 50% throttle it is likely to be substantially less than 50%. A superellipse is used to approximate this nonlinearity. The default setting is 1.2 and is used if the <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> is not defined in your airframe file. A value 1 corresponds to linear behaviour, 1.5 corresponds to strong nonlinearity. The tweaking is done same as decribed above for <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b>, but only partial throttle (cruise throttle) should be applied in flight.<br />
<br />
If both <b><tt>MILLIAMP_AT_FULL_THROTTLE</tt></b> and <b><tt>CURRENT_ESTIMATION_NONLINEARITY</tt></b> are tweaked well, you get precise energy estimations with less than 5% error independant of your flight pattern without even requiring a [[Current_sensor|current sensor]].<br />
<br />
The <b><tt>CATASTROPHIC_BAT_LEVEL</tt></b> (was previously <b><tt>LOW_BATTERY</tt></b>) value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode (kill_throttle mode). This value is also used by the ground server to issue a '''CATASTROPHIC''' alarm message on the bus (this message will be displayed in the console of the GCS). <b><tt>CRITIC</tt></b> and <b><tt>LOW</tt></b> values will also used as threshold for '''CRITIC''' and '''WARNING''' alarms. They are optional and the respective defaults are 10.0 and 10.5V.<br />
<br />
The <b><tt>MAX_BAT_LEVEL</tt></b> may be specified to improve the display of the battery gauge in the strip or in "papgets". Note that this definition is optional, with a default value of 12.5V.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="BAT"><br />
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" /><br />
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/><br />
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/><br />
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/><br />
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/><br />
</section><br />
</source><br />
}}<br />
<br />
The conversion of ADC measurements to Voltage is already defined for the different autopilot boards, if you need to override these defaults you can use the <b><tt>VoltageOfAdc(adc)</tt></b> define and also specify offsets or anything else you might need, e.g.:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="BAT"><br />
...<br />
<define name="VOLTAGE_ADC_SCALE" value="0.0177531"/><br />
<define name="VOLTAGE_OFFSET" value="0.5" unit="V"/><br />
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_SCALE * adc + VOLTAGE_OFFSET)"/><br />
</section><br />
</source><br />
}}<br />
<br />
=== Modules ===<br />
The [[Modules|modules]] allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.<br />
<br />
<source lang="xml"><br />
<modules main_freq="60"><br />
<load name="demo_module.xml"/><br />
</modules><br />
</source><br />
<br />
* The main_freq parameter (in Hz) allows to specify the frequency of the main loop. Default is 60 Hz<br />
<br />
=== GCS ===<br />
Use this <b>optional</b> section to help customize parts of the GCS for a specific airframe:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="GCS"><br />
...<br />
<define name="ALT_SHIFT_PLUS_PLUS" value="30"/><br />
<define name="ALT_SHIFT_PLUS" value="5"/><br />
<define name="ALT_SHIFT_MINUS" value="-5"/><br />
<define name="SPEECH_NAME" value="Quad"/><br />
</section><br />
</source><br />
}}<br />
<br />
* <tt>ALT_SHIFT_PLUS_PLUS</tt> sets the number of metres the target altitude will change when the double up arrow button is pressed on the [[GCS#Strips|strip]]<br />
* <tt>ALT_SHIFT_PLUS</tt> sets the number of metres the target altitude will change when the up arrow button is pressed on the [[GCS#Strips|strip]]<br />
* <tt>ALT_SHIFT_MINUS</tt> sets the number of metres the target altitude will change when the down arrow button is pressed on the [[GCS#Strips|strip]]<br />
* <tt>SPEECH_NAME</tt> a string ([a-zA-Z0-9_]) that will be used in place of the aircraft name specified in <tt>conf.xml</tt> for the [[Speech|speech]] and [[GCS#Alarms|alarms]] functionality. Set this to "_" to prevent the speech function from saying the aircraft name. Useful if your aircraft name takes a long time to say (i.e. "UAV1-A_with_spektrum" can be shortened to "Plane").<br />
<br />
[[Category:User_Documentation]] [[Category:Airframe_Configuration]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Pan_Tilt_Camera&diff=15934Pan Tilt Camera2013-09-16T23:34:26Z<p>Mbina: </p>
<hr />
<div>== Pan/Tilt Video Camera Mechanism ==<br />
<br />
Paparazzi currently allows to automatically move (follow a waypoint) a one axis pitch or roll camera as well as a two axis yaw-fixed-then-pitch camera.<br />
<br />
[[Image:Glotzer_cam_xy.jpg|thumb|left|Two axis yaw-fixed, pitch-move mechanism]]<br />
[[Image:Black_one_roll.jpg|thumb|left|One axis roll]]<br />
[[Image:Red_one_pitch.jpg|thumb|left|One axis pitch]]<br />
<br style="clear:both"><br />
<br />
The camera control is made of normal servos. Usually servos have a turn angle of about 90°. This is changed electrically so that they can do a 180°. It is achieved by adding two serial resistors at both sides of the potentiometer (P1), one for increasing the usable angle (R1) and the other for moving the middle position to a useful angle (R2). Therefore a servo with a 270° potentiometer is needed. Very small and light servos have 180° potentiometers, these do not allow a 180° degrees sweep. Cut the outer two connections between the potentiometer and the board to insert the resistors. The values for R1 and R2 should be found out by testing as there might be serial resistors on the servo board that affect the values. Start with about 1/2 the value of P1 for R1 and change R1 until you get a little more than 180° sweep. Then insert and modify R2 to set neutral back to the middle position of the potentiometer.<br />
<br />
<br />
<tt><br />
^<br />
/<br />
----------<br />
*-------I / I-------*<br />
I ---------- I<br />
I / P1 I<br />
I I I<br />
I I I<br />
--- I ---<br />
I I I I I<br />
I I I I I<br />
I I I I I<br />
--- R1 I --- R2<br />
I I I<br />
I I I<br />
</tt><br />
<br />
If you don't want to bother modifying your servo to 180°, use a 180° servo strecher for your standard servo [[http://www.servocity.com/html/180o_servo_stretcher.html ServoCity]] or [[http://www.robotmarketplace.com/products/0-FRMRT180.html RobotMarketPlace]] or buy a 180° servo [[http://www.servocity.com/html/hs-645mg_ultra_torque.html ServoCity]] or [[http://www.modellbau-bichler.com/servobeckers100s180gradjr-p-8221.html?osCsid=b3f7a1d078e0fa1d0433e29ed16da866 Becker]]<br />
<br />
The Paparazzi software makes planes circle clockwise (use negative radius for counter-clockwise) so the default view is to the right side of the plane. The pan servo neutral makes the camera look to the right with 0° given, 90° is to the back and -90° is to the front. The tilt servo neutral makes the camera look down with 0° given, 90° is to the right and -90° is to the left (all values are used in radian in the software). If the camera looks to the right side of the plane, the picture is upright. It is upside down when looking to the left. That is corrected with the MPEG decoding software on the laptop by mirroring. The pan servo is fixed in the plane and the tilt servo is moved by the pan servo and moves the camera.<br />
<br />
pan servo, tilt set to 90°, looking from top:<br />
<br />
plane front<br />
<tt> <br />
^<br />
I<br />
I 45°<br />
I /<br />
I/<br />
I------- 0°<br />
I\<br />
I \<br />
I -45°<br />
I<br />
</tt><br />
plane rear<br />
<br />
tilt servo, pan set to 0°, looking from back:<br />
<tt> <br />
plane left --------------- plane right<br />
/ I \<br />
/ I \<br />
-45° I 45°<br />
0°<br />
</tt><br />
tilt servo is moved by the pan servo and moves the camera.<br />
<br />
<br />
<br />
Add this to your Aircraft file to the right place:<br />
<source lang="xml"><br />
<servo name="CAM_PAN" no="3" min="2000" neutral="1550" max="1000"/><br />
<servo name="CAM_TILT" no="6" min="1000" neutral="1550" max="2000"/><br />
<br />
<axis name="CAM_TILT" failsafe_value="0"/><br />
<axis name="CAM_PAN" failsafe_value="0"/><br />
<br />
<set command="CAM_PAN" value="@YAW"/><br />
<set command="CAM_TILT" value="@GAIN1"/><br />
<br />
<set servo="CAM_PAN" value="@CAM_PAN"/><br />
<set servo="CAM_TILT" value="@CAM_TILT"/><br />
<br />
<section name="CAM" prefix="CAM_"><br />
<define name="TILT_MAX" value="30" unit="deg"/><br />
<define name="TILT_NEUTRAL" value="0" unit="deg"/><br />
<define name="TILT_MIN" value="-30" unit="deg"/><br />
<define name="TILT0" value="0" unit="deg"/><br />
<br />
<define name="PAN_MAX" value="45" unit="deg"/><br />
<define name="PAN_NEUTRAL" value="0" unit="deg"/><br />
<define name="PAN_MIN" value="-45" unit="deg"/><br />
<define name="PAN0" value="0" unit="deg"/><br />
</section><br />
<br />
<modules main_freq="60"><br />
<load name="cam_point.xml"><br />
<define name="POINT_CAM_PITCH_ROLL" value="1"/><br />
<define name="SHOW_CAM_COORDINATES" value="1"/><br />
</load><br />
</modules><br />
</source><br />
<br />
It make use of cam.c and point.c in sw/airborne/modules/cam_control/<br />
<br />
When you load cam.xml in your settings of your aircraft session you can tune this:<br />
<br />
<br />
<br />
THE MODE:<br />
<br />
OFF =0<br />
<br />
ANGLES=1 (look at angle that you chose in the angle tap)<br />
<br />
NADIR=2 (look down)<br />
<br />
XY_TARGET=3 (looks to the coordinates where you activate it, look here)<br />
<br />
WP_TARGET=4 (looks to the way point that you chose in the target tap, cam_target_wp)<br />
<br />
AC_TARGET=5 (looks at an aircraft, activate traffic_info.c)<br />
<br />
<br />
<br />
ANGLES:<br />
<br />
set your pan tilt angle for the Angles mode=1<br />
<br />
<br />
<br />
TARGET:<br />
<br />
set the way point you want to look at<br />
<br />
1=home<br />
<br />
2=... (see your way point file)<br />
<br />
[[Category:Hardware]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Module/Airspeed_ETS&diff=15933Module/Airspeed ETS2013-09-16T20:54:46Z<p>Mbina: reduced the pinout table to a more compact form</p>
<hr />
<div>__NOTOC__<br />
[[Image:Ets_airspeed_v3.jpg|thumb|right|Eagletree Airspeed v3]]<br />
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree><br />
== Overview ==<br />
<br />
The EagleTree Airspeed Sensor is a low cost module and comes with a good [http://en.wikipedia.org/wiki/Pitot_tube pitot tube] (Prandtl style, pitot-static tube) that includes static and dynamic ports. It has an I²C interface that connects directly to the Autopilot I²C port. The paparazzi autopilot code is able to regulate the throttle in order to keep the airspeed constant (and a minimum ground speed).<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||Module name||sensors/airspeed_ets<br />
|-<br />
|Sensor type<br />
|air speed<br />
|-<br />
|Range<br />
|4m/s .. 150m/s<br />
|-<br />
|Resolution<br />
|0.3m/s<br />
|-<br />
|Refresh rate<br />
|10Hz<br />
|-<br />
|I2C address<br />
|0xEA<br />
|}<br />
<br />
[http://www.eagletreesystems.com/Support/manuals/airspeed-v3.pdf Product data sheet]<br />
<br />
== Hardware ==<br />
<br />
The sensor directly interfaces to the 3.3V I2C port of the autopilots and is supplied by +5V. <br />
<br />
When you buy the airspeed sensor it is set to operate in the default mode. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Make sure you did not set it somehow to 3rd party mode.<br />
<br />
=== Wiring ===<br />
<br />
The ETS Airspeed sensor has an I2C cable with the following layout:<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||'''Tiny/TWOG I2C pin'''||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''<br />
|-<br />
|1<br />
|GND<br />
|white<br />
|-<br />
|2<br />
| +5V<br />
|red<br />
|-<br />
|3<br />
| +3.3V<br />
| <br />
|-<br />
|4<br />
|SDA<br />
|yellow<br />
|-<br />
|5<br />
|SCL<br />
|brown<br />
|}<br />
<br />
Please refer to your boards documentation to find out the correct pinout on your board (which cable to connect to which pin). <br />
As an example the correct pinout for the TWOG v1.0 and Tiny has been given in the table above.<br />
<br />
== Usage ==<br />
<br />
To use it load the ''airspeed_ets'' module:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
...<br />
<load name="airspeed_ets.xml" /><br />
...<br />
</modules><br />
</source><br />
}}<br />
<br />
Depending on your board and the I2C interface you are using, you may need to<br />
enable I2CX, where X is 0,1,2,etc., if you are not using it already:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware><br />
...<br />
<define name="USE_I2C0" /> <!-- In case you attached the ETS module to I2C0 --><br />
<define name="USE_I2C1" /> <!-- In case you attached the ETS module to I2C1 --><br />
<define name="USE_I2C2" /> <!-- In case you attached the ETS module to I2C2 --><br />
<define name="USE_I2C3" /> <!-- In case you attached the ETS module to I2C3 --><br />
</firmware><br />
</source><br />
}}<br />
<br />
<br />
=== Configuration ===<br />
<br />
You can also set some '''optional parameters to change the default configuration'''. <br />
For example to use I2C1 instead of I2C0, a scale of 2 (default is 1.8) and offset of 50 (default is 0) is needed:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<!-- Applies if another I2C interface than IC20 is used --><br />
<define name="AIRSPEED_ETS_SCALE" value="2"/> <br />
<define name="AIRSPEED_ETS_OFFSET" value="50"/><br />
<define name="AIRSPEED_ETS_I2C_DEV" value="i2c1"/> <br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
<br />
== Usage as sensor for speed control ==<br />
<br />
To use the sensor to control the speed of your aircraft add the aggressive climb flag, define which I2C device you are enabling and enable airspeed control:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<target name="ap" board="twog_1.0"><br />
<define name="AGR_CLIMB"/><br />
<define name="USE_I2C0"/> <!-- Details: see above --><br />
<define name="USE_AIRSPEED"/> <!-- Use the airspeed sensor in the control loop --><br />
</target><br />
</source><br />
}}<br />
<br />
=== Airframe configuration ===<br />
<br />
Now to use real airspeed values for adjusting your aircrafts autopilot behavior, add the following to the end of the "VERTICAL CONTROL" section of your airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="VERTICAL_CONTROL" prefix="V_CTL_"><br />
....<br />
<!-- auto airspeed and altitude inner loop (for airspeed sensor) --><br />
<define name="AUTO_AIRSPEED_SETPOINT" value="13.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_AIRSPEED_PGAIN" value="0.060" /><br />
<define name="AUTO_AIRSPEED_IGAIN" value="0.050" /> <br />
<br />
<define name="AUTO_GROUNDSPEED_SETPOINT" value="7.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_GROUNDSPEED_PGAIN" value="0.75" /><br />
<define name="AUTO_GROUNDSPEED_IGAIN" value="0.25" /><br />
</section><br />
</source><br />
}}<br />
<br />
Note that the SETPOINT values may need to be adjusted to suit your aircraft.<br />
<br />
Note that depending on whether you set the AIRSPEED setpoint or the GROUNDSPEED setpoint higher, either constant airspeed or constant groundspeed, respectively, will be the goal of the controller.<br />
<br />
See paparazzi/conf/airframes/easystar_ets_example.xml for an example airframe configuration.<br />
<br />
=== Debugging and logging the airspeed values ===<br />
<br />
To debug or log the raw values from the ETS airspeed sensor define SENSOR_SYNC_SEND in your airframe file to send the message AIRSPEED_ETS on every sensor reading. <br />
Note that defining this sends the AIRSPEED_ETS message at the sensor read rate as defined in conf/modules/airspeed_ets.xml. <br />
This does not have any bearing on the AIRSPEED message (if both SENSOR_SYNC_SEND and USE_AIRSPEED are defined, then both messages are sent). <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> ''Please note: if you are using the master branch and have merged commits on or later than July 16, 2013, please replace SENSOR_SYNC_SEND with AIRSPEED_ETS_SYNC_SEND''<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
The general airspeed can be displayed in the Messages tool by adding the AIRSPEED message to the telemetry file as follows:<br />
{{Box Code|conf/telemetry/default.xml|<br />
<source lang="xml"><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="AIRSPEED" period="1.0"/><br />
...<br />
</source><br />
}}<br />
<br />
The AIRSPEED_ETS message does NOT need to be added to the telemetry configuration since it is sent directly by the module if SENSOR_SYNC_SEND is defined.<br />
<br />
=== NOTES ===<br />
# In the GCS, the strip displays ground speed and '''not''' airspeed by default. In order to display airspeed, drag-and-drop the airspeed message field from the Messages tool onto the 2D map of the GCS. <br />
# The telemetry name AIRSPEED" should actually be called SPEED and contains Groundspeed and airspeed return values.<br />
<br />
== Measurement only ==<br />
<br />
To use the sensor for airspeed measurement is also possible. This Measurement only mode does thus not imput to the control loops to have effect to the aircraft behaviour.<br />
<br />
To see the sensors data in the log file set the SENSOR_SYNC_SEND in your airframe file. Every time new data is available it will be sent directly.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> ''Please note: if you are using the master branch and have merged commits on or later than July 16, 2013, please replace SENSOR_SYNC_SEND with AIRSPEED_ETS_SYNC_SEND''<br />
<br />
===Result message===<br />
<br />
The raw data (adc), estimated offset at init time (offset) and the converted result (scaled) is written to the log file.<br />
{{Box Code|conf/messages.xml|<br />
<source lang="xml"><br />
<message name="AIRSPEED_ETS" id="57"><br />
<field name="adc" type="uint16" /><br />
<field name="offset" type="uint16" /><br />
<field name="scaled" type="float" /><br />
</message><br />
</source><br />
}}<br />
<br />
<br />
Sample log file lines<br />
149.529 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.633 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.730 123 AIRSPEED_ETS 1627 1606 7.942226<br />
149.841 123 AIRSPEED_ETS 1628 1606 7.942226<br />
<br />
[[Category:User_Documentation]] [[Category:Modules]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Telemetry&diff=15932Telemetry2013-09-16T19:13:50Z<p>Mbina: added: syntax highlighting</p>
<hr />
<div>== Messages ==<br />
The set of periodic messages sent over the downlink channel by an aircraft to the ground station is configurable<br />
with the help of one XML file, located in the <tt>conf/telemetry</tt> directory. This file is called by <tt>conf/conf.xml</tt> and must follow the<br />
<tt>telemetry.dtd</tt> syntax. The <tt>default.xml</tt> is provided as an example and should be suitable for most users: (copy this file to your own file like Xbee.xml or aerocom.xml and load this in the telemetry part of the [[Paparazzi Center]] )<br />
{{Box Code|default.xml|<br />
<source lang="xml"><!DOCTYPE telemetry SYSTEM "telemetry.dtd"><br />
<telemetry><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="ATTITUDE" period="0.5"/><br />
<message name="PPRZ_MODE" period="5"/><br />
<message name="SOME_MODULE_MSG" period="2" module="module_name"/><br />
...<br />
</mode><br />
<mode name="fast attitude"><br />
<message name="ATTITUDE" period="0.1"/><br />
</mode><br />
</process><br />
<process name="Fbw"><br />
<mode name="default"><br />
<message name="COMMANDS" period="1"/><br />
...<br />
</mode><br />
<mode name="debug"><br />
<message name="PPM" period="0.5"/><br />
</mode><br />
</process><br />
</telemetry></source><br />
}}<br />
<br />
If a [[Modules|module]] attribute is specified for a message, it will be include in the telemetry only if the corresponding module is loaded.<br />
<br />
===Add Messages===<br />
<br />
Adding a new sensor to Paparazzi and sending the sensor data to the ground example. This example is for adding an airspeed message. <br />
<br />
in conf/messages.xml add an airspeed messages:<br />
{{Box Code|conf/messages.xml|<br />
<source lang="xml"><br />
<message name="AIRSPEED" id="54"><br />
<field name="adc_airspeed" type="uint16"/><br />
<field name="estimator_airspeed" type="float" unit="m/s"/><br />
<field name="airspeed_setpoint" type="float" unit="m/s"/><br />
<field name="airspeed_controlled" type="float" unit="m/s"/><br />
<field name="groundspeed_setpoint" type="float" unit="m/s"/><br />
</message><br />
</source>}}<br />
Where id="54" has to be unique. To find an new ID to use there is a script file located at ${PAPARAZZI_HOME}/sw/tools/find_free_msg_id.out (yes it is really a script). <br />
<br />
Type: ${PAPARAZZI_HOME}/sw/tools/find_msg_id.out <br />
NOTE: Be sure your Paparazzi source and home environment variables are set correctly in your shell [[Installation#Launching_the_Software]])<br />
every field in the output is a variable from Paparazzi. The type must be the type of a variable in your code (ie. look in your code). Add your message along with the frequency to be sent over the messaging bus (AKA telemetry messages).<br />
<br />
Create a DOWNLINK_SEND_AIRSPEED with this XML (In conf/telemetry/default.xml):<br />
{{Box Code|conf/telemetry/default.xml|<br />
<source lang="xml"><br />
<telemetry><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="ALIVE" period="5"/><br />
<message name="GPS" period="0.25"/><br />
<message name="AIRSPEED" period="1"/><br />
....<br />
</source><br />
}}<br />
<br />
Create a PERIODIC_SEND_AIRSPEED with the following code in the header file (In ap_downlink.h) :<br />
{{Box Code|conf/telemetry/default.xml|<br />
<source lang="c"><br />
#ifdef USE_AIRSPEED<br />
#define PERIODIC_SEND_AIRSPEED(_chan) DOWNLINK_SEND_AIRSPEED (_chan, &adc_airspeed_val,&estimator_airspeed,&v_ctl_auto_airspeed_setpoint,&v_ctl_auto_airspeed_controlled,&v_ctl_auto_groundspeed_setpoint)<br />
#else<br />
#define PERIODIC_SEND_AIRSPEED(_chan) {}<br />
#endif<br />
</source><br />
}}<br />
<br />
here you tell to replace all PERIODIC_SEND_AIRSPEED by DOWNLINK_SEND_AIRSPEED<br />
<br />
===Specific Messages===<br />
<br />
====GPS_SOL====<br />
Specification in telemetry file<br />
<source lang="xml"><br />
<message name="GPS_SOL" period="2.0"/><br />
</source><br />
Example from logfile(.data):<br />
6.742 1 GPS_SOL 232 43 198 8<br />
<br />
Meaning of tokens:<br />
Timestamp, Aircraft-Number, GPS_SOL, Pacc, Sacc, PDOP, numSV<br />
<br />
*Pacc = Position accuracy (units: CM)<br />
*Sacc = Speed accuracy (units: CM/sec ?)<br />
*PDOP = Position [http://en.wikipedia.org/wiki/Dilution_of_precision_%28GPS%29 Dilution_of_precision_(GPS)] , if this value is high the value of position will be less accurate<br />
*numSV = number of Space Vehicles (Satellites) used in Nav Solution<br />
<br />
====PPRZ_MODE====<br />
Specification in telemetry file<br />
<source lang="xml"><br />
<message name="PPRZ_MODE" period="5."/><br />
</source><br />
Example from logfile(.data):<br />
20.433 2 PPRZ_MODE 0 1 2 0 0 1<br />
<br />
Meaning of tokens:<br />
Timestamp, Aircraft-Number, PPRZ_MODE, ap_mode, ap_gaz, ap_horizontal, if_calib_mode, mcul_status<br />
*ap_mode = (0 = MANUAL, 1 = AUTO1, 2 = AUTO2, 3 = HOME mode (Circle Home waypoint), 4 = NO_GPS (GPS not working), 5 = NB (?)<br />
*ap_gaz = ?<br />
*ap_horizontal = ?<br />
*if_calib_mode = ?<br />
*mcul_status = ?<br />
<br />
===Configuring the Downlink Data Rate===<br />
<br />
The limited throughput of our RF modems results in a need to carefully choose which data to send, as well as the frequency at which to send it. A sophisticated set of files and parameters have been developed in order to tailor the data downlink behavior automatically, manually, temporarily, or permanently according to any desired parameter. This allows the user to create an almost unlimited possibility of downlink configurations. For example:<br />
* Tailor the data rate to work with very slow modems (9600 baud or slower)<br />
* Reduce the data rate of some messages so that others can be increased:<br />
*: Automatically send GPS data at a very high rate by sacrificing navigation data when not flying (to help GPS/RFI troubleshooting) then automatically reduce the GPS data rate and send normal navigation data when the launch is initiated.<br />
*: Automatically switch to sending only position data upon landing to conserve power and increase the chance of the operator receiving a position packet when recovering a distant aircraft.<br />
*: Manually send selected sensor data at very high speeds (60Hz) for real time tuning.<br />
* Maintain independent telemetry configurations for aircraft with different modems, sensors, or mission profiles.<br />
<br />
Any number of configuration files can be created in the <tt>conf/telemetry</tt> directory and selected from the <tt>conf/conf.xml</tt> file. The telemetry downlink is divided into two processes, '''Ap''' and '''Fbw''' each with a possible <tt>mode</tt> option. Any number of modes could be created, the default is the first in the sequence. A mode contains the list of messages to be sent as well as the period of each message in seconds. In this example, the '''ATTITUDE''' message will be sent by the '''Ap''' process at 2Hz in the default mode and at 10Hz in the '''fast attitude''' mode. The maximum allowed frequency is 60Hz (0.017s) and the maximum period is 1092s.<br />
<br />
The mode can be chosen in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant:<br />
<source lang="xml"><define name="TELEMETRY_MODE_FBW" value="1"/></source><br />
where the (default) first mode is numbered '''0'''.<br />
<br />
This mode can also be changed dynamically with a datalink [[#Settings|setting]] or with a [[Flight_Plans#set|set]] stage in the flight plan.<br />
<br />
Note that an (undocumented!) subset of the messages is required to be able to use ground station properly. So it is not advisable to completely remove messages for the '''Ap''' process listed in the default mode.<br />
<br />
== Settings ==<br />
<br />
The <tt>settings</tt> attribute in the description of the aircraft in <tt>conf.xml</tt> allows the user to specify a list of variables for which values can be changed in-flight:<br />
<source lang="xml"><aircraft <br />
name="Microjet"<br />
...<br />
settings="settings/basic.xml"<br />
...<br />
/></source><br />
<br />
with the <tt>basic.xml</tt> file located in <tt>conf/settings/</tt>. A <tt>dl_setting</tt> element in this file associates [[GCS#Settings|buttons or sliders in the GCS interface]] to autopilot variables:<br />
{{Box Code|conf/settings/basic.xml|<br />
<source lang="xml"><br />
<tt><!DOCTYPE settings SYSTEM "settings.dtd"><br />
<settings><br />
<dl_settings><br />
<dl_settings NAME="flight params"><br />
<dl_setting MAX="1000" MIN="-50" STEP="10" VAR="altitude_shift"/><br />
</dl_settings><br />
<dl_settings NAME="mode"><br />
<dl_setting MAX="2" MIN="0" STEP="1" VAR="pprz_mode"><br />
<strip_button name="AUTO2" value="2"/><br />
</dl_setting><br />
<dl_setting MAX="1" MIN="0" STEP="1" VAR="launch"><br />
<strip_button name="Launch" value="1"/><br />
</dl_setting><br />
<dl_setting MAX="1" MIN="0" STEP="1" VAR="kill_throttle"/><br />
</dl_settings><br />
</dl_settings><br />
</settings></source>}}<br />
<br />
where <tt>dl_settings</tt> elements can be nested at any depth. A <tt>dl_setting</tt> element just specifies the name of the variable, the allowed range for the setting (<tt>min</tt> and <tt>max</tt> attributes) and the minimal <tt>step</tt>.<br />
<br />
A notebook page will be associated in the GUI to each <tt>dl_settings</tt> element. A slider will be associated to each <tt>dl_setting</tt> entry except if the range is small (typically less than 3) and discrete (step=1): in the latter case, a set of radio buttons will be displayed.<br />
<br />
The <tt>strip_button</tt> element adds a button to the [[GCS#Strip|GCS strip]] for commonly used tasks like "Launch" or "Circle". Multiple buttons can be used to assign different values to the same variable. If the attribute <tt>group</tt> is specified, all strip buttons of the same group will be placed vertically on top of each other.<br />
<br />
The <tt>param</tt> attribute of a <tt>dl_setting</tt> element allows to specify the corresponding parameter in the airframe file in order to save a tuned value:<br />
<source lang="xml"><dl_setting max="0.3" min="-0.3" step="0.01" var="ir_roll_neutral" param="IR_ROLL_NEUTRAL_DEFAULT" unit="rad"/></source><br />
where the <tt>unit</tt> attribute is required for the parameters which do not use the same unit than the corresponding variable (currently only for some angle parameters in degrees in the airframe file and in radians for the variable).<br />
<br />
== R/C Transmitter Data Uplink ==<br />
<br />
With the advent of small modems such as the popular Zigbee-based models, the usage of the R/C transmitter as a simple data-link is substantially less. Nevertheless, this feature may still prove useful for extremely minimal hardware configurations. Also '''very''' useful for tuning of some parameters that are best adjusted by the pilot while flying, such as IR pile neutral settings. While a laptop in the field may be the best for most part of the tuning for sometimes it is more convenient from the transmitter directly. For this it is best to have little more advanced transmitter. For example a Graupner JR MX-22 or alike. On these transmitter there are controls that are good for up and down setting <br />
<br />
[[Image:Ap_calib_sliders_via_rc.jpg|thumb|right|Use these up/down buttons for realtime tuning]]<br />
<br />
The <tt>tuning_rc.xml</tt> file is located in <tt>conf/settings</tt>.<br />
{{Box Code|conf/settings/tuning_rc.xml|<br />
<source lang="xml"><aircraft <br />
name="Microjet"<br />
...<br />
settings="settings/tuning_rc.xml"<br />
...<br />
/></source>}}<br />
<br />
A <tt>rc_settings</tt> element in this file associates switches and sliders of the RC to airborne variables:<br />
<br />
{{Box Code|conf/settings/tuning_rc.xml|<br />
<source lang="xml"><br />
<!DOCTYPE settings SYSTEM "settings.dtd"><br />
<!-- A conf to use to tune an A/C using only the rc --><br />
<settings><br />
<rc_settings><br />
<rc_mode NAME="AUTO1"><br />
<rc_setting VAR="ir_pitch_neutral" RANGE="2" RC="gain_1_up" TYPE="float"/><br />
<rc_setting VAR="ir_roll_neutral" RANGE="-2" RC="gain_1_down" TYPE="float"/><br />
</rc_mode><br />
<rc_mode NAME="AUTO2"><br />
<rc_setting VAR="course_pgain" RANGE="0.1" RC="gain_1_up" TYPE="float"/><br />
<rc_setting VAR="pitch_of_roll" RANGE=".2" RC="gain_1_down" TYPE="float"/><br />
</rc_mode><br />
</rc_settings><br />
</settings></source>}}<br />
<br />
First, settings are sorted by mode (<tt>AUTO1</tt> or <tt>AUTO2</tt>). Then a setting is composed of a <tt>var</tt>iable name, a <tt>range</tt> (corresponding to the range of the RC slider) and a <tt>RC</tt> name. The RC name prefix can be ''gain_1'' or ''gain_2'', which corresponds to the <tt>GAIN1</tt> and <tt>GAIN2</tt> channels of your RC transmitter [[Radio_Control|configuration]]. The RC name suffix can be ''up'' or ''down'', which is related to the position of the <tt>CALIB</tt> switch on the RC transmitter.<br />
<br />
== Audio-based downlink ==<br />
<br />
The audio-based downlink has been removed from current hardware designs however using the old designs it is possible to implement. With the current low prices of a simple video transmitter, data over audio may come in as a welcomed addition. Feel free to experiment and revive this classical feature.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]] [[Category:Telemetry]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Module/Airspeed_ETS&diff=15931Module/Airspeed ETS2013-09-16T14:04:05Z<p>Mbina: added link to EN-wikipedia on the pitot tube</p>
<hr />
<div>__NOTOC__<br />
[[Image:Ets_airspeed_v3.jpg|thumb|right|Eagletree Airspeed v3]]<br />
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree><br />
== Overview ==<br />
<br />
The EagleTree Airspeed Sensor is a low cost module and comes with a good [http://en.wikipedia.org/wiki/Pitot_tube pitot tube] (Prandtl style, pitot-static tube) that includes static and dynamic ports. It has an I²C interface that connects directly to the Autopilot I²C port. The paparazzi autopilot code is able to regulate the throttle in order to keep the airspeed constant (and a minimum ground speed).<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||Module name||sensors/airspeed_ets<br />
|-<br />
|Sensor type<br />
|air speed<br />
|-<br />
|Range<br />
|4m/s .. 150m/s<br />
|-<br />
|Resolution<br />
|0.3m/s<br />
|-<br />
|Refresh rate<br />
|10Hz<br />
|-<br />
|I2C address<br />
|0xEA<br />
|}<br />
<br />
[http://www.eagletreesystems.com/Support/manuals/airspeed-v3.pdf Product data sheet]<br />
<br />
== Hardware ==<br />
<br />
The sensor directly interfaces to the 3.3V I2C port of the autopilots and is supplied by +5V. <br />
<br />
When you buy the airspeed sensor it is set to operate in the default mode. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Make sure you did not set it somehow to 3rd party mode.<br />
<br />
=== Wiring ===<br />
<br />
The ETS Airspeed sensor has an I2C cable with the following layout:<br />
{|border="1"<br />
|-valign="top"<br />
||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''<br />
|-<br />
|GND<br />
|white<br />
|-<br />
| +5V<br />
|red<br />
|-<br />
|SDA<br />
|yellow<br />
|-<br />
|SCL<br />
|brown<br />
|}<br />
<br />
Please refer to your boards documentation to find out the correct pinout on your board (which cable to connect to which pin). <br />
Below an example for the TWOG v1.0 is given.<br />
<br />
==== Example: TWOG v1.0 ====<br />
<br />
This is the wiring for the TWOG v1.0 and the Eagle Tree Airspeed sensor on/for the I2C connector and serves as an example.<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||'''Autopilot I2C pin'''||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''<br />
|-<br />
|1<br />
|GND<br />
|white<br />
|-<br />
|2<br />
| +5V<br />
|red<br />
|-<br />
|3<br />
| +3.3V<br />
| do not connect<br />
|-<br />
|4<br />
|SDA<br />
|yellow<br />
|-<br />
|5<br />
|SCL<br />
|brown<br />
|}<br />
<br />
<br />
== Usage ==<br />
<br />
To use it load the ''airspeed_ets'' module:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
...<br />
<load name="airspeed_ets.xml" /><br />
...<br />
</modules><br />
</source><br />
}}<br />
<br />
Depending on your board and the I2C interface you are using, you may need to<br />
enable I2CX, where X is 0,1,2,etc., if you are not using it already:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware><br />
...<br />
<define name="USE_I2C0" /> <!-- In case you attached the ETS module to I2C0 --><br />
<define name="USE_I2C1" /> <!-- In case you attached the ETS module to I2C1 --><br />
<define name="USE_I2C2" /> <!-- In case you attached the ETS module to I2C2 --><br />
<define name="USE_I2C3" /> <!-- In case you attached the ETS module to I2C3 --><br />
</firmware><br />
</source><br />
}}<br />
<br />
<br />
=== Configuration ===<br />
<br />
You can also set some '''optional parameters to change the default configuration'''. <br />
For example to use I2C1 instead of I2C0, a scale of 2 (default is 1.8) and offset of 50 (default is 0) is needed:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<!-- Applies if another I2C interface than IC20 is used --><br />
<define name="AIRSPEED_ETS_SCALE" value="2"/> <br />
<define name="AIRSPEED_ETS_OFFSET" value="50"/><br />
<define name="AIRSPEED_ETS_I2C_DEV" value="i2c1"/> <br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
<br />
== Usage as sensor for speed control ==<br />
<br />
To use the sensor to control the speed of your aircraft add the aggressive climb flag, define which I2C device you are enabling and enable airspeed control:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<target name="ap" board="twog_1.0"><br />
<define name="AGR_CLIMB"/><br />
<define name="USE_I2C0"/> <!-- Details: see above --><br />
<define name="USE_AIRSPEED"/> <!-- Use the airspeed sensor in the control loop --><br />
</target><br />
</source><br />
}}<br />
<br />
=== Airframe configuration ===<br />
<br />
Now to use real airspeed values for adjusting your aircrafts autopilot behavior, add the following to the end of the "VERTICAL CONTROL" section of your airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="VERTICAL_CONTROL" prefix="V_CTL_"><br />
....<br />
<!-- auto airspeed and altitude inner loop (for airspeed sensor) --><br />
<define name="AUTO_AIRSPEED_SETPOINT" value="13.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_AIRSPEED_PGAIN" value="0.060" /><br />
<define name="AUTO_AIRSPEED_IGAIN" value="0.050" /> <br />
<br />
<define name="AUTO_GROUNDSPEED_SETPOINT" value="7.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_GROUNDSPEED_PGAIN" value="0.75" /><br />
<define name="AUTO_GROUNDSPEED_IGAIN" value="0.25" /><br />
</section><br />
</source><br />
}}<br />
<br />
Note that the SETPOINT values may need to be adjusted to suit your aircraft.<br />
<br />
Note that depending on whether you set the AIRSPEED setpoint or the GROUNDSPEED setpoint higher, either constant airspeed or constant groundspeed, respectively, will be the goal of the controller.<br />
<br />
See paparazzi/conf/airframes/easystar_ets_example.xml for an example airframe configuration.<br />
<br />
=== Debugging and logging the airspeed values ===<br />
<br />
To debug or log the raw values from the ETS airspeed sensor define SENSOR_SYNC_SEND in your airframe file to send the message AIRSPEED_ETS on every sensor reading. <br />
Note that defining this sends the AIRSPEED_ETS message at the sensor read rate as defined in conf/modules/airspeed_ets.xml. <br />
This does not have any bearing on the AIRSPEED message (if both SENSOR_SYNC_SEND and USE_AIRSPEED are defined, then both messages are sent). <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> ''Please note: if you are using the master branch and have merged commits on or later than July 16, 2013, please replace SENSOR_SYNC_SEND with AIRSPEED_ETS_SYNC_SEND''<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
The general airspeed can be displayed in the Messages tool by adding the AIRSPEED message to the telemetry file as follows:<br />
{{Box Code|conf/telemetry/default.xml|<br />
<source lang="xml"><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="AIRSPEED" period="1.0"/><br />
...<br />
</source><br />
}}<br />
<br />
The AIRSPEED_ETS message does NOT need to be added to the telemetry configuration since it is sent directly by the module if SENSOR_SYNC_SEND is defined.<br />
<br />
=== NOTES ===<br />
# In the GCS, the strip displays ground speed and '''not''' airspeed by default. In order to display airspeed, drag-and-drop the airspeed message field from the Messages tool onto the 2D map of the GCS. <br />
# The telemetry name AIRSPEED" should actually be called SPEED and contains Groundspeed and airspeed return values.<br />
<br />
== Measurement only ==<br />
<br />
To use the sensor for airspeed measurement is also possible. This Measurement only mode does thus not imput to the control loops to have effect to the aircraft behaviour.<br />
<br />
To see the sensors data in the log file set the SENSOR_SYNC_SEND in your airframe file. Every time new data is available it will be sent directly.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> ''Please note: if you are using the master branch and have merged commits on or later than July 16, 2013, please replace SENSOR_SYNC_SEND with AIRSPEED_ETS_SYNC_SEND''<br />
<br />
===Result message===<br />
<br />
The raw data (adc), estimated offset at init time (offset) and the converted result (scaled) is written to the log file.<br />
{{Box Code|conf/messages.xml|<br />
<source lang="xml"><br />
<message name="AIRSPEED_ETS" id="57"><br />
<field name="adc" type="uint16" /><br />
<field name="offset" type="uint16" /><br />
<field name="scaled" type="float" /><br />
</message><br />
</source><br />
}}<br />
<br />
<br />
Sample log file lines<br />
149.529 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.633 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.730 123 AIRSPEED_ETS 1627 1606 7.942226<br />
149.841 123 AIRSPEED_ETS 1628 1606 7.942226<br />
<br />
[[Category:User_Documentation]] [[Category:Modules]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Module/Airspeed_ETS&diff=15930Module/Airspeed ETS2013-09-16T14:00:52Z<p>Mbina: added warnings (pitfalls); fixed a type</p>
<hr />
<div>__NOTOC__<br />
[[Image:Ets_airspeed_v3.jpg|thumb|right|Eagletree Airspeed v3]]<br />
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree><br />
== Overview ==<br />
<br />
The EagleTree Airspeed Sensor is a low cost module and comes with a good pitot tube (Prandtl style, pitot-static tube) that includes static and dynamic ports. It has an I²C interface that connects directly to the Autopilot I²C port. The paparazzi autopilot code is able to regulate the throttle in order to keep the airspeed constant (and a minimum ground speed).<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||Module name||sensors/airspeed_ets<br />
|-<br />
|Sensor type<br />
|air speed<br />
|-<br />
|Range<br />
|4m/s .. 150m/s<br />
|-<br />
|Resolution<br />
|0.3m/s<br />
|-<br />
|Refresh rate<br />
|10Hz<br />
|-<br />
|I2C address<br />
|0xEA<br />
|}<br />
<br />
[http://www.eagletreesystems.com/Support/manuals/airspeed-v3.pdf Product data sheet]<br />
<br />
== Hardware ==<br />
<br />
The sensor directly interfaces to the 3.3V I2C port of the autopilots and is supplied by +5V. <br />
<br />
When you buy the airspeed sensor it is set to operate in the default mode. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Make sure you did not set it somehow to 3rd party mode.<br />
<br />
=== Wiring ===<br />
<br />
The ETS Airspeed sensor has an I2C cable with the following layout:<br />
{|border="1"<br />
|-valign="top"<br />
||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''<br />
|-<br />
|GND<br />
|white<br />
|-<br />
| +5V<br />
|red<br />
|-<br />
|SDA<br />
|yellow<br />
|-<br />
|SCL<br />
|brown<br />
|}<br />
<br />
Please refer to your boards documentation to find out the correct pinout on your board (which cable to connect to which pin). <br />
Below an example for the TWOG v1.0 is given.<br />
<br />
==== Example: TWOG v1.0 ====<br />
<br />
This is the wiring for the TWOG v1.0 and the Eagle Tree Airspeed sensor on/for the I2C connector and serves as an example.<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||'''Autopilot I2C pin'''||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''<br />
|-<br />
|1<br />
|GND<br />
|white<br />
|-<br />
|2<br />
| +5V<br />
|red<br />
|-<br />
|3<br />
| +3.3V<br />
| do not connect<br />
|-<br />
|4<br />
|SDA<br />
|yellow<br />
|-<br />
|5<br />
|SCL<br />
|brown<br />
|}<br />
<br />
<br />
== Usage ==<br />
<br />
To use it load the ''airspeed_ets'' module:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
...<br />
<load name="airspeed_ets.xml" /><br />
...<br />
</modules><br />
</source><br />
}}<br />
<br />
Depending on your board and the I2C interface you are using, you may need to<br />
enable I2CX, where X is 0,1,2,etc., if you are not using it already:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware><br />
...<br />
<define name="USE_I2C0" /> <!-- In case you attached the ETS module to I2C0 --><br />
<define name="USE_I2C1" /> <!-- In case you attached the ETS module to I2C1 --><br />
<define name="USE_I2C2" /> <!-- In case you attached the ETS module to I2C2 --><br />
<define name="USE_I2C3" /> <!-- In case you attached the ETS module to I2C3 --><br />
</firmware><br />
</source><br />
}}<br />
<br />
<br />
=== Configuration ===<br />
<br />
You can also set some '''optional parameters to change the default configuration'''. <br />
For example to use I2C1 instead of I2C0, a scale of 2 (default is 1.8) and offset of 50 (default is 0) is needed:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<!-- Applies if another I2C interface than IC20 is used --><br />
<define name="AIRSPEED_ETS_SCALE" value="2"/> <br />
<define name="AIRSPEED_ETS_OFFSET" value="50"/><br />
<define name="AIRSPEED_ETS_I2C_DEV" value="i2c1"/> <br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
<br />
== Usage as sensor for speed control ==<br />
<br />
To use the sensor to control the speed of your aircraft add the aggressive climb flag, define which I2C device you are enabling and enable airspeed control:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<target name="ap" board="twog_1.0"><br />
<define name="AGR_CLIMB"/><br />
<define name="USE_I2C0"/> <!-- Details: see above --><br />
<define name="USE_AIRSPEED"/> <!-- Use the airspeed sensor in the control loop --><br />
</target><br />
</source><br />
}}<br />
<br />
=== Airframe configuration ===<br />
<br />
Now to use real airspeed values for adjusting your aircrafts autopilot behavior, add the following to the end of the "VERTICAL CONTROL" section of your airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="VERTICAL_CONTROL" prefix="V_CTL_"><br />
....<br />
<!-- auto airspeed and altitude inner loop (for airspeed sensor) --><br />
<define name="AUTO_AIRSPEED_SETPOINT" value="13.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_AIRSPEED_PGAIN" value="0.060" /><br />
<define name="AUTO_AIRSPEED_IGAIN" value="0.050" /> <br />
<br />
<define name="AUTO_GROUNDSPEED_SETPOINT" value="7.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_GROUNDSPEED_PGAIN" value="0.75" /><br />
<define name="AUTO_GROUNDSPEED_IGAIN" value="0.25" /><br />
</section><br />
</source><br />
}}<br />
<br />
Note that the SETPOINT values may need to be adjusted to suit your aircraft.<br />
<br />
Note that depending on whether you set the AIRSPEED setpoint or the GROUNDSPEED setpoint higher, either constant airspeed or constant groundspeed, respectively, will be the goal of the controller.<br />
<br />
See paparazzi/conf/airframes/easystar_ets_example.xml for an example airframe configuration.<br />
<br />
=== Debugging and logging the airspeed values ===<br />
<br />
To debug or log the raw values from the ETS airspeed sensor define SENSOR_SYNC_SEND in your airframe file to send the message AIRSPEED_ETS on every sensor reading. <br />
Note that defining this sends the AIRSPEED_ETS message at the sensor read rate as defined in conf/modules/airspeed_ets.xml. <br />
This does not have any bearing on the AIRSPEED message (if both SENSOR_SYNC_SEND and USE_AIRSPEED are defined, then both messages are sent). <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> ''Please note: if you are using the master branch and have merged commits on or later than July 16, 2013, please replace SENSOR_SYNC_SEND with AIRSPEED_ETS_SYNC_SEND''<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
The general airspeed can be displayed in the Messages tool by adding the AIRSPEED message to the telemetry file as follows:<br />
{{Box Code|conf/telemetry/default.xml|<br />
<source lang="xml"><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="AIRSPEED" period="1.0"/><br />
...<br />
</source><br />
}}<br />
<br />
The AIRSPEED_ETS message does NOT need to be added to the telemetry configuration since it is sent directly by the module if SENSOR_SYNC_SEND is defined.<br />
<br />
=== NOTES ===<br />
# In the GCS, the strip displays ground speed and '''not''' airspeed by default. In order to display airspeed, drag-and-drop the airspeed message field from the Messages tool onto the 2D map of the GCS. <br />
# The telemetry name AIRSPEED" should actually be called SPEED and contains Groundspeed and airspeed return values.<br />
<br />
== Measurement only ==<br />
<br />
To use the sensor for airspeed measurement is also possible. This Measurement only mode does thus not imput to the control loops to have effect to the aircraft behaviour.<br />
<br />
To see the sensors data in the log file set the SENSOR_SYNC_SEND in your airframe file. Every time new data is available it will be sent directly.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> ''Please note: if you are using the master branch and have merged commits on or later than July 16, 2013, please replace SENSOR_SYNC_SEND with AIRSPEED_ETS_SYNC_SEND''<br />
<br />
===Result message===<br />
<br />
The raw data (adc), estimated offset at init time (offset) and the converted result (scaled) is written to the log file.<br />
{{Box Code|conf/messages.xml|<br />
<source lang="xml"><br />
<message name="AIRSPEED_ETS" id="57"><br />
<field name="adc" type="uint16" /><br />
<field name="offset" type="uint16" /><br />
<field name="scaled" type="float" /><br />
</message><br />
</source><br />
}}<br />
<br />
<br />
Sample log file lines<br />
149.529 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.633 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.730 123 AIRSPEED_ETS 1627 1606 7.942226<br />
149.841 123 AIRSPEED_ETS 1628 1606 7.942226<br />
<br />
[[Category:User_Documentation]] [[Category:Modules]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Module/Airspeed_ETS&diff=15929Module/Airspeed ETS2013-09-16T13:57:38Z<p>Mbina: added additional info; reformatted the page a bit</p>
<hr />
<div>__NOTOC__<br />
[[Image:Ets_airspeed_v3.jpg|thumb|right|Eagletree Airspeed v3]]<br />
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree><br />
== Overview ==<br />
<br />
The EagleTree Airspeed Sensor is a low cost module and comes with a good pitot tube (Prandtl style, pitot-static tube) that includes static and dynamic ports. It has an I²C interface that connects directly to the Autopilot I²C port. The paparazzi autopilot code is able to regulate the throttle in order to keep the airspeed constant (and a minimum ground speed).<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||Module name||sensors/airspeed_ets<br />
|-<br />
|Sensor type<br />
|air speed<br />
|-<br />
|Range<br />
|4m/s .. 150m/s<br />
|-<br />
|Resolution<br />
|0.3m/s<br />
|-<br />
|Refresh rate<br />
|10Hz<br />
|-<br />
|I2C address<br />
|0xEA<br />
|}<br />
<br />
[http://www.eagletreesystems.com/Support/manuals/airspeed-v3.pdf Product data sheet]<br />
<br />
== Hardware ==<br />
<br />
The sensor directly interfaces to the 3.3V I2C port of the autopilots and is supplied by +5V. <br />
<br />
When you buy the airspeed sensor it is set to operate in the default mode. <br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Make sure you did not set it somehow to 3rd party mode.<br />
<br />
=== Wiring ===<br />
<br />
The ETS Airspeed sensor has an I2C cable with the following layout:<br />
{|border="1"<br />
|-valign="top"<br />
||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''<br />
|-<br />
|GND<br />
|white<br />
|-<br />
| +5V<br />
|red<br />
|-<br />
|SDA<br />
|yellow<br />
|-<br />
|SCL<br />
|brown<br />
|}<br />
<br />
Please refer to your boards documentation to find out the correct pinout on your board (which cable to connect which pin). <br />
Below an example for the TWOG v1.0 is given.<br />
<br />
==== Example: TWOG v1.0 ====<br />
<br />
This is the wiring for the TWOG v1.0 and the Eagle Tree Airspeed sensor on/for the I2C connector and serves as an example.<br />
<br />
{|border="1"<br />
|-valign="top"<br />
||'''Autopilot I2C pin'''||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''<br />
|-<br />
|1<br />
|GND<br />
|white<br />
|-<br />
|2<br />
| +5V<br />
|red<br />
|-<br />
|3<br />
| +3.3V<br />
| do not connect<br />
|-<br />
|4<br />
|SDA<br />
|yellow<br />
|-<br />
|5<br />
|SCL<br />
|brown<br />
|}<br />
<br />
<br />
== Usage ==<br />
<br />
To use it load the ''airspeed_ets'' module:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
...<br />
<load name="airspeed_ets.xml" /><br />
...<br />
</modules><br />
</source><br />
}}<br />
<br />
Depending on your board and the I2C interface you are using, you may need to<br />
enable I2CX, where X is 0,1,2,etc., if you are not using it already:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware><br />
...<br />
<define name="USE_I2C0" /> <!-- In case you attached the ETS module to I2C0 --><br />
<define name="USE_I2C1" /> <!-- In case you attached the ETS module to I2C1 --><br />
<define name="USE_I2C2" /> <!-- In case you attached the ETS module to I2C2 --><br />
<define name="USE_I2C3" /> <!-- In case you attached the ETS module to I2C3 --><br />
</firmware><br />
</source><br />
}}<br />
<br />
<br />
=== Configuration ===<br />
<br />
You can also set some '''optional parameters to change the default configuration'''. <br />
For example to use I2C1 instead of I2C0, a scale of 2 (default is 1.8) and offset of 50 (default is 0) is needed:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<!-- Applies if another I2C interface than IC20 is used --><br />
<define name="AIRSPEED_ETS_SCALE" value="2"/> <br />
<define name="AIRSPEED_ETS_OFFSET" value="50"/><br />
<define name="AIRSPEED_ETS_I2C_DEV" value="i2c1"/> <br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
<br />
== Usage as sensor for speed control ==<br />
<br />
To use the sensor to control the speed of your aircraft add the aggressive climb flag, define which I2C device you are enabling and enable airspeed control:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<target name="ap" board="twog_1.0"><br />
<define name="AGR_CLIMB"/><br />
<define name="USE_I2C0"/> <!-- Details: see above --><br />
<define name="USE_AIRSPEED"/> <!-- Use the airspeed sensor in the control loop --><br />
</target><br />
</source><br />
}}<br />
<br />
=== Airframe configuration ===<br />
<br />
Now to use real airspeed values for adjusting your aircrafts autopilot behavior, add the following to the end of the "VERTICAL CONTROL" section of your airframe file:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<section name="VERTICAL_CONTROL" prefix="V_CTL_"><br />
....<br />
<!-- auto airspeed and altitude inner loop (for airspeed sensor) --><br />
<define name="AUTO_AIRSPEED_SETPOINT" value="13.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_AIRSPEED_PGAIN" value="0.060" /><br />
<define name="AUTO_AIRSPEED_IGAIN" value="0.050" /> <br />
<br />
<define name="AUTO_GROUNDSPEED_SETPOINT" value="7.0" unit="m/s" /> <!-- SETPOINT values may need to be adjusted to suit your aircraft --><br />
<define name="AUTO_GROUNDSPEED_PGAIN" value="0.75" /><br />
<define name="AUTO_GROUNDSPEED_IGAIN" value="0.25" /><br />
</section><br />
</source><br />
}}<br />
<br />
Note that the SETPOINT values may need to be adjusted to suit your aircraft.<br />
<br />
Note that depending on whether you set the AIRSPEED setpoint or the GROUNDSPEED setpoint higher, either constant airspeed or constant groundspeed, respectively, will be the goal of the controller.<br />
<br />
See paparazzi/conf/airframes/easystar_ets_example.xml for an example airframe configuration.<br />
<br />
=== Debugging and logging the airspeed values ===<br />
<br />
To debug or log the raw values from the ETS airspeed sensor define SENSOR_SYNC_SEND in your airframe file to send the message AIRSPEED_ETS on every sensor reading. <br />
Note that defining this sends the AIRSPEED_ETS message at the sensor read rate as defined in conf/modules/airspeed_ets.xml. <br />
This does not have any bearing on the AIRSPEED message (if both SENSOR_SYNC_SEND and USE_AIRSPEED are defined, then both messages are sent). <br />
<br />
''Please note: if you are using the master branch and have merged commits on or later than July 16, 2013, please replace SENSOR_SYNC_SEND with AIRSPEED_ETS_SYNC_SEND''<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
The general airspeed can be displayed in the Messages tool by adding the AIRSPEED message to the telemetry file as follows:<br />
{{Box Code|conf/telemetry/default.xml|<br />
<source lang="xml"><br />
<process name="Ap"><br />
<mode name="default"><br />
<message name="AIRSPEED" period="1.0"/><br />
...<br />
</source><br />
}}<br />
<br />
The AIRSPEED_ETS message does NOT need to be added to the telemetry configuration since it is sent directly by the module if SENSOR_SYNC_SEND is defined.<br />
<br />
=== NOTES ===<br />
# In the GCS, the strip displays ground speed and '''not''' airspeed by default. In order to display airspeed, drag-and-drop the airspeed message field from the Messages tool onto the 2D map of the GCS. <br />
# The telemetry name AIRSPEED" should actually be called SPEED and contains Groundspeed and airspeed return values.<br />
<br />
== Measurement only ==<br />
<br />
To use the sensor for airspeed measurement is also possible. This Measurement only mode does thus not imput to the control loops to have effect to the aircraft behaviour.<br />
<br />
To see the sensors data in the log file set the SENSOR_SYNC_SEND in your airframe file. Every time new data is available it will be sent directly.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<modules><br />
<load name="airspeed_ets.xml"><br />
<define name="SENSOR_SYNC_SEND"/><br />
</load><br />
</modules><br />
</source><br />
}}<br />
<br />
===Result message===<br />
<br />
The raw data (adc), estimated offset at init time (offset) and the converted result (scaled) is written to the log file.<br />
{{Box Code|conf/messages.xml|<br />
<source lang="xml"><br />
<message name="AIRSPEED_ETS" id="57"><br />
<field name="adc" type="uint16" /><br />
<field name="offset" type="uint16" /><br />
<field name="scaled" type="float" /><br />
</message><br />
</source><br />
}}<br />
<br />
<br />
Sample log file lines<br />
149.529 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.633 123 AIRSPEED_ETS 1626 1606 8.024844<br />
149.730 123 AIRSPEED_ETS 1627 1606 7.942226<br />
149.841 123 AIRSPEED_ETS 1628 1606 7.942226<br />
<br />
[[Category:User_Documentation]] [[Category:Modules]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=HITL&diff=15928HITL2013-09-16T13:21:28Z<p>Mbina: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Simulation</categorytree><br />
__TOC__<br />
<br />
=Hardware In The Loop Simulation=<br />
<br />
Hardware in the loop simulations (HITL) are a way to test an embedded system (the real hardware and software) by simulating its environment, ie. sensor inputs, and comparing its output, ie. actuator outputs, to expected<br />
output values.<br />
<br />
==Principle==<br />
While the [[Simulation|Software In The Loop]] simulation (SITL) executes the airborne code on the ground host, HITL is a way to run the autopilot code on the actual hardware in an environment where sensors and actuators are simulated. Two processes are involved:<br />
* The real autopilot code on the control board;<br />
* A flight model combined with a model of the actuators and the sensors.<br />
Commands computed by the autopilot are sent to the flight model which sends back simulated values of the sensors output (e.g infrared and GPS).<br />
<br />
In Paparazzi, the link between the two processes is done through the telemetry/datalink:<br />
* Commands are sent through the standard '''COMMANDS''' telemetry message. Since the refresh rate must be high enough, a special telemetry file will be used (<tt>settings/hitl.xml</tt>)<br />
* Sensor values are sent through the '''HITL_UBX''' (GPS) and '''HITL_INFRARED''' datalink messages.<br />
<br />
==Configuration==<br />
The airborne code has to be compiled with a specific flag to use these '''HITL''' messages instead of the sensors. <br />
The following line must be added in the makefile section of the airframe file (here for a Tiny 1 board where the modem is plugged to the UART0):<br />
<source lang="make"><br />
ap.CFLAGS += -DHITL -UGPS_CONFIGURE -UUART0_BAUD -DUART0_BAUD=B57600<br />
</source><br />
Note that a high baudrate (at least 57600) is required to allow the '''COMMANDS''' messages to be correctly transmitted.<br />
<br />
The code has to be compiled ('''ap''' target) as usual and uploaded to the board. The '''HITL''' A/C entry provides an example of configuration for a Tiny 1 board (set UART1_BAUD for a Tiny 2).<br />
<source lang="xml"><br />
<aircraft name="HITL" ac_id="7"<br />
airframe="airframes/tiny_hitl.xml"<br />
telemetry="telemetry/hitl.xml"<br />
...<br />
/><br />
</source><br />
<br />
The '''HITL''' session entry gives an example of the corresponding session involving the <tt>simhitl</tt> simulator agent, ran with the <tt>-ac HITL</tt> option (the name of the simulated aircraft), and the standard link, server and GCS. The link can be done with a serial cable (probably through USB) or with the installed modem.<br />
<source lang="xml" ><br />
<session name="HITL"><br />
<program name="Hardware in the Loop"><br />
<arg flag="-a" constant="HITL"/><br />
<arg flag="-noground"/><br />
<arg flag="-boot"/><br />
</program><br />
<program name="Data Link"><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
</session><br />
</source><br />
<br />
<br />
==Datalink through the USB link==<br />
<br />
As explained in this [[DevGuide/USB-Serial|page]], the USB link (used to flash the board) can replace the serial link. It is probably the easiest way to run a HITL session since a single cable is required between the host and the board. Using a USB powered developement board (such as [http://www.olimex.com/dev/lpc-h2148.html this one]), HITL simulation becomes as easy as the [[Simulation|SITL one]].<br />
<br />
The <tt>hitl_usb.xml</tt> airframe file contains a minimal configuration (it is worth noticing that the useless <tt>servos</tt> section has been removed in this file) of HITL with serial USB. <br />
The specific lines of the makefile section are:<br />
{{Box Code|hitl_usb.xml|<br />
<source lang="make"><br />
ap.CFLAGS += -DDOWNLINK -DDOWNLINK_TRANSPORT=PprzTransport -DUSE_USB_SERIAL<br />
ap.CFLAGS += -DDOWNLINK_FBW_DEVICE=UsbS -DDOWNLINK_AP_DEVICE=UsbS -DPPRZ_UART=UsbS -DDATALINK=PPRZ<br />
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c $(SRC_ARCH)/usb_ser_hw.c datalink.c pprz_transport.c<br />
ap.srcs += $(SRC_ARCH)/lpcusb/usbhw_lpc.c $(SRC_ARCH)/lpcusb/usbcontrol.c<br />
ap.srcs += $(SRC_ARCH)/lpcusb/usbstdreq.c $(SRC_ARCH)/lpcusb/usbinit.c<br />
ap.CFLAGS += -DHITL<br />
</source>}}<br />
<br />
Compile it and flash it as usual.<br />
<br />
The port to use for the '''link''' agent is then <tt>/dev/ttyACM0</tt><br />
<br />
[[Category:Simulation]] [[Category:Software]] [[Category:Hardware]] [[Category:Developer_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Logs&diff=15916Logs2013-09-15T19:47:01Z<p>Mbina: added: syntax highlighting</p>
<hr />
<div>On each launch, the <tt>[[Server]]</tt> creates a ''log'' of all the messages sent by the aircraft. This log can be used to analyse flight data and to replay the flight.<br />
<br />
==Format==<br />
<br />
The log files are stored in the <tt>var/logs/</tt> folder (under <tt>PAPARAZZI_HOME</tt>). A log is split into two files:<br />
* A <tt>.log</tt> file, an XML file, which contains a copy of the whole configuration (airframes, flight plans, ...).<br />
* A <tt>.data</tt> file, an ascii file, which contains the list of the received messages. Each message is time-stamped in seconds since the creation of the file and marked with the id of the sending aircraft.<br />
<br />
The basename of these two files is the same and is build from the date and time at the creation.<br />
<br />
The lines of the <tt>.data</tt> file are formatted according to the message description listed in the <tt>conf/messages.xml</tt> file. For example, the following line:<br />
3.300 6 GPS 3 36028551 481359212 899 18500 0 -8 960 31 0<br />
contains a <tt>GPS</tt> message received at time 3.3s, from aircraft 6. According the GPS message description:<br />
<source lang="xml" ><br />
<message name="GPS" ID="8"><br />
<field name="mode" type="uint8" unit="byte_mask" ></field><br />
<field name="utm_east" type="int32" unit="cm" ></field><br />
<field name="utm_north" type="int32" unit="cm" ></field><br />
<field name="course" type="int16" unit="decideg" ></field><br />
<field name="alt" type="int32" unit="cm" ></field><br />
...<br />
</message><br />
</source><br />
<br />
UTM position is 360285.51m east, 4813592.12m north, course is 89.9° (east), altitude is 185m, ...<br />
Note that the appropriate <tt>messages.xml</tt> description, i.e. the one which has been used while the log was created, is itself stored in the associated <tt>.log</tt> file. It may differ from the current one installed in your <tt>conf/</tt> folder.<br />
<br />
Note: The <tt>.data</tt> files may be huge (about 4M per hour with a standard telemetry configuration). They can be efficiently compressed. The tools described in the next sections handle most of the compressed format (.zip, .gz, .bz2, ...). The bzip2 compression seems to perform better than others on these files.<br />
<br />
==Data Plotting==<br />
<br />
Data stored in log files can be plotted with the [[Plotter]] (<tt>sw/logalizer/plot</tt> or launchable from the [[Paparazzi Center]]). This tool can plot data from different logs in the same window and data from the same log in different windows. It also offers to export the track as a KML file for [http://earth.google.com Google Earth].<br />
<br />
==Replay==<br />
A flight can be replayed with the Log Flight Player (<tt>sw/logalizer/play</tt>, launchable from the [[Paparazzi Center]]). This agent then is a substitute for the Data Link agent and will send over the bus the messages which had been send by the aircraft while the log was recorded.<br />
<br />
Note: While replaying a log, it is a good idea to disable a new log creation from the server (<tt>-n</tt> option). <br />
<br />
When doing a log replay it is very valuable to launch the messages window (in the tools menu) as well. This allows for the use of the the real time plotter and also gives the data from the aircraft to the user.<br />
<br />
If the user wishes to speed up a replay gaia can be used (launch from paparazzi centers tools menu) to do this by changing the time scale.<br />
<br />
A <tt>.log</tt> file given in the command line will be loaded on startup.<br />
<br />
===Output on a serial port===<br />
Launched with the <tt>-o</tt> option, the player will send to a serial port all the binary messages, as they have been received through the modem during the flight. Related options:<br />
* <tt>-s</tt> Set the baudrate (<tt>9600</tt>)<br />
* <tt>-d</tt> Set the device (<tt>/dev/ttyUSB0</tt>)<br />
<br />
==Load PprzLog into Matlab Workspace==<br />
Paparazzi log file could also be converted into matrices in matlab workspace for further data processing. An example matlab script is shown in [http://paparazzi.enac.fr/wiki/Image:PprzLog2Matlab_1_0.zip PprzLog2Matlab_1_0.zip]. The example script needs the inputs of the log file name and directory. Just modify the line "fid = fopen('.\FlighLog20090321_MZN\09_03_19__15_03_14.data','r');". Eight matrices are read into matlab workspace including GPS_SOL, GPS, PPRZ_MODE, DESIRED, ATTITUDE, NAVIGATION, NAVIGATION_REF, COMMANDS. The user could also modify the code easily to add more messages they want to know.<br />
<br />
[[Image:logviewer.png|thumb|right|The logviewer GUI]]<br />
There is now another parser named <tt>log2struct</tt> available, see [http://lists.gnu.org/archive/html/paparazzi-devel/2009-08/msg00135.html this post on the mailing list].<br />
It does not require code modification and can read any messages sent from any aircraft.<br />
Usage examples can be found in the source code documentation.<br />
<br />
A GUI built on this parser is available: [http://paparazzi.enac.fr/wiki_images/Logviewer.zip Logviewer.zip].<br />
It is based on the GUI from <tt>sw/logalizer/matlab_log</tt> but features some improvements, e.g. in speed and reliability.<br />
Standard plots like trajectory, attitude or speed are available for quick reviewing and Matlab's plotting tools can be accessed for plot cosmetics and printing.<br />
<br />
==NMEA output==<br />
NMEA output is useful for [[Kinomap]], for example.<br />
<br />
Two methods exist for generating an NMEA gps log from the paparazzi logs:<br />
: 1- convert the .kml to .nmea by use of gpsbabel application (available on windows and linux)<br />
: 2- convert the .data to .nmea by use of perl script in sw/in_progress/log_parser/log2nmea.pl (also works on windows and linux)<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Talk:HITL&diff=15915Talk:HITL2013-09-15T19:38:49Z<p>Mbina: Created page with "The page seems to be a bit outdated ... is it?"</p>
<hr />
<div>The page seems to be a bit outdated ... is it?</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=HITL&diff=15914HITL2013-09-15T19:37:55Z<p>Mbina: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Simulation</categorytree><br />
__TOC__<br />
<br />
=Hardware In The Loop Simulation=<br />
<br />
Hardware in the loop simulations (HITL) are a way to test an embedded system (the real hardware and software) by simulating its environment, ie. sensor inputs, and comparing its output, ie. actuator outputs, to expected<br />
output values.<br />
<br />
==Principle==<br />
While the [[Simulation|Software In The Loop]] simulation (SITL) executes the airborne code on the ground host, HITL is a way to run the autopilot code on the actual hardware in an environment where sensors and actuators are simulated. Two processes are involved:<br />
* The real autopilot code on the control board;<br />
* A flight model combined with a model of the actuators and the sensors.<br />
Commands computed by the autopilot are sent to the flight model which sends back simulated values of the sensors output (e.g infrared and GPS).<br />
<br />
In Paparazzi, the link between the two processes is done through the telemetry/datalink:<br />
* Commands are sent through the standard '''COMMANDS''' telemetry message. Since the refresh rate must be high enough, a special telemetry file will be used (<tt>settings/hitl.xml</tt>)<br />
* Sensor values are sent through the '''HITL_UBX''' (GPS) and '''HITL_INFRARED''' datalink messages.<br />
<br />
==Configuration==<br />
The airborne code has to be compiled with a specific flag to use these '''HITL''' messages instead of the sensors. <br />
The following line must be added in the makefile section of the airframe file (here for a Tiny 1 board where the modem is plugged to the UART0):<br />
<source lang="make"><br />
ap.CFLAGS += -DHITL -UGPS_CONFIGURE -UUART0_BAUD -DUART0_BAUD=B57600<br />
</source><br />
Note that a high baudrate (at least 57600) is required to allow the '''COMMANDS''' messages to be correctly transmitted.<br />
<br />
The code has to be compiled ('''ap''' target) as usual and uploaded to the board. The '''HITL''' A/C entry provides an example of configuration for a Tiny 1 board (set UART1_BAUD for a Tiny 2).<br />
<source lang="xml"><br />
<aircraft name="HITL" ac_id="7"<br />
airframe="airframes/tiny_hitl.xml"<br />
telemetry="telemetry/hitl.xml"<br />
...<br />
/><br />
</source><br />
<br />
The '''HITL''' session entry gives an example of the corresponding session involving the <tt>simhitl</tt> simulator agent, ran with the <tt>-ac HITL</tt> option (the name of the simulated aircraft), and the standard link, server and GCS. The link can be done with a serial cable (probably through USB) or with the installed modem.<br />
<source lang="xml" ><br />
<session name="HITL"><br />
<program name="Hardware in the Loop"><br />
<arg flag="-a" constant="HITL"/><br />
<arg flag="-noground"/><br />
<arg flag="-boot"/><br />
</program><br />
<program name="Data Link"><br />
<arg flag="-s" constant="57600"/><br />
</program><br />
</session><br />
</source><br />
<br />
<br />
==Datalink through the USB link==<br />
<br />
As explained in this [[DevGuide/USB-Serial|page]], the USB link (used to flash the board) can replace the serial link. It is probably the easiest way to run a HITL session since a single cable is required between the host and the board. Using a USB powered developement board (such as [http://www.olimex.com/dev/lpc-h2148.html this one]), HITL simulation becomes as easy as the [[Simulation|SITL one]].<br />
<br />
The <tt>hitl_usb.xml</tt> airframe file contains a minimal configuration (it is worth noticing that the useless <tt>servos</tt> section has been removed in this file) of HITL with serial USB. <br />
The specific lines of the makefile section are:<br />
<source lang="make"><br />
ap.CFLAGS += -DDOWNLINK -DDOWNLINK_TRANSPORT=PprzTransport -DUSE_USB_SERIAL<br />
ap.CFLAGS += -DDOWNLINK_FBW_DEVICE=UsbS -DDOWNLINK_AP_DEVICE=UsbS -DPPRZ_UART=UsbS -DDATALINK=PPRZ<br />
ap.srcs += downlink.c $(SRC_ARCH)/uart_hw.c $(SRC_ARCH)/usb_ser_hw.c datalink.c pprz_transport.c<br />
ap.srcs += $(SRC_ARCH)/lpcusb/usbhw_lpc.c $(SRC_ARCH)/lpcusb/usbcontrol.c<br />
ap.srcs += $(SRC_ARCH)/lpcusb/usbstdreq.c $(SRC_ARCH)/lpcusb/usbinit.c<br />
ap.CFLAGS += -DHITL<br />
</source><br />
<br />
Compile it and flash it as usual.<br />
<br />
The port to use for the '''link''' agent is then <tt>/dev/ttyACM0</tt><br />
<br />
[[Category:Simulation]] [[Category:Software]] [[Category:Hardware]] [[Category:Developer_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Fixedwing_Configuration&diff=15913Fixedwing Configuration2013-09-15T19:30:02Z<p>Mbina: </p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree><br />
This page describes configuration options <span style="color:red"><b>specific to the fixedwing firmware</b></span> in the [[Airframe_Configuration|airframe file]].<br />
== Firmware and Hardware definitions ==<br />
<br />
=== Select your Board ===<br />
Make sure you use the <b>fixedwing [[Airframe_Configuration#Firmware|firmware]]</b> and choose the correct board, e.g.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="sim" board="pc"/> <!-- For simulation --><br />
<target name="ap" board="twog_1.0"/> <!-- Select your board here --><br />
...<br />
</firmware><br />
</source><br />
}}<br />
<br />
You can find the correct value to give for your board on the board [[Autopilots|specific page]].<br />
<br />
=== Attitude and Heading Reference System (AHRS) ===<br />
<br />
Next the filter for attitude estimation needs to be selected, where<br />
the tratidtional approach is to use infrared sensors (see blow).<br />
To select the type of [[Subsystem/ahrs|AHRS]] use the subsystem-tag as follows:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="ap" board="tiny_2.11"/><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_quat"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
==== Infrared Sensors ====<br />
To use the IR sensors for attitude estimation add the infrared module and ahrs infrared subsystem:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="ap" board="tiny_2.11"/><br />
...<br />
<subsystem name="ahrs" type="infrared"/><br />
</firmware><br />
<modules><br />
<load name="infrared_adc.xml"/><br />
</modules><br />
</source><br />
}}<br />
<br />
See the [[Module/infrared|infrared module page]] for more details on configuration.<br />
<br />
=== Control loops ===<br />
<br />
The [[Control_Loops#Fixed-wing_autopilot|control loops]] can be divided in two largely independent groups: <br />
* The vertical loop (sw/airborne/firmwares/fixedwing/guidance/guidance_v.c)<br />
* The horizontal loop (sw/airborne/firmwares/fixedwing/stabilization/stabilization_attitude.c)<br />
Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.<br />
<br />
Just specify the appropriate subsystem in your firmware section. <br />
Currently you can choose between no type (see below) and the types '''adaptive''', '''new''' and '''[[EnergyControl|energy]]'''.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="ap" board="tiny_2.11"/><br />
...<br />
<subsystem name="control" /> <!-- Standard fixed wing control loops --><br />
<br />
<!-- Different control loop types can be enabled instead (Use only one) --><br />
<subsystem name="control" type="adaptive"/> <!-- fixed wing control loops with adaptive horizontal control, standard vertical control --><br />
<subsystem name="control" type="new"/> <!-- new fixed wing control loops with merged auto pitch and auto throttle, adaptive horizontal control --><br />
<subsystem name="control" type="energy"/> <!-- Since v4.1.0 --><br />
<br />
</firmware><br />
</source><br />
}}<br />
<br />
== XML Parameters ==<br />
<br />
<br />
=== Manual ===<br />
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:<br />
<source lang="xml"><br />
<rc_commands><br />
<set command="THROTTLE" value="@THROTTLE"/><br />
<set command="ROLL" value="@ROLL"/><br />
<set command="PITCH" value="@PITCH"/><br />
</rc_commands><br />
</source><br />
This example looks trivial since the channel values have the same name than the commands.<br />
<br />
=== RC commands in Auto ===<br />
To control servos or other servo signal compatible devices by RC in Auto1 or Auto2, define them in the <auto_rc_commands> section.<br />
If you have an airframe with a dedicated rudder (YAW channel) then it is still controllable in auto mode via RC. This is the default behavior and is equivalent to setting the YAW command in auto_rc_commands:<br />
<source lang="xml"><br />
<auto_rc_commands><br />
<set command="YAW" value="@YAW"/><br />
</auto_rc_commands><br />
</source><br />
To disable this behavior (meaning no RC control of the rudder in auto) define an empty auto_rc_commands section:<br />
<source lang="xml"><br />
<auto_rc_commands><br />
</auto_rc_commands><br />
</source><br />
<br />
=== Autopilot Only Commands ===<br />
For certain missions it might be required to control servos (payload) from the autopilot (gcs) at all times (even during manual flight). These commands should not be in the <rc_commands> block but in the special <ap_only_commands> block. This allows for instance the pantilt operator to keep working when in manual flight, or safety logic to automatically close cameras below a certain altitude during manual landings.<br />
<source lang="xml"><br />
<ap_only_commands><br />
<copy command="PAN" /><br />
<copy command="TILT" /><br />
<copy command="SHOOT" /><br />
</ap_only_commands><br />
</source><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 />
<source lang="xml"><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="35" unit="deg" /><br />
<define name="MAX_PITCH" value="5" unit="deg" /><br />
</section><br />
</source><br />
<br />
''NOTE'': [[Units|automatic unit conversion]] using <tt>unit="deg"</tt> is supported since v3.9, if you have an older version set it in radians or using <tt>value="RadOfDeg(35)"</tt><br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. For additional configuration to change the defaults, see the [[Module/infrared|infrared module page]].<br />
<br />
The only mandatory definitions are the sensor neutral readings and how the IR sensors are mounted.<br />
<br />
The electronic neutral of the sensors (a sensor here is a '''pair''' of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.<br />
<source lang="xml"><br />
<section name="INFRARED" prefix="IR_"><br />
<define name="ADC_IR1_NEUTRAL" value="512"/><br />
<define name="ADC_IR2_NEUTRAL" value="512"/><br />
<define name="ADC_TOP_NEUTRAL" value="512"/><br />
<define name="HORIZ_SENSOR_ALIGNED" value="1"/><br />
</section><br />
</source><br />
These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.<br />
<br />
In the example above the horizontal sensor is connected to the airframe in ''aligned'' orientation. The other possibility is ''tilted''.<br />
Define either<br />
* '''HORIZ_SENSOR_ALIGNED''': ir1 is along the lateral axis (The axis that passes through the plane from wingtip to wingtip) and ir2 along the longitudinal one.<br />
or<br />
* '''HORIZ_SENSOR_TILTED''': the sensors are tilted by 45 degrees; ir1 is along rear-left -- front-right, and ir2 along rear-right -- front-left.<br />
If the airframe construction allows choose an aligned sensor orientation since this gives the best stabilization response results.<br />
<br />
=== Gyro ===<br />
'''This section only applies to versions prior to v3.9 when using a gyro with IR sensors.'''<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 />
<source lang="xml"><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 />
</source><br />
<br />
=== Horizontal Control ===<br />
<source lang="xml"><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="0.4" /><br />
<define name="ROLL_MAX_SETPOINT" value="20" unit="deg" /><br />
<define name="ROLL_ATTITUDE_GAIN" value="7500." /><br />
<define name="ROLL_RATE_GAIN" value="1500" /><br />
<define name="PITCH_PGAIN" value="8000." /><br />
<define name="ELEVATOR_OF_ROLL" value="1250" /><br />
</section><br />
</source><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 />
The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.<br />
<br />
<br />
'''IMPORTANT''': Previous to v3.9 some of the gains need to be set with a '''negative sign''': ''COURSE_PGAIN'', ''ROLL_ATTITUDE_GAIN'', ''ROLL_RATE_GAIN'', ''PITCH_PGAIN''<br />
<br />
''NOTE'': [[Units|automatic unit conversion]] using <tt>unit="deg"</tt> is supported since v3.9, if you have an older version set it in radians or using <tt>value="RadOfDeg(20)"</tt><br />
<br />
The [[Control_Loops#Fixed-wing_autopilot|graphical representation of the control loops]] can help you to visualize the effect of each gain.<br />
<br />
===Vertical Control===<br />
<source lang="xml"><br />
<section name="VERTICAL CONTROL" prefix="V_CTL_"><br />
<!-- outer loop proportional gain --><br />
<define name="ALTITUDE_PGAIN" value="0.1" unit="(m/s)/m" /><br />
<!-- outer loop saturation --><br />
<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s" /><br />
</source><br />
These lines are associated with vertical control loops contained in sw/airborne/firmwares/fixedwing/guidance/guidance_v.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate<br />
<source lang="xml"><br />
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%" /><br />
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%" /><br />
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%" /><br />
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t" /><br />
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t" /><br />
<define name="AUTO_THROTTLE_PGAIN" value="0.008" unit="%/(m/s)"/><br />
<define name="AUTO_THROTTLE_IGAIN" value="0.25" /><br />
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)" /><br />
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)" /><br />
</source><br />
<br />
These lines are associated with vertical rate control loops contained in sw/airborne/firmwares/fixedwing/guidance/guidance_v.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.<br />
<source lang="xml"><br />
<define name="AUTO_PITCH_PGAIN" value="0.1"/><br />
<define name="AUTO_PITCH_IGAIN" value="0.025"/><br />
<define name="AUTO_PITCH_MAX_PITCH" value="30" unit="deg"/><br />
<define name="AUTO_PITCH_MIN_PITCH" value="30" unit="deg"/><br />
</source><br />
These lines are associated with vertical control loops contained in sw/airborne/firmwares/fixedwing/guidance/guidance_v.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.<br />
<source lang="xml"><br />
<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/><br />
</source><br />
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.<br />
<br />
<br />
'''IMPORTANT''': Previous to v3.9 some of the gains need to be set with a '''negative sign''': ''ALTITUDE_PGAIN'', ''AUTO_THROTTLE_PGAIN'', ''AUTO_PITCH_PGAIN'', ''''<br />
<br />
''NOTE'': [[Units|automatic unit conversion]] using <tt>unit="deg"</tt> is supported since v3.9, if you have an older version set it in radians or using <tt>value="RadOfDeg(20)"</tt><br />
<br />
The [[Control_Loops#Fixed-wing_autopilot|graphical representation of the control loops]] can help you to visualize the effect of each gain.<br />
<br />
=== Misc ===<br />
<source lang="xml"><br />
<section name="MISC"><br />
<define name="NOMINAL_AIRSPEED" value ="12.0" unit="m/s" /><br />
<define name="CONTROL_RATE" value="60" unit="Hz"/><br />
<define name="CARROT" value="5.0" unit="s" /><br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
</section><br />
</source><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 />
=== Simu ===<br />
Values from this section can be used to tweak the software in the loop (SITL) simulation.<br />
<source lang="xml"><br />
<section name="SIMU"><br />
<define name="WEIGHT" value ="1."/><br />
<define name="YAW_RESPONSE_FACTOR" value ="1."/><br />
<define name="ROLL_RESPONSE_FACTOR" value ="15."/><br />
</section><br />
</source><br />
* "YAW_RESPONSE_FACTOR" adapts the aircraft's turn rate corresponding to a bank angle; a larger value increases the turn radius<br />
* "ROLL_RESPONSE_FACTOR" is basically your aileron efficiency; a higher value increases roll agility<br />
<br />
If you want to use JSBSim as SITL simulator, you have to make some definitions in this section as well; see [[Simulation#JSBSim|here]].<br />
<br />
<br />
[[Category:User_Documentation]] [[Category:Airframe_Configuration]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Fixedwing_Configuration&diff=15912Fixedwing Configuration2013-09-15T19:20:13Z<p>Mbina: added general AHRS info; minor changes;</p>
<hr />
<div><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree><br />
This page describes configuration options <span style="color:red"><b>specific to the fixedwing firmware</b></span> in the [[Airframe_Configuration|airframe file]].<br />
== Firmware and Hardware definitions ==<br />
<br />
=== Select your Board ===<br />
Make sure you use the <b>fixedwing [[Airframe_Configuration#Firmware|firmware]]</b> and choose the correct board, e.g.<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="sim" board="pc"/><br />
<target name="ap" board="twog_1.0"/><br />
...<br />
</firmware><br />
</source><br />
}}<br />
<br />
=== Attitude and Heading Reference System (AHRS) ===<br />
<br />
Next the filter for attitude estimation needs to be selected, where<br />
the tratidtional approach is to use infrared sensors (see blow).<br />
To select the type of [[Subsystem/ahrs|AHRS]] use the subsystem-tag as follows:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="ap" board="tiny_2.11"/><br />
...<br />
<subsystem name="ahrs" type="int_cmpl_quat"/><br />
</firmware><br />
</source><br />
}}<br />
<br />
==== Infrared Sensors ====<br />
To use the IR sensors for attitude estimation add the infrared module and ahrs infrared subsystem:<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="ap" board="tiny_2.11"/><br />
...<br />
<subsystem name="ahrs" type="infrared"/><br />
</firmware><br />
<modules><br />
<load name="infrared_adc.xml"/><br />
</modules><br />
</source><br />
}}<br />
<br />
See the [[Module/infrared|infrared module page]] for more details on configuration.<br />
<br />
=== Control loops ===<br />
<br />
The [[Control_Loops#Fixed-wing_autopilot|control loops]] can be divided in two largely independent groups: <br />
* The vertical loop (sw/airborne/firmwares/fixedwing/guidance/guidance_v.c)<br />
* The horizontal loop (sw/airborne/firmwares/fixedwing/stabilization/stabilization_attitude.c)<br />
Those loops can be commanded at different levels by either the R/C transmitter or the autonomous navigation routine.<br />
<br />
Just specify the appropriate subsystem in your firmware section. <br />
Currently you can choose between no type (see below) and the types '''adaptive''', '''new''' and '''[[EnergyControl|energy]]'''.<br />
<br />
{{Box Code|conf/airframes/myplane.xml|<br />
<source lang="xml"><br />
<firmware name="fixedwing"><br />
<target name="ap" board="tiny_2.11"/><br />
...<br />
<subsystem name="control" /> <!-- Standard fixed wing control loops --><br />
<br />
<!-- Different control loop types can be enabled instead (Use only one) --><br />
<subsystem name="control" type="adaptive"/> <!-- fixed wing control loops with adaptive horizontal control, standard vertical control --><br />
<subsystem name="control" type="new"/> <!-- new fixed wing control loops with merged auto pitch and auto throttle, adaptive horizontal control --><br />
<subsystem name="control" type="energy"/> <!-- Since v4.1.0 --><br />
<br />
</firmware><br />
</source><br />
}}<br />
<br />
== XML Parameters ==<br />
<br />
<br />
=== Manual ===<br />
The <tt>rc_command</tt> sections links the channels of the RC transmitter (defined in the [[Radio_Control|Radio Control]] file) to the <tt>commands</tt> defined above:<br />
<source lang="xml"><br />
<rc_commands><br />
<set command="THROTTLE" value="@THROTTLE"/><br />
<set command="ROLL" value="@ROLL"/><br />
<set command="PITCH" value="@PITCH"/><br />
</rc_commands><br />
</source><br />
This example looks trivial since the channel values have the same name than the commands.<br />
<br />
=== RC commands in Auto ===<br />
To control servos or other servo signal compatible devices by RC in Auto1 or Auto2, define them in the <auto_rc_commands> section.<br />
If you have an airframe with a dedicated rudder (YAW channel) then it is still controllable in auto mode via RC. This is the default behavior and is equivalent to setting the YAW command in auto_rc_commands:<br />
<source lang="xml"><br />
<auto_rc_commands><br />
<set command="YAW" value="@YAW"/><br />
</auto_rc_commands><br />
</source><br />
To disable this behavior (meaning no RC control of the rudder in auto) define an empty auto_rc_commands section:<br />
<source lang="xml"><br />
<auto_rc_commands><br />
</auto_rc_commands><br />
</source><br />
<br />
=== Autopilot Only Commands ===<br />
For certain missions it might be required to control servos (payload) from the autopilot (gcs) at all times (even during manual flight). These commands should not be in the <rc_commands> block but in the special <ap_only_commands> block. This allows for instance the pantilt operator to keep working when in manual flight, or safety logic to automatically close cameras below a certain altitude during manual landings.<br />
<source lang="xml"><br />
<ap_only_commands><br />
<copy command="PAN"/><br />
<copy command="TILT"/><br />
<copy command="SHOOT"/><br />
</ap_only_commands><br />
</source><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 />
<source lang="xml"><br />
<section name="AUTO1" prefix="AUTO1_"><br />
<define name="MAX_ROLL" value="35" unit="deg"/><br />
<define name="MAX_PITCH" value="5" unit="deg"/><br />
</section><br />
</source><br />
<br />
''NOTE'': [[Units|automatic unit conversion]] using <tt>unit="deg"</tt> is supported since v3.9, if you have an older version set it in radians or using <tt>value="RadOfDeg(35)"</tt><br />
=== Infrared === <br />
The <b><tt>INFRARED</tt></b> section describes the configuration of the infrared sensors. For additional configuration to change the defaults, see the [[Module/infrared|infrared module page]].<br />
<br />
The only mandatory definitions are the sensor neutral readings and how the IR sensors are mounted.<br />
<br />
The electronic neutral of the sensors (a sensor here is a '''pair''' of thermopiles). A perfect sensor should give 512 if it measures the same value on both sides.<br />
<source lang="xml"><br />
<section name="INFRARED" prefix="IR_"><br />
<define name="ADC_IR1_NEUTRAL" value="512"/><br />
<define name="ADC_IR2_NEUTRAL" value="512"/><br />
<define name="ADC_TOP_NEUTRAL" value="512"/><br />
<define name="HORIZ_SENSOR_ALIGNED" value="1"/><br />
</section><br />
</source><br />
These neutrals are tuned with the "cupboard test": Put the sensor in a close box (a cupboard) and read the values of the IR_SENSORS message (ir1, ir2 and vertical). Set the neutrals (they are subtracted from the measurement) to get null values. E.g. if you read 5 for the ir1 value with ADC_IR1_NEUTRAL equal to 512, change the latter to 517.<br />
<br />
In the example above the horizontal sensor is connected to the airframe in ''aligned'' orientation. The other possibility is ''tilted''.<br />
Define either<br />
* '''HORIZ_SENSOR_ALIGNED''': ir1 is along the lateral axis (The axis that passes through the plane from wingtip to wingtip) and ir2 along the longitudinal one.<br />
or<br />
* '''HORIZ_SENSOR_TILTED''': the sensors are tilted by 45 degrees; ir1 is along rear-left -- front-right, and ir2 along rear-right -- front-left.<br />
If the airframe construction allows choose an aligned sensor orientation since this gives the best stabilization response results.<br />
<br />
=== Gyro ===<br />
'''This section only applies to versions prior to v3.9 when using a gyro with IR sensors.'''<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 />
<source lang="xml"><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 />
</source><br />
<br />
=== Horizontal Control ===<br />
<source lang="xml"><br />
<section name="HORIZONTAL CONTROL" prefix="H_CTL_"><br />
<define name="COURSE_PGAIN" value="0.4"/><br />
<define name="ROLL_MAX_SETPOINT" value="20" unit="deg"/><br />
<define name="ROLL_ATTITUDE_GAIN" value="7500."/><br />
<define name="ROLL_RATE_GAIN" value="1500"/><br />
<define name="PITCH_PGAIN" value="8000."/><br />
<define name="ELEVATOR_OF_ROLL" value="1250"/><br />
</section><br />
</source><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 />
The ROLL_ATTITUDE_GAIN is used to compute a ROLL command from the roll error (setpoint minus measurement). If a gyro in installed, the ROLL_RATE_GAIN to keep a null roll rate. So these two gains provide a P-D controller.<br />
<br />
<br />
'''IMPORTANT''': Previous to v3.9 some of the gains need to be set with a '''negative sign''': ''COURSE_PGAIN'', ''ROLL_ATTITUDE_GAIN'', ''ROLL_RATE_GAIN'', ''PITCH_PGAIN''<br />
<br />
''NOTE'': [[Units|automatic unit conversion]] using <tt>unit="deg"</tt> is supported since v3.9, if you have an older version set it in radians or using <tt>value="RadOfDeg(20)"</tt><br />
<br />
The [[Control_Loops#Fixed-wing_autopilot|graphical representation of the control loops]] can help you to visualize the effect of each gain.<br />
<br />
===Vertical Control===<br />
<source lang="xml"><br />
<section name="VERTICAL CONTROL" prefix="V_CTL_"><br />
<!-- outer loop proportional gain --><br />
<define name="ALTITUDE_PGAIN" value="0.1" unit="(m/s)/m"/><br />
<!-- outer loop saturation --><br />
<define name="ALTITUDE_MAX_CLIMB" value="3." unit="m/s"/><br />
</source><br />
These lines are associated with vertical control loops contained in sw/airborne/firmwares/fixedwing/guidance/guidance_v.c. These are outer loop parameters that calculate a desired climb rate based on altitude error. Here, if the altitude error is 10m, the climb setpoint will be set to 1m/s. ALTITUDE_MAX_CLIMB is a bounded value (in m/s) so that the outer loop does not calculate too large of a climb rate<br />
<source lang="xml"><br />
<define name="AUTO_THROTTLE_NOMINAL_CRUISE_THROTTLE" value="0.65" unit="%"/><br />
<define name="AUTO_THROTTLE_MIN_CRUISE_THROTTLE" value=".4" unit="%"/><br />
<define name="AUTO_THROTTLE_MAX_CRUISE_THROTTLE" value="1" unit="%"/><br />
<define name="AUTO_THROTTLE_LOITER_TRIM" value="1000" unit="pprz_t"/><br />
<define name="AUTO_THROTTLE_DASH_TRIM" value="-2500" unit="pprz_t"/><br />
<define name="AUTO_THROTTLE_CLIMB_THROTTLE_INCREMENT" value="0.15" unit="%/(m/s)"/><br />
<define name="AUTO_THROTTLE_PGAIN" value="0.008" unit="%/(m/s)"/><br />
<define name="AUTO_THROTTLE_IGAIN" value="0.25"/><br />
<define name="AUTO_THROTTLE_PITCH_OF_VZ_PGAIN" value="0.35" unit="rad/(m/s)"/><br />
</source><br />
<br />
These lines are associated with vertical rate control loops contained in sw/airborne/firmwares/fixedwing/guidance/guidance_v.c and are used by default in most cases. The default vertical control law is for the vertical rate to be managed by a combination of throttle and pitch.<br />
<source lang="xml"><br />
<define name="AUTO_PITCH_PGAIN" value="0.1"/><br />
<define name="AUTO_PITCH_IGAIN" value="0.025"/><br />
<define name="AUTO_PITCH_MAX_PITCH" value="30" unit="deg"/><br />
<define name="AUTO_PITCH_MIN_PITCH" value="30" unit="deg"/><br />
</source><br />
These lines are associated with vertical control loops contained in sw/airborne/firmwares/fixedwing/guidance/guidance_v.c but are not used in default. The non-default vertical control law is for the vertical rate to be managed by the pitch.<br />
<source lang="xml"><br />
<define name="THROTTLE_SLEW_LIMITER" value="2" unit="s"/><br />
</source><br />
THROTTLE_SLEW_LIMITER is the required time is seconds to change throttle from 0% to 100%.<br />
<br />
<br />
'''IMPORTANT''': Previous to v3.9 some of the gains need to be set with a '''negative sign''': ''ALTITUDE_PGAIN'', ''AUTO_THROTTLE_PGAIN'', ''AUTO_PITCH_PGAIN'', ''''<br />
<br />
''NOTE'': [[Units|automatic unit conversion]] using <tt>unit="deg"</tt> is supported since v3.9, if you have an older version set it in radians or using <tt>value="RadOfDeg(20)"</tt><br />
<br />
The [[Control_Loops#Fixed-wing_autopilot|graphical representation of the control loops]] can help you to visualize the effect of each gain.<br />
<br />
=== Misc ===<br />
<source lang="xml"><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 />
</source><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 />
=== Simu ===<br />
Values from this section can be used to tweak the software in the loop (SITL) simulation.<br />
<source lang="xml"><br />
<section name="SIMU"><br />
<define name="WEIGHT" value ="1."/><br />
<define name="YAW_RESPONSE_FACTOR" value ="1."/><br />
<define name="ROLL_RESPONSE_FACTOR" value ="15."/><br />
</section><br />
</source><br />
* "YAW_RESPONSE_FACTOR" adapts the aircraft's turn rate corresponding to a bank angle; a larger value increases the turn radius<br />
* "ROLL_RESPONSE_FACTOR" is basically your aileron efficiency; a higher value increases roll agility<br />
<br />
If you want to use JSBSim as SITL simulator, you have to make some definitions in this section as well; see [[Simulation#JSBSim|here]].<br />
<br />
<br />
[[Category:User_Documentation]] [[Category:Airframe_Configuration]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Radio_Control&diff=15893Radio Control2013-09-12T21:59:17Z<p>Mbina: added: syntax highlighting ; fixed typos</p>
<hr />
<div>== PPM Radio Configuration ==<br />
<br />
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>. <b>This is only used for PPM transmitters so it does not apply to DSM/DSM2/FASST/FHSS or other 2.4Mhz radios.</b><br />
<br />
The contents are an '''ordered''' sequence of elements describing each channel with its name and its range:<br />
<br />
<tt><source lang="xml"><!DOCTYPE radio SYSTEM "radio.dtd"><br />
<radio name="cockpitMM" data_min="900" data_max="2100" sync_min ="5000" sync_max ="15000" pulse_type="POSITIVE"><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></source></tt><br />
<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 />
<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 />
* <tt>pulse_type</tt>: the polarity of the PPM pulse. Can be either <tt>POSITIVE</tt> (FUTABA, Hitec, Multiplex etc) or <tt>NEGATIVE</tt> (JR, Graupner etc.).<br/>With <tt>POSITIVE</tt> it will trigger on the rising flank to measure the time of the positive pulse, with <tt>NEGATIVE</tt> on the falling flank (for a negative pulse width).<br />
<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 />
'''Wrong attributes of the "radio" element will prevent the decoder to recognize any PPM frame; same for a wrong number or channels.'''<br />
<br />
=== Number of channels ===<br />
<br />
Note that the number of channels in your radio file <b>must exactly match</b> the number of channels in the ppm sum signal the autopilot receives.<br><br />
Also the ''function'' names must be unique.<br />
<br />
* in case of analog 35MHz receivers it is the RC - TRANSMITTER that makes the pulse train (receiver only does RF part) <br />
** radio file depends on transmitter, you could swap to another receiver (and e.g. you can use a 4channel receiver to receive 9 pulses :-) )<br />
* in case of digital receivers it is not the transmitter but the receiver that makes the pulses<br />
** e.g. Futaba Fasst 6017: you can use any compatible transmitter without need to change the radio file<br />
* in case of an encoder it is the encoder that makes the summed pulse<br />
** if the encoder software makes 8 pulses, even with a 5 channel RC connected paparazzi will get 8: so the radio file should read 8<br />
<br />
This means if your transmitter sends for example a PPM18 (Graupner/JR) signal you have nine (9) different servo channels. Even if you use a receiver with less channels you must set up <b>all</b> transmitting servos, even if you do not use them then you must use "bogus switches" related to functions. For example a six (6) servo channels out receiver with five (5) functions used in combination with a nine (9) servo channels transmitter would need four (4) bogus entries. (5 + 4 = 9)<br />
<br />
<source lang="xml"><br />
...<br />
<channel ctl="NoneA" function="NOTUSEDA" min="1100" neutral="1500" max="1900" average="0"/><br />
<channel ctl="NoneB" function="NOTUSEDB" min="1100" neutral="1500" max="1900" average="0"/><br />
<channel ctl="NoneC function="NOTUSEDC" min="1100" neutral="1500" max="1900" average="0"/><br />
<channel ctl="NoneD" function="NOTUSEDD" min="1100" neutral="1500" max="1900" average="0"/><br />
...<br />
</source><br />
<br />
<br />
=== Averaging ===<br />
<br />
The <tt>average</tt> attribute must be set to '''1..x''' 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. Note that averaging a channel gives the output an additional small delay.<br />
<br />
== Direction ==<br />
<br />
The following signs have been used in the radio configuration files distributed in <tt>conf/radios</tt>:<br />
<br />
* '''ROLL''': The <tt>min</tt> attribute value stands for the right position of the stick (turning right)<br />
* '''PITCH''': The <tt>max</tt> attribute value stands for the up position of the stick (pitching up)<br />
<br />
''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''<br />
* '''ROLL''': The <tt>max</tt> attribute value stands for the right position of the roll stick (banking right)<br />
* '''PITCH''': The <tt>max</tt> attribute value stands for the "up" position of the pitch stick pulled towards you (pitching up)<br />
* '''YAW''': The <tt>max</tt> attribute value stands for the right position of the yaw stick (yawing clock-wise)<br />
<br />
=== Practical test ===<br />
In the RC message:<br />
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to -MAX_PPRZ (-9600) in the ROLL channel<br />
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel<br />
<br />
''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''<br />
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to MAX_PPRZ (9600) in the ROLL channel<br />
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel<br />
* When the YAW stick is pulled to the right (aircraft yawing clock-wise), you should see a value close to MAX_PPRZ (9600) in the YAW channel<br />
<br />
This works with all kind of radios (PPM, USB, 2.4GHz)<br />
<br />
== Example ==<br />
<br />
Below you find an example of a radio file.<br />
<br />
<br />
<source lang="xml"><br />
<?xml version="1.0"?><br />
<br />
<!--<br />
-- Attributes of root (Radio) tag :<br />
-- name: name of RC<br />
-- min: min width of a pulse to be considered as a data pulse<br />
-- max: max width of a pulse to be considered as a data pulse<br />
-- sync: min width of a pulse to be considered as a synchro pulse<br />
-- min, max and sync are expressed in micro-seconds<br />
--><br />
<br />
<!--<br />
-- Attributes of channel tag :<br />
-- ctl: name of the command on the transmitter - only for displaying<br />
-- function: logical command<br />
-- average: (boolean) channel filtered through several frames (for discrete commands)<br />
-- min: minimum pulse length (micro-seconds)<br />
-- max: maximum pulse length (micro-seconds)<br />
-- neutral: neutral pulse length (micro-seconds)<br />
Note: a command may be reversed by exchanging min and max values<br />
--><br />
<br />
<radio name="GraupnerMC20" data_min="950" data_max="2150" sync_min="5000" sync_max="15000" pulse_type="NEGATIVE"><br />
<channel ctl="A" function="THROTTLE" min="1100" neutral="1100" max="1900" average="0"/> <!-- left stick up/down --><br />
<channel ctl="B" function="ROLL" min="1100" neutral="1500" max="1900" average="0"/> <!-- right stick left/right --><br />
<channel ctl="C" function="PITCH" min="1900" neutral="1500" max="1100" average="0"/> <!-- right stick up/down --><br />
<channel ctl="D" function="YAW" min="1100" neutral="1500" max="1900" average="0"/> <!-- left stick left/right--><br />
<channel ctl="E" function="MODE" min="1100" neutral="1500" max="1900" average="1"/> <!-- left middle 3-pos switch --><br />
<channel ctl="F" function="GAIN1" min="1100" neutral="1500" max="1900" average="0"/> <!-- left slider prop channel --><br />
<channel ctl="G" function="GAIN2" min="1100" neutral="1500" max="1900" average="0"/> <!-- right slider prop channel --><br />
<channel ctl="H" function="SWITCH1" min="1100" neutral="1500" max="1900" average="1"/> <!-- switch (channel 8) --><br />
<channel ctl="I" function="UNUSED" min="1100" neutral="1500" max="1900" average="1"/> <!-- channel 9 is transmitted but cannot be controlled --><br />
</radio><br />
</source><br />
<br />
<br />
== PPM input to output chain ==<br />
The chain from ppm input to servo output has intermediate steps and roughly looks like this:<br />
<br />
ppm input --(radio.xml)--> ppm_pulses[] --(radio.xml)--> radio_control.values[] --([[Fixedwing_Configuration#Manual|rc_commands]])--> commands[] --([[Fixedwing_Configuration#Servos|command_laws,servos]])--> actuators_pwm_values[] ppm out<br />
<br />
Written in parenthesis is where you configure how to transform one value into the other.<br />
<br />
So in a simple case without fancy mixing, e.g. looking at the roll command / aileron servo while in MANUAL mode:<br />
#PPM sum signal is read and split into channels as specified in your radio xml file.<br/>It does some sanity checking on the pulse length and frame lenght according to the top attributes in that file.<br/>This is written to the ppm_pulses array, where you now have the length of the pulse in system ticks.<br />
#Now these get converted to radio_control.values array according to the channels in your radio xml file.<br/>They get scaled to MAX_PPRZ (9600), meaning what you specified as max is 9600, neutral is 0, etc.<br/>radio_control.values[RADIO_ROLL] now has the value 9600 if the pulse width of that channels was "max"<br />
#Mapping of RC commands to the actual commands as specified in rc_commands section.<br/>In your case simply copy radio_control.values[RADIO_ROLL] to commands[COMMAND_ROLL]<br />
#Applying command_laws (mixing) to get the commands for each servo.<br/>Again just copying in your case...<br />
#Scaling from commands with MAX_PPRZ scale to the actual pwm output signal according to the servos section.<br />
<br />
== Measuring the PPM time values ==<br />
<br />
[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|R/C receiver timing diagram]]<br />
<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.<br />
<br />
With the default telemetry configuration file (<tt>conf/telemetry/default_fixedwing.xml</tt>), this message is '''not''' sent in the '''default''' fbw telemetry mode (numbered 0).<br />
<br />
There are two ways to enable this message:<br />
* Use the settings mechanism to change the FBW telemetry mode while the autopilot is already running:<br/>In the GCS: Settings -> telemetry -> tele_FBW -> set to debug (1)<br />
* This mode can be permanently changed to '''debug''' (numbered 1) in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant in your firmware section: <br />
<source lang="xml"><define name="TELEMETRY_MODE_FBW" value="1"/></source><br />
<br />
'''Since "v3.9" the values in the PPM message are in µs.'''<br />
<br />
Before "v3.9" the time unit used in this '''PPM''' message was 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/arch/lpc21/mcu_periph/sys_time_arch.h</tt>) !!!)<br />
<br />
== Tips ==<br />
<br />
If one has a good servo tester the output values at the receiver side can be measured<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Failsafe&diff=15892Failsafe2013-09-12T21:53:12Z<p>Mbina: minor changes; added example to "catastrophic battery level"</p>
<hr />
<div>Paparazzi has several built-in failsafe features ranging from lowlevel to highlevel and from implied to optional.<br />
<br />
On the lowest level, precise timing of the transmitter pulses creates safety that goes beyond traditional switches enabling safer use of old RC equipment.<br />
On the highest level, the [[Flight_Plans#Exceptions|exceptions]] feature of the flight-plans allow for very flexible custom built failsafe features.<br />
<br />
<br />
== Fly By Wire (FBW) ==<br />
<br />
=== 'Failsafe Switch' ===<br />
<br />
The lowest level of paparazzi is the FBW (Fly By Wire) controller that reads the RC, reads the autopilot commands and drives the servos based on the lowlevel failsafe options.<br />
<br />
This is the 'switch' between '''manual''' or '''automatic''' modes. Therefore there is no need for another failsafe board. Indeed, the paparazzi FBW has evolved with so much intelligence that it is certainly safer than some and probably at least as safe as any other failsafe switches. This is amongst others (besides the highlevel validated code, separated process, ...) because paparazzi FBW unlike generic switches is given precise remote control information in its RC.xml. If you use a wrong type of transmitter (e.g. not the right amount of channels, or not the correct interval or sync pulse length) then even when on the same frequency the FBW will not listen to the commands. Also, if 2 transmitters are on the same frequency, then the chance of both signals together still being read as valid is very small. (This does NOT mean you can fly with 2 planes on the same frequency however. This only means that in this catastrophic scenario paparazzi does a pretty good job in delaying disaster from happening. )<br />
<br />
Be aware that there exist many failsafe switches that use a pulse of the RC (e.g. channel 5) to switch <br />
between autopilot or RC. When using analog RC equipment or any equipment that does not have correctly <br />
programmed failsafe servo values this is very unsafe as whenever the RC is out of range the switch will <br />
start switching back and forth putting the UAV out of control even if the autpilot is perfectly OK.<br />
<br />
<span style="color:#FF0000">'''CAUTION!'''</span> Common receivers today (especially 2.4GHz receivers) has own failsafe mode(s).<br />
Three modes are used in most cases:<br />
<br />
# No failsafe: the receiver will switch off servo sinals in case of RC connection lost.<br/>Paparazzi own failsafe will be activated in case of RC connection lost.<br />
# Last position: the receiver will keep the last valid servo positions in case of RC connection lost.<br/>Paparazzi own failsafe will NOT be activated. (The autopilot will not have information on RC signal lost.)<br />
# Preset servo positions: the receiver will switch servo sinals to a preset value in case of RC connection lost.<br/>This values should be set directly in the receiver. (Read manual.) Paparazzi own failsafe will not be activated.<br/>BUT! If you set the failsafe value of the channel used for Mode control(Manual/Auto1/Auto2) to the value which commands Auto2, then paparazzi will switch automaticaly to Auto2 mode in case of RC connection lost.<br />
<br />
=== FBW logic ===<br />
<br />
* RC GOOD: listen to the MODE switch on the Transmitter<br/>(this means whenever the remote control is close enough the pilot has the final word)<br />
* RC BAD: go to automatic mode (see further on for handling of automatic modes)<br />
* RC BAD AND AUTOPILOT DATA TIMEOUT: failsafe command values from airframe configuration XML<br/>(do not omit to fill in useful failsafe values in the command section; usually slight pitch up for minimal speed, ailerons neutral in order not to roll inverted and of course throttle down: it is not recommended to try to make turns here with aileron deflections. A small rudder deflection on the other hand is recommended when available )<br />
<br />
== AutoPilot (AP) ==<br />
<br />
=== Home mode ===<br />
<br />
The HOME mode is a failsafe mode where the standard navigation (own flightplan) is suspended and the aircraft <br />
flies a circle around the HOME waypoint at a safe altitude (''security_height'' attribute in your flight-plan). This mode is triggered on different events. <br />
Leaving this mode is done by clicking on the red HOME text in the GCS.<br />
<br />
==== Too far from HOME ====<br />
<br />
Home mode is triggered if the distance to the HOME waypoint is greater than a threshold ('''max_dist_from_home''' attribute) set in the <br />
fight-plan (displayed as a circle on the GCS map).<br />
<br />
==== RC link failure while manual or AUTO1 ====<br />
<br />
Home mode is triggered if the RC uplink is lost in '''MANUAL''' or '''AUTO 1''' modes.<br />
<br />
* When '''MANUAL''' the manual mode is restored as soon as the RC link is restored as expected.<br />
* However: In '''AUTO 1''' mode, one must manually leave the HOME mode using the GCS<br />
<br />
! Word of caution with respect to '''AUTO1''': <br />
When flying auto1 with a lot of RC interference (which is not recommended anyway), be prepared that the plane might enter HOME mode.<br />
Also, do not be tempted to fly far away in auto1 mode (possibly out of RC range) without a fully tuned auto2 autopilot or sufficient visual contact to allow manual control. As soon as you are so far that RC packets get lost, paparazzi will switch to HOME and will stay in HOME until you choose MANUAL of re-enable AUTO1 on the GCS !<br />
<br />
===== Setting RC lost mode =====<br />
<br />
By default when RC is lost (in Manual or Auto1) HOME mode is triggered, you can change this behaviour by setting the RC_LOST_MODE:<br />
<br />
<source lang="xml" ><br />
<define name="RC_LOST_MODE" value="PPRZ_MODE_AUTO2"/><br />
</source><br />
<br />
In this example RC_LOST_MODE is set to AUTO2, which can be useful if you experience glitches on your RC on the mode channel and want the aircraft to continue the mission instead of triggering HOME mode. '''BUT''' only use this if you have AUTO2 navigation set up properly and everything is initialized correctly! Another scenario to set this value is if you will fly out of your RC range in a long range mission.<br />
<br />
You can disable HOME mode locking by adding the following line in your airframe file:<br />
<br />
<source lang="xml"><br />
<define name="UNLOCKED_HOME_MODE" value="TRUE"/><br />
</source><br />
<br />
Then you can restore from HOME mode using the RC and do not need to do this on the GCS if in AUTO1.<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Use these two settings with care, as they might deteriorate the failsafe security of your aircraft.<br />
<br />
=== Kill mode ===<br />
<br />
In this mode the throttle is killed (this is the default mode when switching on the autopilot). You can enter this mode manually with the kill button (with confirmation). <br />
Kill mode is also triggered in the following cases:<br />
* Catastrophic battery level<br />
* Way too far from HOME<br />
<br />
<span style="color:#FF0000">'''TODO: '''</span> Complete the list. [MB]<br />
<br />
==== Catastrophic battery level ====<br />
<br />
If the battery level goes under the catastrophic low level (defined in the airframe file):<br />
{{Box Code|myairframefile.xml|<br />
<source lang="xml"><br />
<section name="BAT"><br />
...<br />
<define name="CATASTROPHIC_BAT_LEVEL" value="9.0" unit="V" /><br />
...<br />
</section><br />
</source><br />
}}<br />
<br />
<br />
==== Way too far from HOME ====<br />
<br />
The plane goes into kill mode if it is too far away from the HOME waypoint. You can configure this '''KILL_MODE_DISTANCE''' in your airframe file:<br />
<br />
<source lang="xml"><br />
<section name="MISC"><br />
...<br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
...<br />
</section><br />
</source><br />
<br />
In this example it is set to 1.5 times the '''max_dist_from_home''' (attribute set in your flight plan).<br />
<br />
=== GPS signal lost ===<br />
<br />
In this mode, the autopilot uses the failsafe roll, pitch and throttle settings defined in the airframe file. It is recommended to disable throttle and make a shallow turn at low flight speed. When barometric information is available and compass heading information, it is recommended to disable this safety mode and train the GCS operator to bring the plane home on heading and altitude only. <br />
<br />
Do not mix up the <commands> failsafe_value and the <section name="FAILSAFE" prefix="FAILSAFE_"> default values. The first result in fixed servo positions with the plane totally out of control, while the latter still involve the innerloop to stabilize the plane. <br />
<br />
=== Lost datalink communication (optional) ===<br />
<br />
This can be done via the a flight-plan exception, e.g. go to the Standby block after 30 seconds:<br />
{{Box Code|flightplan.xml|<br />
<source lang="xml"><br />
<header><br />
#include "subsystems/datalink/datalink.h"<br />
</header><br />
...<br />
<exceptions><br />
...<br />
<exception cond="datalink_time > 30" deroute="Standby"/><br />
</exceptions><br />
</source><br />
}}<br />
<br />
<br />
=== Outside mission boundary (optional) ===<br />
<br />
Also use exceptions and/or [[Flight_Plans#Call|function calls]] for this.<br />
<br />
For an example see ''EMAV2009_safety.xml'' in the directory ''conf/flight_plans'' is an example of a safety procedure that can be included in other flight-plans.<br />
It uses two [[Flight_Plans#Sectors|sectors]] defined in ''EMAV2009_data.xml'', a smaller Green "soft boundary" and a hard boundary defined by the Red sector.<br />
<br />
<source lang="xml"><br />
<procedure><br />
<exceptions><br />
<exception cond="Or(! InsideGreen(GetPosX(), GetPosY()), GetPosAlt() > ground_alt + 150)" deroute="Center"/><br />
</exceptions><br />
<br />
<blocks><br />
<block name="Center" pre_call="if (!InsideRed(GetPosX(), GetPosY())) NavKillThrottle();"><br />
<circle wp="_CENTER" radius="DEFAULT_CIRCLE_RADIUS"/><br />
</block><br />
</blocks><br />
</procedure><br />
</source><br />
<br />
The first exception deroutes the plane to the Center block below it, if it is outside the Green [[Flight_Plans#Sectors|sector]] or higher than 150m over ground.<br />
While in the Center block the statement in the pre_call function gets evaluated each time, if the plane is now also outside of the Red sector throttle is killed.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Failsafe&diff=15891Failsafe2013-09-12T21:21:55Z<p>Mbina: Changed the style a bit; added a TODO (a list requieres completion).</p>
<hr />
<div>Paparazzi has several built-in failsafe features ranging from lowlevel to highlevel and from implied to optional.<br />
<br />
On the lowest level, precise timing of the transmitter pulses creates safety that goes beyond traditional switches enabling safer use of old RC equipment.<br />
On the highest level, the [[Flight_Plans#Exceptions|exceptions]] feature of the flight-plans allow for very flexible custom built failsafe features.<br />
<br />
<br />
== FBW (Fly By Wire) ==<br />
<br />
=== 'Failsafe Switch' ===<br />
<br />
The lowest level of paparazzi is the FBW (Fly By Wire) controller that reads the RC, reads the autopilot commands and drives the servos based on the lowlevel failsafe options.<br />
<br />
This is the 'switch' between '''manual''' or '''automatic''' modes. Therefore there is no need for another failsafe board. Indeed, the paparazzi FBW has evolved with so much intelligence that it is certainly safer than some and probably at least as safe as any other failsafe switches. This is amongst others (besides the highlevel validated code, separated process, ...) because paparazzi FBW unlike generic switches is given precise remote control information in its RC.xml. If you use a wrong type of transmitter (e.g. not the right amount of channels, or not the correct interval or sync pulse length) then even when on the same frequency the FBW will not listen to the commands. Also, if 2 transmitters are on the same frequency, then the chance of both signals together still being read as valid is very small. (This does NOT mean you can fly with 2 planes on the same frequency however. This only means that in this catastrophic scenario paparazzi does a pretty good job in delaying disaster from happening. )<br />
<br />
Be aware that there exist many failsafe switches that use a pulse of the RC (e.g. channel 5) to switch <br />
between autopilot or RC. When using analog RC equipment or any equipment that does not have correctly <br />
programmed failsafe servo values this is very unsafe as whenever the RC is out of range the switch will <br />
start switching back and forth putting the UAV out of control even if the autpilot is perfectly OK.<br />
<br />
<span style="color:#FF0000">'''CAUTION!'''</span> Common receivers today (especially 2.4GHz receivers) has own failsafe mode(s).<br />
Three modes are used in most cases:<br />
<br />
# No failsafe: the receiver will switch off servo sinals in case of RC connection lost.<br/>Paparazzi own failsafe will be activated in case of RC connection lost.<br />
# Last position: the receiver will keep the last valid servo positions in case of RC connection lost.<br/>Paparazzi own failsafe will NOT be activated. (The autopilot will not have information on RC signal lost.)<br />
# Preset servo positions: the receiver will switch servo sinals to a preset value in case of RC connection lost.<br/>This values should be set directly in the receiver. (Read manual.) Paparazzi own failsafe will not be activated.<br/>BUT! If you set the failsafe value of the channel used for Mode control(Manual/Auto1/Auto2) to the value which commands Auto2, then paparazzi will switch automaticaly to Auto2 mode in case of RC connection lost.<br />
<br />
=== FBW logic ===<br />
<br />
* RC GOOD: listen to the MODE switch on the Transmitter<br/>(this means whenever the remote control is close enough the pilot has the final word)<br />
* RC BAD: go to automatic mode (see further on for handling of automatic modes)<br />
* RC BAD AND AUTOPILOT DATA TIMEOUT: failsafe command values from airframe configuration XML<br/>(do not omit to fill in useful failsafe values in the command section; usually slight pitch up for minimal speed, ailerons neutral in order not to roll inverted and of course throttle down: it is not recommended to try to make turns here with aileron deflections. A small rudder deflection on the other hand is recommended when available )<br />
<br />
== AutoPilot (AP) ==<br />
<br />
=== Home mode ===<br />
<br />
The HOME mode is a failsafe mode where the standard navigation (own flightplan) is suspended and the aircraft <br />
flies a circle around the HOME waypoint at a safe altitude (''security_height'' attribute in your flight-plan). This mode is triggered on different events. <br />
Leaving this mode is done by clicking on the red HOME text in the GCS.<br />
<br />
==== Too far from HOME ====<br />
<br />
Home mode is triggered if the distance to the HOME waypoint is greater than a threshold ('''max_dist_from_home''' attribute) set in the <br />
fight-plan (displayed as a circle on the GCS map).<br />
<br />
==== RC link failure while manual or AUTO1 ====<br />
<br />
Home mode is triggered if the RC uplink is lost in '''MANUAL''' or '''AUTO 1''' modes.<br />
<br />
* When '''MANUAL''' the manual mode is restored as soon as the RC link is restored as expected.<br />
* However: In '''AUTO 1''' mode, one must manually leave the HOME mode using the GCS<br />
<br />
! Word of caution with respect to '''AUTO1''': <br />
When flying auto1 with a lot of RC interference (which is not recommended anyway), be prepared that the plane might enter HOME mode.<br />
Also, do not be tempted to fly far away in auto1 mode (possibly out of RC range) without a fully tuned auto2 autopilot or sufficient visual contact to allow manual control. As soon as you are so far that RC packets get lost, paparazzi will switch to HOME and will stay in HOME until you choose MANUAL of re-enable AUTO1 on the GCS !<br />
<br />
===== Setting RC lost mode =====<br />
<br />
By default when RC is lost (in Manual or Auto1) HOME mode is triggered, you can change this behaviour by setting the RC_LOST_MODE:<br />
<br />
<source lang="xml" ><br />
<define name="RC_LOST_MODE" value="PPRZ_MODE_AUTO2"/><br />
</source><br />
<br />
In this example RC_LOST_MODE is set to AUTO2, which can be useful if you experience glitches on your RC on the mode channel and want the aircraft to continue the mission instead of triggering HOME mode. '''BUT''' only use this if you have AUTO2 navigation set up properly and everything is initialized correctly! Another scenario to set this value is if you will fly out of your RC range in a long range mission.<br />
<br />
You can disable HOME mode locking by adding the following line in your airframe file:<br />
<br />
<source lang="xml"><br />
<define name="UNLOCKED_HOME_MODE" value="TRUE"/><br />
</source><br />
<br />
Then you can restore from HOME mode using the RC and do not need to do this on the GCS if in AUTO1.<br />
<br />
<span style="color:#FF0000">'''Caution!'''</span> Use these two settings with care, as they might deteriorate the failsafe security of your aircraft.<br />
<br />
=== Kill mode ===<br />
<br />
In this mode the throttle is killed (this is the default mode when switching on the autopilot). You can enter this mode manually with the kill button (with confirmation). <br />
Kill mode is also triggered in the following cases:<br />
* Catastrophic battery level<br />
* Way too far from HOME<br />
<br />
<span style="color:#FF0000">'''TODO: '''</span> Complete the list. [MB]<br />
<br />
==== Catastrophic battery level ====<br />
<br />
If the battery level goes under the catastrophic low level (defined in the airframe file)<br />
<br />
==== Way too far from HOME ====<br />
<br />
The plane goes into kill mode if it is too far away from the HOME waypoint. You can configure this '''KILL_MODE_DISTANCE''' in your airframe file:<br />
<br />
<source lang="xml"><br />
<section name="MISC"><br />
...<br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
...<br />
</section><br />
</source><br />
<br />
In this example it is set to 1.5 times the '''max_dist_from_home''' (attribute set in your flight plan).<br />
<br />
=== GPS signal lost ===<br />
<br />
In this mode, the autopilot uses the failsafe roll, pitch and throttle settings defined in the airframe file. It is recommended to disable throttle and make a shallow turn at low flight speed. When barometric information is available and compass heading information, it is recommended to disable this safety mode and train the GCS operator to bring the plane home on heading and altitude only. <br />
<br />
Do not mix up the <commands> failsafe_value and the <section name="FAILSAFE" prefix="FAILSAFE_"> default values. The first result in fixed servo positions with the plane totally out of control, while the latter still involve the innerloop to stabilize the plane. <br />
<br />
=== Lost datalink communication (optional) ===<br />
<br />
This can be done via the a flight-plan exception, e.g. go to the Standby block after 30 seconds:<br />
{{Box Code|flightplan.xml|<br />
<source lang="xml"><br />
<header><br />
#include "subsystems/datalink/datalink.h"<br />
</header><br />
...<br />
<exceptions><br />
...<br />
<exception cond="datalink_time > 30" deroute="Standby"/><br />
</exceptions><br />
</source><br />
}}<br />
<br />
=== Outside mission boundary (optional) ===<br />
<br />
Also use exceptions and/or [[Flight_Plans#Call|function calls]] for this.<br />
<br />
For an example see ''EMAV2009_safety.xml'' in the directory ''conf/flight_plans'' is an example of a safety procedure that can be included in other flight-plans.<br />
It uses two [[Flight_Plans#Sectors|sectors]] defined in ''EMAV2009_data.xml'', a smaller Green "soft boundary" and a hard boundary defined by the Red sector.<br />
<br />
<source lang="xml"><br />
<procedure><br />
<exceptions><br />
<exception cond="Or(! InsideGreen(GetPosX(), GetPosY()), GetPosAlt() > ground_alt + 150)" deroute="Center"/><br />
</exceptions><br />
<br />
<blocks><br />
<block name="Center" pre_call="if (!InsideRed(GetPosX(), GetPosY())) NavKillThrottle();"><br />
<circle wp="_CENTER" radius="DEFAULT_CIRCLE_RADIUS"/><br />
</block><br />
</blocks><br />
</procedure><br />
</source><br />
<br />
The first exception deroutes the plane to the Center block below it, if it is outside the Green [[Flight_Plans#Sectors|sector]] or higher than 150m over ground.<br />
While in the Center block the statement in the pre_call function gets evaluated each time, if the plane is now also outside of the Red sector throttle is killed.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbinahttp://wiki.paparazziuav.org/w/index.php?title=Failsafe&diff=15890Failsafe2013-09-12T21:16:15Z<p>Mbina: </p>
<hr />
<div>Paparazzi has several built-in failsafe features ranging from lowlevel to highlevel and from implied to optional.<br />
<br />
On the lowest level, precise timing of the transmitter pulses creates safety that goes beyond traditional switches enabling safer use of old RC equipment.<br />
On the highest level, the [[Flight_Plans#Exceptions|exceptions]] feature of the flight-plans allow for very flexible custom built failsafe features.<br />
<br />
<br />
== FBW (Fly By Wire) ==<br />
<br />
=== 'Failsafe Switch' ===<br />
<br />
The lowest level of paparazzi is the FBW (Fly By Wire) controller that reads the RC, reads the autopilot commands and drives the servos based on the lowlevel failsafe options.<br />
<br />
This is the 'switch' between '''manual''' or '''automatic''' modes. Therefore there is no need for another failsafe board. Indeed, the paparazzi FBW has evolved with so much intelligence that it is certainly safer than some and probably at least as safe as any other failsafe switches. This is amongst others (besides the highlevel validated code, separated process, ...) because paparazzi FBW unlike generic switches is given precise remote control information in its RC.xml. If you use a wrong type of transmitter (e.g. not the right amount of channels, or not the correct interval or sync pulse length) then even when on the same frequency the FBW will not listen to the commands. Also, if 2 transmitters are on the same frequency, then the chance of both signals together still being read as valid is very small. (This does NOT mean you can fly with 2 planes on the same frequency however. This only means that in this catastrophic scenario paparazzi does a pretty good job in delaying disaster from happening. )<br />
<br />
Be aware that there exist many failsafe switches that use a pulse of the RC (e.g. channel 5) to switch <br />
between autopilot or RC. When using analog RC equipment or any equipment that does not have correctly <br />
programmed failsafe servo values this is very unsafe as whenever the RC is out of range the switch will <br />
start switching back and forth putting the UAV out of control even if the autpilot is perfectly OK.<br />
<br />
<span style="color:#FF0000">'''CAUTION!'''</span> Common receivers today (especially 2.4GHz receivers) has own failsafe mode(s).<br />
Three modes are used in most cases:<br />
<br />
# No failsafe: the receiver will switch off servo sinals in case of RC connection lost.<br/>Paparazzi own failsafe will be activated in case of RC connection lost.<br />
# Last position: the receiver will keep the last valid servo positions in case of RC connection lost.<br/>Paparazzi own failsafe will NOT be activated. (The autopilot will not have information on RC signal lost.)<br />
# Preset servo positions: the receiver will switch servo sinals to a preset value in case of RC connection lost.<br/>This values should be set directly in the receiver. (Read manual.) Paparazzi own failsafe will not be activated.<br/>BUT! If you set the failsafe value of the channel used for Mode control(Manual/Auto1/Auto2) to the value which commands Auto2, then paparazzi will switch automaticaly to Auto2 mode in case of RC connection lost.<br />
<br />
=== FBW logic ===<br />
<br />
* RC GOOD: listen to the MODE switch on the Transmitter<br/>(this means whenever the remote control is close enough the pilot has the final word)<br />
* RC BAD: go to automatic mode (see further on for handling of automatic modes)<br />
* RC BAD AND AUTOPILOT DATA TIMEOUT: failsafe command values from airframe configuration XML<br/>(do not omit to fill in useful failsafe values in the command section; usually slight pitch up for minimal speed, ailerons neutral in order not to roll inverted and of course throttle down: it is not recommended to try to make turns here with aileron deflections. A small rudder deflection on the other hand is recommended when available )<br />
<br />
== AP (AutoPilot) ==<br />
<br />
=== Home mode ===<br />
<br />
The HOME mode is a failsafe mode where the standard navigation (own flightplan) is suspended and the aircraft <br />
flies a circle around the HOME waypoint at a safe altitude (''security_height'' attribute in your flight-plan). This mode is triggered on different events. <br />
Leaving this mode is done by clicking on the red HOME text in the GCS.<br />
<br />
==== Too far from HOME ====<br />
<br />
Home mode is triggered if the distance to the HOME waypoint is greater than a threshold ('''max_dist_from_home''' attribute) set in the <br />
fight-plan (displayed as a circle on the GCS map).<br />
<br />
==== RC link failure while manual or AUTO1 ====<br />
<br />
Home mode is triggered if RC uplink is lost in '''MANUAL''' or '''AUTO 1''' modes.<br />
<br />
* When '''MANUAL''' the manual mode is restored as soon as RC link is restored as expected.<br />
* However: In '''AUTO 1''' mode, one must manually leave the HOME mode using the GCS<br />
<br />
! Word of caution with respect to '''AUTO1''': <br />
When flying auto1 with a lot of RC interference (which is not recommended anyway), be prepared that the plane might enter HOME mode.<br />
Also, do not be tempted to fly far away in auto1 mode (possibly out of RC range) without a fully tuned auto2 autopilot or sufficient visual contact to allow manual control. As soon as you are so far that RC packets get lost, paparazzi will switch to HOME and will stay in HOME until you choose MANUAL of re-enable AUTO1 on the GCS !<br />
<br />
===== Setting RC lost mode =====<br />
<br />
By default when RC is lost (in Manual or Auto1) HOME mode is triggered, you can change this behaviour by setting the RC_LOST_MODE:<br />
<br />
<source lang="xml" ><br />
<define name="RC_LOST_MODE" value="PPRZ_MODE_AUTO2"/><br />
</source><br />
<br />
In this example RC_LOST_MODE is set to AUTO2, which can be useful if you experience glitches on your RC on the mode channel and want the aircraft to continue the mission instead of triggering HOME mode. '''BUT''' only use this if you have AUTO2 navigation set up properly and everything is initialized correctly! Another scenario to set this value is if you will fly out of your RC range in a long range mission.<br />
<br />
You can disable HOME mode locking by adding the following line in your airframe file:<br />
<br />
<source lang="xml"><br />
<define name="UNLOCKED_HOME_MODE" value="TRUE"/><br />
</source><br />
<br />
Then you can restore from HOME mode using the RC and do not need to do this on the GCS if in AUTO1.<br />
<br />
'''Caution:''' Use these two settings with care, as they might deteriorate the failsafe security of your aircraft.<br />
<br />
=== Kill mode ===<br />
<br />
In this mode the throttle is killed (this is the default mode when switching on the autopilot). You can enter this mode manually with the kill button (with confirmation). Kill mode is also triggered in the following cases:<br />
<br />
==== Catastrophic battery level ====<br />
<br />
If the battery level goes under the catastrophic low level (defined in the airframe file)<br />
<br />
==== Way too far from HOME ====<br />
<br />
The plane goes into kill mode if it is too far away from the HOME waypoint. You can configure this '''KILL_MODE_DISTANCE''' in your airframe file:<br />
<br />
<source lang="xml"><br />
<section name="MISC"><br />
...<br />
<define name="KILL_MODE_DISTANCE" value="(1.5*MAX_DIST_FROM_HOME)"/><br />
...<br />
</section><br />
</source><br />
<br />
In this example it is set to 1.5 times the '''max_dist_from_home''' (attribute set in your flight plan).<br />
<br />
=== GPS signal lost ===<br />
<br />
In this mode, the autopilot uses the failsafe roll, pitch and throttle settings defined in the airframe file. It is recommended to disable throttle and make a shallow turn at low flight speed. When barometric information is available and compass heading information, it is recommended to disable this safety mode and train the GCS operator to bring the plane home on heading and altitude only. <br />
<br />
Do not mix up the <commands> failsafe_value and the <section name="FAILSAFE" prefix="FAILSAFE_"> default values. The first result in fixed servo positions with the plane totally out of control, while the latter still involve the innerloop to stabilize the plane. <br />
<br />
=== Lost datalink communication (optional) ===<br />
<br />
This can be done via the a flight-plan exception, e.g. go to the Standby block after 30 seconds:<br />
{{Box Code|flightplan.xml|<br />
<source lang="xml"><br />
<header><br />
#include "subsystems/datalink/datalink.h"<br />
</header><br />
...<br />
<exceptions><br />
...<br />
<exception cond="datalink_time > 30" deroute="Standby"/><br />
</exceptions><br />
</source><br />
}}<br />
<br />
=== Outside mission boundary (optional) ===<br />
<br />
Also use exceptions and/or [[Flight_Plans#Call|function calls]] for this.<br />
<br />
For an example see ''EMAV2009_safety.xml'' in the directory ''conf/flight_plans'' is an example of a safety procedure that can be included in other flight-plans.<br />
It uses two [[Flight_Plans#Sectors|sectors]] defined in ''EMAV2009_data.xml'', a smaller Green "soft boundary" and a hard boundary defined by the Red sector.<br />
<br />
<source lang="xml"><br />
<procedure><br />
<exceptions><br />
<exception cond="Or(! InsideGreen(GetPosX(), GetPosY()), GetPosAlt() > ground_alt + 150)" deroute="Center"/><br />
</exceptions><br />
<br />
<blocks><br />
<block name="Center" pre_call="if (!InsideRed(GetPosX(), GetPosY())) NavKillThrottle();"><br />
<circle wp="_CENTER" radius="DEFAULT_CIRCLE_RADIUS"/><br />
</block><br />
</blocks><br />
</procedure><br />
</source><br />
<br />
The first exception deroutes the plane to the Center block below it, if it is outside the Green [[Flight_Plans#Sectors|sector]] or higher than 150m over ground.<br />
While in the Center block the statement in the pre_call function gets evaluated each time, if the plane is now also outside of the Red sector throttle is killed.<br />
<br />
[[Category:Software]] [[Category:User_Documentation]]</div>Mbina