Request for Comments: Ideas for Twix 2

[Narcha]

There are numerous ideas for a possible new version of twix floating around in the team.
The purpose of this issue is to collect those ideas and to host the discussion around them.

[h3ndrk]

Flowing data

MATE and Twix 1 had a collection of panels that each have their own state and functionality. One drawback is that panels that need common data processing need to calculate this each on their own. Another drawback is that panels cannot communicate and coordinate with each other because of the separation.

One more flexible approach is to model the data flow from source to target. The source is usually a NAO (connected communication server) and the target is usually a GUI for the user. One possible model is a data pipeline where processing steps between source and target can be defined (similar to ordered nodes in the framework cyclers). Another model is a processing graph (directed acyclic graph) where nodes are processing entities and edges mark data flows.

Flows defined in files

In MATE we had the concept of loadable/storable layouts which allowed to easily switch between predefined arrangements of panels with settings. We should keep the highlighted features for Twix 2.

MATE and Twix 1 had a sophisticated GUI that allowed to arrange panels e.g. via the mouse. These arrangements are then saved and restored later. A different approach would be to drop the GUI requirement for arrangement but rather define flows and arrangements in files with your favorite text editor. This would include GUI things in the flows.

Lua for fast prototyping

Lua has prooven to be a very easy and fast way to define behavior simulator scenarios and Twix 1 transformation functions. Twix 2 flows may also leverage this potential by defining flows in Lua.

The Lua files may be executed once to initialize a flow or executed for each frame of new data coming in.

Nice to have: Hot reloading of Lua files would allow to keep Twix 2 open all the time and edit+save the flows in your favorite editor.

[Fyor]

Some things that came to mind whilst on the train back from GORE.

Jersey/Player number as selection instead of IP

Allow for quicker switching during a test match without needing to keep track of ip to number mapping. Could be listed as 10.0.24.21 | 7. (Defined by player_number in head config file)

Recording and replaying in behavior simulator

Record a limited set of info (from the panels) for a robot and what's needed for the behavior simulator. Then replay in the behavior simulator with the extra recorded params also available. Allows for analyzing behavior after a match.

Robot status

Show the status of each robot in the robot selection dropdown, you might be able to this by looking at the data resend by the GameController to the TeamCommunicator.

[h3ndrk]

Two Configuration Domains

During design discussions of the data flow approach, we found that two "configuration" domains exist: 1. the selected robots to connect to and 2. the specific data flow to execute with the selected robots.

We found two approaches to implement that:

Data Flow Generation Approach

The data flow is generated from a piece of code which could be named "generator". The input of the generator is at least the set of robots. The output is a data flow that is specialized for the current set of robots. Nodes of this data flow can be very simple because they only need to handle a scalar data stream.

Non-Scalar Connections Approach

Types of data streams may contain values for multiple robots. Special aggregation and filter nodes allow to reduce the robot-dimension, if necessary. The reduction criteria can be influenced by configuration values or GUI elements (e.g. robot selector). The whole data flow can be statically configured and only the robot selection would be dynamic.

[h3ndrk]