Software Architecture Overview


Currently none of the interfaces (hardware, software) are definitive. This means that we might still change this. Developing educational material around Mirte is possible, but you should be able to modify this in case we change the interfaces.

Software Architecture

As the robot is meant for education, most of the design decisions we made were made with that in mind. This means we were forced to make decisions in the speed vs usability (/learnability) tradeoff and decided to go for the learnability over speed. We this improving speed should, at some point, be done by the students themselves.

Full Software Architecture

Full architecture overview of the Mirte software. Repositories are shown in red, ROS nodes in blue, and systemd services in green. More explanation can be found in the corresponding tabs. The dataflow is shown with arrows and will be explained in the next section.

Software Flows

Settings flow.

Like described earlier there are some things that you need to set before you can use the robot. This involves both uploading telemetrix to the MCU, and defining the connected hardware. Both can be done via commandline and web interface.

When uploading telemetrix to the MCU from the web interface, a request will be sent to the backend to execute the same command as you would execute when in a terminal.

When a user changes the settings in the web interface a YAML file is generated and uploaded via the backend to the robot. This will overwrite the mirte_user_config.yaml file and overwrite the parameters in the running parameter server. The backend will also stop the running telemetrix node and restart it so the initialization will be done again with the new parameters. By restarting the telemetrix node, this node will get the new settings from the parameter server and initialize this using mirte-telemetrix-aio which will apply it on the MCU with mirte-telemetrix4Arduino.

You can also connect to your own wifi. Whe doing this from the web interface, it will communicate the change right away to the wifi-connect server which will use NetworkManager accordingly.


In the current implementation the YAML config is generated in the web interface and uploaded to the robot through the backend. We will redesign this in the future and implement a version where the web interface will communicate via roslibjs and therefore also be able to reflect the settings as they are.


Usually one does not change the parameters within a running ROS system. We do think that these kind of settings belong to the parameter server since they usually do not change. In this educational robot we try to also make it easy to modify your robot.