Introduction

Overview

mimir serves as a simple reference implementation to achieve an optimization-based decision support in the FHF project: Catch control in purse seining [35]. The program typically runs to provide algorithm outputs to another application, for instance a graphical application that visualizes the results. The algorithms are specifically set up to use the CasADi [4] framework and its interfaces to various algorithm libraries, including optimization problem solvers and numerical integrators.

We provide a few algorithms that follows an interface defined by mimir::IAlgorithm. The interface consists of only three functions: initialize(), solve(), and timer(). These functions are controlled by a state machine, mimir::StateMachine, using Boost StateChart [26], which strives to ensure that the solve step is executed on a regular interval. The state machine is run by the mimir executable and loads one algorithm with settings specified by a YAML configuration file. The inputs to, and outputs from, an algorithm are exchanged using the data distribution service standard OMG DDS [34], which is a communication middleware that takes care of the data sharing with other applications. The Diagram in Fig. 1 illustrates the uncomplicated algorithm wrapper implementation in mimir.

Fig. 1 Component diagram for Mimir.

Running an algorithm

To load mimir with a specific algorithm, you need to provide the executable with a YAML configuration file similar the the one below. Each algorithm has its own expected schema. Available algorithms are found in Namespace mimir::algorithm. Most application settings are contained in the configuration file, but there are a few more command line options available, see Manpage.

YAML config file

The algorithm:command and algorithm:notifier entries are used to configure the DDS topics for user commands and state machine transition notifications. They use the interface definition language types indicated in the comment, which are defined in the RatatoskIDL dependency. Each algorithm has its own algorithm-specific schema; consult the documentation for the algorithm you intend to use.

# Excerpt of /path/to/config.yml, with 'algorithm-specific' map not expanded:
---
dds:
  domain: 0                                # DDS domain to connect to
algorithm:
  name: PursePlanner                       # Name identifier of algorithm
  command:
    request_topic: fkin_cmd                # IDL type: fkin::Command
    reply_topic: fkin_cmd_resp             # IDL type: fkin::CommandResponse
    recipient: PursePlanner                # Recipient identifier request/reply
  notifier:
    notify_topic: fkin_state_notification  # IDL type: fkin::ProcessStateKind
    identifier: PursePlanner               # Identifier of notification

PursePlanner:
  *algorithm-specific
...

Fig. 2 YAML config visualization.

Note

As can be seen in the mimir::StateMachine, the algorithm enters a standby state by default. The user needs to issue a START_PROCESS to the user specified request_topic (DDS) in order for the algorithm to start.

Interacting with the algorithm

The user can post commands to the mimir::StateMachine to control in which state the algorithm should be. This is achieved through DDS signals, which is translated to state machine events.

• The user sends a DDS fkin::Command defined in RatatoskIDL.

• mimir::control::CommandResponder translates between commands and state machine events.

• mimir::control::StateNotifier broadcasts changes on DDS using a fkin::ProcessStateKind.

The sequence diagram in Fig. 3 shows a possible realization.

Fig. 3 A sequence diagram for a simple start-then-stop of Mimir.