Format should be UNIX timestamp, i.e., a floating-point number with seconds since the Unix epoch.

e.g. temperature 0 (if sensor is disconnected) shows up as 40 (bright yellow)

"Absolute" sensor labels currently used in the UI (N, NE, NW etc.) are deprecated. Should be replaced:

N->F
NE->FR
etc.

Enable camera image display in the GUI, through gstreamer.

If possible a button in the 'Caus Data' sheet for extending all / collapsing all menu-nodes

The default open path, on first UI run should be just the user's home folder.

Spawning an Arena file has different orientation in the simulator and in the UI. The UI should have the same behavior as the simulator.

The limits for the temperature setpoint should be set to (26,45) (current limits are (20,42)).

Selecting ON, 0, 0 stops the vibration, but OFF, 0, 0 does not have any effect.

Complete UI state should be saved as a ui-project file. Specifically, the following info needs to be saved:

• active .arena file
• arena layer loaded in the UI
• trend graph settings (number and location of open graphs, data source displayed in each graph)
• manual connection settings
• CASU groups
• last setpoints sent to the CASUs through the GUI

Vibration stimulus does not have a marker so far in the UI

Implement a context menu for the arena scene. This is a dummy issue.

Enable the following functionality:

• deploy controllers
• run experiment
• stop experiment
• collect data
• clean logs on deployment target
• display output of the command-line tools

Documentation for the command-line tools is available here.

Tabs need to be aded to make the dialog more readable. I see the need for the following tabs:

• Arena (Sensor graphics ON on startup, name of arena layer to visualize)
• Data and Trends (most of the current Settings dialog elements)
• Simulator (Simulator location, a new QLineEdit vidget to allow passing additional parameters to the simulator; more UI elements might be needed in the future)
• Camera (Camera stream source, parameters)

The dialog should not be created in code but usig Qt form design tools.

I was expecting statements like the following

value1->setValidator(new QDoubleValidator(26.0,45.0,2));

in qdialogsetpoint.cpp to limit the setpoint values sent to the CASUs. However, if a value outside of the spcified range is passed, it will still be sent to the CASU.

Defining the dialogs in code causes code bloat and is more difficult to adapt an maintain.

Add colorbar to indicate temeprature sensor values. Colorbar should show and hide together with CASU's temperature sensors.

Compiling requires libboost-dev to be installed, which is actually required by libyaml-cpp-dev, which does not declare it as a dependency. Therefore, building a .deb in a clean environment fails due to /usr/include/yaml-cpp/node/node.h not finding boost/shared_ptr.hpp

Should file a bug report for the libyaml-cpp-dev debian package (version 0.5.1-1).

This is important for multi-environment setups (e.g. real and virtual arena).

The indicator on each CASU in the currently installed array points to the right. A manual check shows that the "F" sensor points downwards.

1-2-3  ||
4-5-6  ||
7-8-9  \/
      Front

not sure whether this is a local configuration or a built-in layout. How do we display in accurate orientation?

Add UI element to spawn CASUs, as specified in the .assisi (.arena) file. Should be a straightforward matter of calling sim.py with appropriate arguments.

Casu TOP temperature is not properly read or displayed. Instead of the TOP temperature, the value of estimated CASU temperature is displayed in the UI. Also, the WAX temperature is not displayed at all.

The user docs should be updated to reflect the new stimulus markers and other enhancements.

Every time the dialog is closed (by clicking on OK) and re-opened, an additional / character is added to all paths in the dialog.

Very often, groups are created with the aim of manipulating several CASUs in the same way, e.g. sending trending the same sensor reading from several CASUs. However, in the current implementation, the user still has to expand each individual treeview for every CASU and select the data to plot. One wrong click (i.e. click without having the control key properly pressed) can ruin the whole selection. This problem will become far worse as the number of CASUs increases.

A solution to this problem is to create an additional treeview item for the group. An action performed on an element of this treeview would be applied to all CASUs. @stribor14 please comment wheather you think that this approach is feasible.

By default, a trend graph scrolls along as new data arrives. However, if you use the mouse to drag where the image is centred, the trend time limits stay fixed (i.e. new data gets drawn off the RHS of the screen).

Is it possible to add a button or context menu option to restore scrolling with the latest data?

Visualization can be similar to current proximity sensor visualization.

• Proximity sensor color should be changed to yellow
• Active airflow visualized with white circle around CASU, Alpha = 0.5
• Inactive airflow without visualization

If there no .nbg or .dep file given in the arena configuration file (.assisi), the program crashes.

To be consistent with the on-CASU logging.

• README.md (dependencies, build instructions)
• Doxygen

Enable sending of setpoints through a context menu (right-click) in graphic scene.

Some pixels get deleted and are not redrawn until the visualization area comes out of focus.

This happens only while no CASUs are connected, so it's not a high priority thing.

Save session does not open the "Session save folder location". Maybe the Settings option should be renamed to "Default session save location"?

Lots of screenshots with a bit of text :)

The sensor orientation/ordering on the CASUs seems incorrect. This issue can be reproduced by having a bee circle around a CASU and observing the sequence of activated proximity sensors.

When simulator is started, program releases PID handle so the simulator won't close with GUI. When new instance of GUI is running, action "Stop simulator" does nothing altough a simulator is running.

Whenever a dialog is opened, the editable fields should be pre-populated with current setpoints (or default values if no setpoints are currently active, or the dialog is activated for a group of CASUs). This saves time when working with actuators that take several parameters (e.g. vibration).

Amplitude setpoint is always '8' no matter which setpoint you send to simulator.

Load saved session->Trend graphs tab->Crash!

The bug does not always show. Sometimes it's necessary to load the same session several times in a row until the bug shows.

Sometimes, opening the same session twice will create two instances of the same graph.

Clean up terminology in context menus referring to trending. The following would make sense:

• a graph refers to the axis on which the data is plotted
• a trend refers to the data itself
• matlab uses the terms plot/axes

Having this in mind, it would be correct to change the context menu in the CASU data treeview to: "Plot selected on same axis"/"Plot selected on different axes"?

Add a dialog option for specifying vibration pattern setpoints.

Just an idea, maybe simple to implement but makes the usage a lot easier:
when adding a setpoint, the UI should inform you about the possible range for the stimulus.
e.g., vibration frequency [100-500]
vibration amplitude [0-100]

The Run button does not start the corresponding processes.

With new graphics markers for various sensors, temperature sensors should not move closer to CASU when IR sensor is hidden. This causes temp marker to be drawn on similar distance as vibration marker

Enable saving as vectorized (.pdf) files.

Attempting to open a new arena/session file, but then cancelling the operation destroys the current session. This is obviously not the desired behavior.

Can't figure out how to change setpoints.

Display CASU sensor values in the Graphics scene, as colour-coded patches.