• Changing the format of maps is a topic that was developed by the developments in the field of a graphical map editor. After the implementation of the beta version of the graphic editor, the question of changing the format of the maps became.
• It was proposed to divide maps into loosely connected layers. Each layer stores data of a separate type: information about the types of cells of the field, the location of frames, the list and characteristics of watchtowers, information about grouping objects and other layers. It was decided to leave some of the layers for further discussion, and some decided to freeze to start development.
• Demonstrating the first implementation generated the following suggestions. It was proposed to change the structure of the classes, add dataclasses for each type of object, but keep all map objects in a single place, without dividing storage into layers. Access to the map layers for the library user is realized by filtering objects. At the moment, the transition to a new storage format, serialization and deserialization broke the rendering and after the final discussion and approval of the architecture, this will be fixed.
• Joystick problems were identified: the use of the pygame library for its implementation, and the difficulties in supporting this application. In addition, it was noted that all other graphical duckietown applications are implemented in PyQt. Given the expertise in PyQt, it was decided to rewrite this application.
• A serious problem was identified and discussed in the robotarium. The bottleneck is marker detection. This is a resource intensive process. Running it on the server leads to huge network load and scalability issues. But the detection process on watchtower is too slow. The identified problem was solved by dramatically changing the architecture of the camera image acquisition and detection units. This increased the detection rate by almost 10 times. The issues of the size of the resulting image layer and testing the accuracy of the new solution with the previous one remained not discussed.
• Driver stress estimation system could be built on top of Duckietown simulator -- it should use simulator camera input and evaluate “Driver behavior system”. Combining simulator data with real car videos car we can design the following systems:

1. Driver stress estimation taking into account physiological data
2. Evaluation system for autopilot maturity

The round table was held with the support of the Ministry of Science and Higher Education of the Russian Federation by the Agreement № 075-15-2020-933 dated 13.11.2020 on the provision of a grant in the form of subsidies from the federal budget for the implementation of state support for the establishment and development of the world-class scientific center