Integrated Debugging Tools

Script output folder

TODO

Crash Checker

Most scripts started by the LCC run in tmux sessions (which is similar to screen). These sessions have distinct names, depending on the program.

Sessions exist for the middleware and your script (if a simulation was started and they are running locally). There also exist sessions for the lab cam, position detection and other vital features of the LCC (if they are activated).

The integrated crash checker checks regularly - during a simulation - if all these tools are still running. To simplify the process, we only look up if the according tmux sessions still exist, which in most cases is enough to detect a crash of the contained program.

In case of an error, a LCC log entry is created and an additional popup window (which needs to be closed manually) warns the user about the undesired behaviour.

Local Deployment

If you deploy your script locally, the process described above can be used to check if your script and the middleware are still running.

Remote Deployment

Take a look at this page.

Round Trip Time Measurements

DDS Datatype

The following datatype is used to measure the RTT:

struct RoundTripTime {
    string source_id; //To find out where the msg came from and to not answer to own msg

    boolean is_answer; //If true, do not respond to this msg, as it already is an answer to an RTT request
    octet count; //Counter to not mix up old with new RTT requests
};

Implementation

The implementation of the calculation of the RTT as well as answering / sending RTT requests is part of the cpm library. They can be activated using the activate function, e.g. for the HLC:

cpm::RTTTool::Instance().activate("hlc");

Here, hlc implies that this participant is responsible for measurements regarding the HLC, and answers to HLC RTT requests. You do not need to take care of this - HLC measurements are part of the autostart program on the NUCs.

The LCC includes some more tools to aggregate the calculated RTTs and to display them in the UI.

Functionality

The LCC regularly sends RTT measurement requests as long as no simulation is running (to prevent network overload). 

These messages are received by different participants, which can send an answer to this request. It consists of their source_id (e.g. vehicle or hlc), and additional information to make sure that the answer is up-to-date etc.

The LCC either waits for these messages until a timeout occurs, or waits for some additional time after receiving the first message to determine when - approximately - the latest answers arrive.

These messages - for HLC and vehicles - are then processed to show the user the current best and worst RTT measured for each of the two participant types, the percentage of requests with missing replies since the start of the RTT measurement (since the last simulation) and the all-time worst RTT.

If no replies were received for some time (about 10 seconds), then all participants of that type are assumed to be turned off. The according data structures are reset and the UI does not show any information regarding the RTT of the participants anymore.

UI

Picture of the LCC monitoring bar including information about the RTT, when no measurements could be made (because the participants are offline).

Experiment Runtime

A small indicator has been added that shows the user how long the experiment has been running. It is also part of the monitoring bar. It displays hours, minutes and seconds (if they are greater than zero).