FLEXIBLE TELEMETRY PARAMETERS MANAGEMENT SYSTEM FOR RESEARCH AND DEVELOPMENT OF UNMANNED PLATFORMS
Ivan V. Makarov
Approach for automatic onboard arrangement of telemetry data by its formal description is presented. Author’s realization of approach for unmanned aerial vehicle is explained. Explanation touches aspects of monitoring of parameters for external onboard devices. Telemetry decomposition for ground control software is described in a way of reducing development time and product complexity.
One of the questions in research and development process of unmanned complex platforms is the way of experimental data management for telemetry packets or for recording on non-volatile on-board memory (NVM). Obvious way to arrange data is direct software coding of procedures to get specified structure of data and copy it to defined place (file system, data link port).
The first problem begins when number of structures of interest is increasing as system becomes more complex. Every structure has to be documented for next decoding after receiving or for binary file converting.
The second problem arises when developers from time to time change some structures, what leads to documents correction and then to ground software changing.
The third problem appears when for optimizing of using data link bandwidth or NVM space developer want to deliver some structure’s parameters and leave the others. In direct software coding developer has to do this manually every time the final structure of interest is changed.
This paper represents approach for automatic data arrangement onboard and following automatic decoding on ground using formal decryption of all onboard parameters and description of target structure.
Key information of necessary system’s parameters is stored in System Parameters Description (SPD) file. (fig. 1) Description of every parameter should have at least following information:
- Identification value, ID signature (name by text or number)
- Access data (ex. address + offset);
- Value representation way (endianness, variable type).
Final structure of target frame is described by Final Frame Description (FFD) file. FFD is list of references to parameters of interest and the way of theirs final representation.
Fig. 1.System parameters description and final frame descriptions representation in a dedication for different destinations
When target system works in common address space the simplest way to access parameters of structure of interest is provide theirs physical address during runtime (fig. 2). This approach guarantees coincidence of addresses of parameters to theirs ID signatures by compiler.
Fig. 2. Approach to form SPD information by user code in runtime
Another case of realization is when target system is based on operating system (OS) with memory management. So, parameters request task (process) is not able to get value of any parameter from separate process address space and developer has to use inter-process communication (IPC) mechanisms. In this case SPD file should have connectivity information to establish access to specified parameters.
Author deals with QNX Neutrino RTOS for unmanned aerial vehicle project (take-off mass 6kg). Functionality of system separated on processes for each primary task: navigation, control, communication, external devices access driver (fig. 3). Interfaces to these processes arranged as resource managers  (files in /dev/* path). Requesttoprocessisperformedbydevctl() POSIX subroutine.
Fig. 3. Flow chart of system processes request of specified FFD elements. In this instance FFD contains parameters from each system process
Each of the processes is programmed to return most of its important parameters, for instance navigation process able to give not only final solution, but raw data from sensors, information from GNSS receiver, diagnostics data. Automatic control process presents: control loop integrity information, final control solution data, control mode. Giving that information out of the process initially programmed for debugging purposes and on ground diagnostics. Access to each type of process data are provided by devctl() call with 1 byte command code as second argument and buffer and its size as third and fourth accordingly. Therefore in OS-based solution every parameter is got within structure, so user has to get all structure and then extract parameter of interest. To automate this process SPD file must provide information about elements of structure.
Author realization of SPD file is based on the Extensible Markup Language (XML) . System data are divided into groups e.g.: navigational, control, communication, external devices. Group reference is number and name. Each group contains structure description, called frame. Frame also has ID information (number and name). It describes access to data by following parameters:
- Recourse manager path (e.g. /dev/nav);
- Access type (e.g. “devctl”);
- Request code (e.g. 0x10);
Then each parameter of the frame called variable is presented with next information:
- Nameand ID number;
- Variable type (in terms of C language);
- Optional scale factor and bias value for conversion of requested parameter.
By using XML, configuration files become self documented.
Presented instance of realization provides converting to binary or text representation of parameters of interest. System has sufficient amount of NVM so all on-flight on-board logging is performed in text format. This way allows to process data directly into most of spreadsheet applications (like MS Excel) without of using additional data converters. This approach helps to optimize workflow when flight tests are performed intensively. And user doesn’t need to know format, its human readable as it produced by system.
FFD file for binary representation specifies set of parameters of interest with next information:
- Reference to parameter by group name, frame name, variable name;
- Scale factor and bias value;
- Format of parameter at target structure (float, double int32_t, uint32_t, etc.).
Providing means to convert values helps to optimize amount of data to be transmitted when, for instance, initial variable is float, but user needs to know just one digit after radix and its integral part varies between -6500 and 6500. So scale factor in this case is 10.
Described approach in author realization allows gathering of data from external devices also. System provides special external devices driver (EDD). This driver reflects prescience of external devices on RS485 bus by putting their names in operating system’s file manager (fig. 4).
Fig. 4. Flow chart of external devices access structure
Therefore access to external devices is performing the same way as to local processes. Interaction with particular device is hidden within EDD. Overhead of using RS485 bus is avoided by caching responses for specified request codes for specified devices. Period of expiration is also specified, so the real frequency of frame request became fixed and predictable, even for several request processes of one device.
In presented implementation instance most of parameters management functionality is packed to library and currently used by two modules: telemetry sending and NVM text logger.
For better compatibility, receiver of packed binary information recognizes its format by reading same FFD file (fig. 5). It allows excluding of any decoding programming within ground software. One of the ways to realize that is using hash table like “map” in C++ STL or “dictionary” in C#.
Fig. 5. Flow chart of telemetry decomposition by same FFD description as onboard version
The only task is left for developer is to use extracted by its name parameter. All scale conversions are provided automatically by receiver decoding level.
Presented approach for telemetry parameters management allows to rapidly extend system or switch focus from one test aspect to another by several simple settings, what leads to reducing load on developers during field (flight) test preparations, keeping system software runtime overhead low.
 R. Krten, Writing a Resource Manager, QSSL http://www.qnx.com/download/download/19523/resource_managers.pdf