Telemetry

Messages

The set of periodic messages sent over the downlink channel by an aircraft to the ground station is configurable with the help of one XML file, located in the conf/telemetry directory. This file is called by conf/conf.xml and must follow the telemetry.dtd syntax. The default.xml 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 )

<!DOCTYPE telemetry SYSTEM "telemetry.dtd">
<telemetry>
 <process name="Ap">
   <mode name="default">
    <message name="ATTITUDE" period="0.5"/>
    <message name="PPRZ_MODE" period="5"/>
    <message name="SOME_MODULE_MSG" period="2" module="module_name"/>
    ...
   </mode>
   <mode name="fast attitude">
     <message name="ATTITUDE" period="0.1"/>
   </mode>
</process>
 <process name="Fbw">
   <mode name="default">
     <message name="COMMANDS" period="1"/>
     ...
   </mode>
   <mode name="debug">
     <message name="PPM" period="0.5"/>
   </mode>
 </process>
</telemetry>

If a module attribute is specified for a message, it will be include in the telemetry only if the corresponding module is loaded.

Add Messages

When you want to add a new senor to Paparazzi and need the sensor data on the ground station do this: in this example we will add an airspeed message.

in conf/messages.xml add an airspeed messages

  <message name="AIRSPEED" id="54">
   <field name="adc_airspeed" type="uint16"></field>
   <field name="estimator_airspeed" type="float"></field>
   <field name="airspeed_setpoint" type="float"></field>
   <field name="airspeed_controlled" type="float"></field>
   <field name="groundspeed_setpoint" type="float"></field>
 </message>

id="54" has to be unique. ( in the console type in your paparazzi map ./sw/tools/find_free_msg_id.out to find a free ID. your Paparazzi source and home environment variables have to be set correctly in your shell [1]) every field is a variable from Paparazzi. The type have to be the type of the variable. (look it op in your code)

now a DOWNLINK_SEND_AIRSPEED is made by the code

in conf/telemetry/default.xml add your message an tel at with frequency it has to be send.

<telemetry>
  <process name="Ap">
   <mode name="default">
     <message name="ALIVE"          period="5"/>
     <message name="GPS"            period="0.25"/>
     <message name="AIRSPEED"       period="1"/>
     ....

now a PERIODIC_SEND_AIRSPEED is made by the code

In ap_downlink.h add :

#ifdef USE_AIRSPEED
#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)
#else
#define PERIODIC_SEND_AIRSPEED(_chan) {}
#endif

here you tell to replace all PERIODIC_SEND_AIRSPEED by DOWNLINK_SEND_AIRSPEED

Specific Messages

GPS_SOL

Specification in telemetry file

<message name="GPS_SOL"        period="2.0"/>

Example from logfile(.data):

6.742 1 GPS_SOL 232 43 198 8

Meaning of tokens:

Timestamp, Aircraft-Number, GPS_SOL, Pacc, Sacc, PDOP, numSV

• Pacc = Position accuracy (units: CM)
• Sacc = Speed accuracy (units: CM/sec ?)
• PDOP = Position Dilution of Precision
• numSV = number of Space Vehicles (Satellites) used in Nav Solution

PPRZ_MODE

Specification in telemetry file

<message name="PPRZ_MODE"      period="5."/>

Example from logfile(.data):

20.433 2 PPRZ_MODE 0 1 2 0 0 1

Meaning of tokens:

Timestamp, Aircraft-Number, PPRZ_MODE, ap_mode, ap_gaz, ap_horizontal, if_calib_mode, mcul_status

• ap_mode = (0 = MANUAL, 1 = AUTO1, 2 = AUTO2, 3 = HOME mode (Circle Home waypoint), 4 = NO_GPS (GPS not working), 5 = NB (?)
• ap_gaz = ?
• ap_horizontal = ?
• if_calib_mode = ?
• mcul_status = ?

Configuring the Downlink Data Rate

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:

• Tailor the data rate to work with very slow modems (9600 baud or slower)
• Reduce the data rate of some messages so that others can be increased:

  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.

  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.

  Manually send selected sensor data at very high speeds (60Hz) for real time tuning.

• Maintain independent telemetry configurations for aircraft with different modems, sensors, or mission profiles.

Any number of configuration files can be created in the conf/telemetry directory and selected from the conf/conf.xml file. The telemetry downlink is divided into two processes, Ap and Fbw each with a possible mode 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.

The mode can be chosen in the airframe file by setting the TELEMETRY_MODE_FBW constant:

<define name="TELEMETRY_MODE_FBW" value="1"/>

where the (default) first mode is numbered 0.

This mode can also be changed dynamically with a datalink setting or with a set stage in the flight plan.

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.

Settings

The settings attribute in the description of the aircraft in conf.xml allows the user to specify a list of variables for which values can be changed in-flight:

<aircraft 
 name="Microjet"
 ...
 settings="settings/basic.xml"
 ...
/>

with the basic.xml file located in conf/settings/. A dl_setting element in this file associates buttons or sliders in the GCS interface to autopilot variables:

<!DOCTYPE settings SYSTEM "settings.dtd">
<settings>
 <dl_settings>
   <dl_settings NAME="flight params">
     <dl_setting MAX="1000" MIN="-50" STEP="10" VAR="altitude_shift"/>
   </dl_settings>
   <dl_settings NAME="mode">
     <dl_setting MAX="2" MIN="0" STEP="1" VAR="pprz_mode">
       <strip_button name="AUTO2" value="2"/>
     </dl_setting>
     <dl_setting MAX="1" MIN="0" STEP="1" VAR="launch">
       <strip_button name="Launch" value="1"/>
     </dl_setting>
     <dl_setting MAX="1" MIN="0" STEP="1" VAR="kill_throttle"/>
   </dl_settings>
 </dl_settings>
</settings>

where dl_settings elements can be nested at any depth. A dl_setting element just specifies the name of the variable, the allowed range for the setting (min and max attributes) and the minimal step.

A notebook page will be associated in the GUI to each dl_settings element. A slider will be associated to each dl_setting 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.

The strip_button element adds a button to the 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 group is specified, all strip buttons of the same group will be placed vertically on top of each other.

The param attribute of a dl_setting element allows to specify the corresponding parameter in the airframe file in order to save a tuned value:

<dl_setting max="0.3" min="-0.3" step="0.01" var="ir_roll_neutral" param="IR_ROLL_NEUTRAL_DEFAULT" unit="rad"/>

where the unit 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).

R/C Transmitter Data Uplink

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

Use these up/down buttons for realtime tuning

The tuning_rc.xml file is located in conf/settings.

<aircraft 
 name="Microjet"
 ...
 settings="settings/tuning_rc.xml"
 ...
/>

A rc_settings element in this file associates switches and sliders of the RC to airborne variables:

<!DOCTYPE settings SYSTEM "settings.dtd">
<settings>
 <rc_settings>
   <rc_mode NAME="AUTO1">
     <rc_setting VAR="ir_pitch_neutral" RANGE="2" RC="gain_1_up" TYPE="float"/>
     <rc_setting VAR="ir_roll_neutral" RANGE="-2" RC="gain_1_down" TYPE="float"/>
   </rc_mode>
   <rc_mode NAME="AUTO2">
     <rc_setting VAR="course_pgain" RANGE="0.1" RC="gain_1_up" TYPE="float"/>
     <rc_setting VAR="pitch_of_roll" RANGE=".2" RC="gain_1_down" TYPE="float"/>
   </rc_mode>
 </rc_settings>
</settings>

First, settings are sorted by mode (AUTO1 or AUTO2). Then a setting is composed of a variable name, a range (corresponding to the range of the RC slider) and a RC name. The RC name prefix can be gain_1 or gain_2, which corresponds to the GAIN1 and GAIN2 channels of your RC transmitter configuration. The RC name suffix can be up or down, which is related to the position of the CALIB switch on the RC transmitter.

Audio-based downlink

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.