Skip to content

Application for handling diagnostic messages from the RTOS boards, from yarprobotinterface and any other UDP source.

Notifications You must be signed in to change notification settings

robotology/diagnostic-daemon

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

1. DiagnosticDaemon (DD)

1.1. Introduction

The DiagnosticDaemon (DD) application has been developed to get diagnostic messages from the RTOS boards, from yarprobotinterface and any other UDP source. DiagnosticDaemon redirects the message to other applications or writes the messages to file or console. DD works with a list of preloadable components.

Deploy diagram

1.2. Installation from source on Linux system

Prerequisite:

sudo apt-get install build-essential g++ cmake libboost-system-dev

Clone the DiagnosticDaemon repository:

git clone https://github.com/icub-tech-iit/diagnostic-daemon.git

Clone the icub-firmware-shared repository

git clone https://github.com/icub-tech-iit/icub-firmware-shared.git

Compile the icub-firmware-shared:

cd icub-firmware-shared
mkdir build
cd build
cmake ..
make

Compile:

cd diagnostic-daemon
mkdir build
cd build
cmake ..
make

1.2.1. YarpLogger ready

If you also need the YarpLogger connection make sure to select in ccmake the following:

COMPILE_WITHYARP_DEF                 ON                                                     

In this case, Yarp should be compiled and installed.
See https://github.com/robotology/yarp

1.3. Execution

To execute the application:

cd diagnostic-daemon/build/bin
./diagnosticdaemon

1.4. Default configuration

The DiagnosticDaemon has a configuration file in xml called config.xml. The file must be located in the same folder as the diagnosticdaemon executable file.
Here is the default file:

<configuration>
    <component type="udp"            name="boards"     rxport="11000" txport="11000" address="10.0.1.1"   mask="255.255.255.0" mode="copy-raw"    rules="x:10.0.1.4 i:10.0.1.1" enable="true"  value="" destination="dec gui1 file1"/>  
    <component type="udp"            name="configrx"   rxport="11001" txport="11001" address="127.0.0.1"  mask=""              mode="copy-raw"    rules="" enable="true"  value="" destination="config"/>  
    <component type="udp"            name="gui1"       rxport="8000"  txport="9000"  address="127.0.0.1"  mask=""              mode="copy-raw"    rules="" enable="true"  value="" destination="boards"/>
    <component type="file"           name="file1"      rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="logger1.log" destination=""/>
    <component type="file"           name="file2"      rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="logger2.log" destination=""/>
    <component type="console"        name="console"    rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="" destination=""/>
    <component type="decoder"        name="dec"        rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="" destination="file2 console yarp"/>
    <component type="yarplogger"     name="yarp"       rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="" destination=""/>
    <component type="config"         name="config"     rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="" destination=""/>
</configuration>

At the start, the DiagnosticDaemon reads the file and create as many components as described in the config.xml file.
In this case the following UML diagram describe the created objects:

UML Object diagram



The message flow through the instantiated components (follow step0...3):

UML msg diagram In the figure the message flow from RTOS and yarprobotinterface to the file/console/gui.

1.4.1. Examples

DD follows various flows.
Example #1:

  • Component #1 receives a UDP message
  • Component #1 route the message to component #2
  • Component #2 send the message to an external application

Example #2:

  • Component #1 receives a UDP message
  • Component #1 route the message to component #2
  • Component #2 write message to file

1.4.2. Available components

The following components are available.

upd or UDP-broadcast: send and receive data on UDP connection.
console: write data on console and accept keyboard input.
file: write data on file.
decoder: decode message from byte format to string.
yarplogger: send received message to yarplogger.
config: change configuration as it receives a configuration message.
synch: create a synch time message to be sent to boards.

1.5. Tags meaning

An example component in the config.xml:

    <component type="udp"            name="boards"     rxport="11000" txport="11000" address="10.0.1.1"   mask="255.255.255.0" mode="copy-raw"    rules="x:10.0.1.4 i:10.0.1.1" enable="true"  value="" destination="dec gui1 file1"/>  

The component tag has the following attributes:

parameter name parameter type parameter value component note
protocol enum udp/file/console/yarplogger/config/decoder component type
name string all component name
rxport number udp rx ip port
txport number udp tx ip port
address ipaddress udp ip destination address
mask ipaddress
mode enum decode/raw console copy the messages to destination with no modifications
rules string x:1.1.1.1 i:1.1.1.1 x:all i:none udp excluded messages from this addresses
enable boolean true/false all enable or disable the component
value string file various uses, for file the file name
destination string udp messages destination, here the receiver component name
synchtime integer synch timeout for sending synch message in msec

1.6. Use with YarpLogger

DiagnosticDaemon can forward data to YarpLogger. To enable this feature use the component yarplogger.
Example:

<configuration>
    <component type="udp"            name="boards"     rxport="11000" txport="11000" address="10.0.1.1"   mask="255.255.255.0" mode="copy-raw"    rules="x:10.0.1.4 i:10.0.1.1" enable="true"  value="" destination="dec"/>  
    <component type="decoder"        name="dec"        rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="" destination="yarp"/>
    <component type="yarplogger"     name="yarp"       rxport=""      txport=""      address=""           mask=""              mode="copy-parser" rules="" enable="true"  value="" destination=""/>

In this example three components are working: The component with name 'boards' receive messages from UDP, then it sends the messages to the component 'dec' and at the end the component 'dec' send the messages to the component 'yarp'. The component 'yarp' send the messages to the yarplogger.
Note that the component named 'dec' decode the bytes messages to string format messages.

Also before executing DiagnosticDaemon use in the same shell or your .bashrc:

export YARP_FORWARD_LOG_ENABLE=1
export YARP_DEBUG_ENABLE=1

Also, the DiagnosticDaemon should be compiled with Yarp, see section YarpLogger ready

1.7. Application structure

In figure the application class diagram.

UML class diagram

1.8. Configuration messages

1.9. Use

All the configuration messages should be sent to port UDP component connected to a config component.
In default config.xml the port for configuration is 11001.

1.10. Message list

message name use note
filtermanageset It can be used for filters setting none

1.10.1. filtermessageset

This message is used to set the filters in DiagnosticDaemon.

parameter name description values default
name message name string with message name empty
destinationaddress Destination address to which the filter is anctivated dotted string:port empty
type Type of filter address address
rules Rules of exclusion (x:address) and inclusion (i:address) Special addresses are none and all x:none i:all
propagatetoboard The rules can be propagated to the boards ture or false false
persistence The rules will be saved in the DiagnosticDaemon configuration file true or false false

Example:

<message name="filtermessageset" type="address" destinationaddress="10.0.1.1 9000" rules="x:10.0.1.4 x:10.0.1.5 i:10.0.1.6" propagatetoboard="false" persistence="false"/>

1.11. Time sync

DD can be used to perform time synch between the RTOS board and the machine on which DD is currently working.

1.11.1. Configuration

To perform the requested task you need to add the "synch" component to the config.xml files. Together with the synch component, you will need a UDP component to send the message on the desired port.

 <component type="udp" name="synchboard" rxport="11002" txport="11000" address="10.0.1.255" mask="255.255.255.0" mode="copy-raw" rules="" enable="true" value="" broadcast="true" destination=""/>  
    <component type="synch" name="synchtime"  rxport="" txport="" address="" mask="" mode="copy-parser" rules="" enable="true"  value="" destination="synchboard" synchtime="2000"/> 

Note that the synch message will be sent every 2000msec (synchtime="2000") to the broadcast udp address with port 11000 (txport="11000"). Add the above lines anywhere in the config.xml file.

1.12. Changing the sent message

If you need to change the sent message refer to folder msgready in the execution folder. Choose the roptime.xml file. In the file is described the sent message. Changing the file will result in a change the sending message.

1.13. Advanced

1.13.1. Application log

On the screen, a consol log is always present. The application log can be written to file by adding, to the execution folder, an empty file called pleaselogtofile. In this case, it will appear a log.log file with the logs inside.

πŸ‘¨πŸ»β€πŸ’» Maintainers

This repository is maintained by:

@triccyx