The Lab Control Center (LCC) is a GUI tool that allows monitoring and control for various aspects of the lab. It has two main purposes,

1. to start and stop an experiment, and
2. to visualize the current state of the experiment.

Start the LCC from the start menu. It should look somewhat like this:

After starting a simulation, it should look like this:

Vehicle Monitoring

On the bottom, you see variables related to the vehicles (vehicle state data and the IPS poses) that are exchanged via DDS. Values are color coded green, yellow or red according to expected values. This makes is possible to quickly check if all vehicles are operating normally.

Map View

The map on the upper left view depicts the vehicle's positions and orientations, a "trail" of past positions (red), the commanded reference trajectory (blue), and the MPC's predicted trajectory (pink).

A vehicle can be controlled in a semi-automated fashion, by clicking and dragging to draw a reference trajectory. This only works when the vehicle is within the view of the IPS.

Tabs

The tabs in the upper right fulfill multiple purposes, which are explained in the following sections.

Setup (WIP)

The setup view allows to launch all components required to perform a simulation from within the LCC's GUI. It can also be used for real vehicles, and to deploy your selected program or script remotely on the NUCs (HLCs).

Selecting a Script

A single script can be selected by editing the path text field or selecting a file using the Open button. In the file chooser, you can select whether you want to use an executable or a Matlab script in a drop down menu at the bottom right of the window.

Required Script Properties

Your script should take the following arguments:

Most of the required C++ parameters are used to set values for the cpm library. Of these parameters, you are probably only interested in the list of vehicle IDs your program is responsible for (--vehicle-ids). The same is true for the matlab script, where varargin gives you a list of vehicle IDs - any other parameters, which come beforehand, are custom.

Further parameters can be specified in the text field below the Open button. If you need to access these command line parameters in your C++ program, simply use the Command Line Parser and --your_param= in the text field. Custom arguments can be set by yourself this way during testing / for your simulations. Matlab custom arguments just need to be passed in a comma-separated fashion (e.g.: 1, 155, 3).

Selecting Vehicles

You can select, for each vehicle individually, whether they should be ignored, simulated, or if a real vehicle is used with that vehicle ID during the simulation. The buttons below the scrollable view allow you to set the state for all vehicles at once. Vehicles that are set to be off will be ignored by your script, as their IDs are not passed to it. You do not need to start the simulated vehicles - the LCC does that for you.

Warning: If you have not started the LCC with the correct parameters, you might not be able to connect to the real vehicles.

Simulated Time

This switch should be self-explanatory - if you want to use simulated time, turn it on, else turn it off.

Lab mode

The IPS tracks the real vehicles, so it should be turned on if real vehicles are used. In any other case, it should stay turned off.

Deploy Remote

If you select this option, the behaviour of the whole deployment fundamentally changes. Your software is no longer deployed locally, on your device, but on the NUCs (HLCs) which are used in the Lab. Your system must be set up similarly to the main Lab PC for this option to actually work. The following requirements must be fulfilled.

• The main Lab PC (IP: 192.168.1.249) must be running (with an Apache Server), ideally before the NUCs are turned on. The middleware, cpm library and autostart software must be built - the build script puts data required for the software to work on the NUCs in folders that allow the NUCs to download it from the Apache Server (/var/www/html/nuc).
• Your folder structure must match the recommended folder structure (usage of ~/dev/...) for both the cpm library and the software repository. If your script/program relies on this data, then you should always refer to other programs using paths relative from ~ (so do not use /home/username explicitly). Cpm library and middleware can be found in the same folders on the NUCs.
• All required data must lie in the same folder as your executable or script. The whole folder containig it gets uploaded to each NUC. If you depend on other data (except for the Middleware or cpm library, which are uploaded separately), put it in that folder, or your program might not work correctly. WIP: Set folder from which on all data should be uploaded, name script within that folder separately
• If you use Matlab then you need to use the init script to load required data and to setup or reader and writer and include it in your own script folder, or - alternatively - use a script that is inspired by the init script. QOS_LOCAL_COMMUNICATION.xml is always located in ~/dev/software/hlc/middleware/build, and precompiled DDS IDL Matlab files can always be found in ~/cpm_base/cpm_lib/dds_idl_matlab. Other files can not be expected to be found on the NUC, unless you put them in the same folder as your own script.
• The UI indicates how many NUCs are online. Vehicle IDs are matched to available NUC IPs in an ascending order (IP ...211 → ID 1, IP ...215 → ID 4), depending on the vehicle IDs you have selected. The UI shows you how many NUCs are currently online (matching might take up to a minute after the NUCs have been booted and your program has started.) You cannot simulate more vehicles than NUCs are available - each NUC is always responsible for one vehilce only. Else, please use local deployment (or start additional scripts locally manually).
  

The location of the cpm library is always set using LD_LIBRARY_PATH in the local terminal - you do not need to take care of this in your program, as long as you have linked the library properly.

Deploy / Kill

When you have finished your setup, you can launch all the components / scripts by clicking on Deploy. Not all software starts immediately then. Some, e.g. those that rely on the Middleware, wait until you start the simulation in the Timer Tab. (Wait for the program to show up before you start the simulation)

Local: This starts several tmux sessions that run the required scripts. These sessions are terminated when you press on Kill. A stop signal is sent to all timers when the kill button gets pressed.

Remote: The folder in which the script is located gets uploaded to the NUCs if you choose to deploy the software remotely. Each HLC/NUC script gets assigned a single vehicle ID. IDs are given in ascending order regarding the selected vehicle IDs and the available HLC IDs. Not all vehicles might be controlled, if not enough NUCs are online. Middleware and Script are deployed on the HLCs, simulated vehicles, IPS and CloudDiscoveryService are deployed on the local machine.

Important note: Always use Kill after you have finished, or else some software might end up running on a system until it is restarted.

Relevant information for remote deployment

The HLCs use a startup script that takes the cpm library and the Middleware from an Apache server located on the Lab's main PC. The according files are updated every single time that these components are built. If you changed them during the lab run / if they are missing, please rebuild them and restart the NUCs/HLCs, so that they get the new software.

This decision was made to reduce upload traffic when files are uploaded to the HLCs during a lab run.

Manual Control

Each vehicle can be controlled manually with a joystick or gamepad. First, make sure your gamepad works properly using jstest-gtk. Enter the ID of the desired vehicle and click start.

The two progress bars in the UI indicate the commanded throttle and steering position.

The manual control overrides the reference trajectory based control. Thus it is important to click "stop" before sending reference trajectories.

Parameters

Defining Initial Parameters for the Participants

Initial parameters can be defined using the parameters.yaml - file. For most parameters, there is yet no convention regarding their name and types, so please contact someone responsible for the LCC if this part of the documentation has not been updated yet.

The parameters are stored in the YAML format in the file parameters.yaml in the directory of the LCC. Some parameters are distributed on program startup, these must be either edited in the LCC before restarting it, or the can be edited manually by changing the content of the YAML file:

Six different parameter types can be defined - bool, integer, double and string as well as comma-separated lists of integers and doubles. The parameters consist of a name (e.g. trajectory_controller/lateral_D_gain), a value (or set of values) and an information string that can be used to describe the purpose of the parameter.

Setting Parameters in the GUI

Parameters are shown in the LCC UI in the parameters tab. This UI simplifies the editing process of the available parameters - they can be deleted or changed, and new parameters can be created as well using the UI tools. Thus, if desired, the YAML file does not need to be used explicitly.

The LCC can use different YAML files as well. A file chooser has been implemented to load and save parameter configurations (to / from YAML files).

Save can be used to store the current configuration in the current file.

Save As can be used to store the current configuration in a new file.

Reload can be used to reload the currently selected file - this overwrites any unsaved changes made in between.

Load can be used to load a new file.

Timer

General Timer Functionalities

The LCC can be used to start / stop the execution of all applications that use the cpm timer (see synchronization) centrally. In the future, it might also be possible to restart the current simulation without restarting the LCC. This functionality is available both in the real-time and in the simulated time case.

The timer UI shows all participants that use the timer and whose ReadySignal messages have been received by the LCC. The participant's ID, the time passed since its last message was received, its current status and (in simulated time) its next active time step are shown in the UI.

Participant Status

Simulated Time

In the simulated time case, the columns Participant status and Next timestep can be a useful tool for debugging and monitoring purposes. The latter indicates at which simulated point in time the participant is woken up again to perform its periodic task.

Current time step below the table indicates the current simulated time.

The timing itself is managed by the LCC itself internally. It manages the received ReadySignals of all participants and progresses to the next smallest timestep whenever all participants of the current timestep have signaled that they have finished their current computation. For more information, have a look at the page about synchronization.

Logs

The cpm library provides a logging functionality that includes writing to stdout, to a log file and to a RTI DDS DataWriter. The logs sent via the latter over the network are listened to by the LCC and shown in the Logs UI. (The LCC only show the newest ~10000 logs to keep the UI responsive). 

Log structure

The log messages include a unique identifier of the sender (ID), the content of the log message (Content) and the point in time when the log message was created (At time). They appear in a table in the middle of the logs view.

The Autoscroll check button can be used to toggle automatic scrolling to the newest log entry on or off. The newest log entry is always at the bottom of the list. Entries are sorted w.r.t. their timestamp.

If the content of a cell is not fully visible, the user can change the width of each column using the mouse (by dragging the vertical lines between each of the cells at the head of the table). If that is not sufficient, the user can also hover over the region of interest - the full text then appears below the pointer.

Filtering Logs

The logs can be filtered using a regex search. The search can either be performed over all columns or only in one of them - this can be selected using the filter column combo box. The regex search string can be put in the filter string search entry. The table below either shows the result of the applied filter, or all logs if no filter is applied (if the search entry is empty).

Warning: A filter is only applied to all messages that have been received up to that point in time. New logs are received in the background, but are not added to the result of the search unless the search string is changed (which starts a new search).