build details

Show: section status errors & todos local changes recent changes last change in-page changes feedback controls

The Heroes - System Architecture: final report

Modified 2018-03-11 by Jacopo Tani

TODO: links to relevant files

task next (1 of 24) index
for:Jacopo Tanitask

The following was marked as "todo".

TODO: links to relevant files

File book/fall2017_projects/11_heroes_system_architecture/30-final-project-report-heroes.md.

File book/fall2017_projects/11_heroes_system_architecture/30-final-project-report-heroes.md
in repo duckietown/docs-fall2017_projects branch master17 commit 2fcca8c7
last modified by Andrea Censi on 2018-09-02 16:46:23

Created by function create_notes_from_elements in module mcdp_docs.task_markers.

System Architecture refers to the high-level conceptual model that defines the structure and behaviour of a system. There are different ways to get an insight into the architecture of a system, for example functional decomposition diagrams, package composition, or a Finite State Machine diagram.

The final result

Modified 2018-03-11 by Jacopo Tani

The System Architecture project helped to ensure that the Fall 2018 projects integrate into the existing system. The role of the System Architect was to identify and solve problems that arose during the project development and integration, as well as influencing the high-level design of the system.

In Duckietown, the Finite State Machine (FSM) diagram plays an important role in determining how the higher-level system behaves in different scenarios. The FSM defines which states the system can be in, and which functionalities must be active in which states. During the project, the need for development on the FSM arose. Below is the resulting updated Finite State Machine (FSM) diagram.

The Finite State Machine

Mission and Scope

Modified 2018-02-22 by Sonja Brits

The System Architecture project was not a clearly defined work package, but rather a responsibility to ensure smooth development and integration of the new projects into the existing system.

Motivation

Modified 2018-02-22 by Sonja Brits

With many teams working on many different parts of the system, chaos is inevitable (without divine intervention). The role of the System Architect was to ensure that development and intergation of new projects goes smoothly, by addressing interface, contract and dependency issues between the teams.

During the project, the need arose for an updated version of the FSM.

Existing solution

Modified 2018-02-22 by Sonja Brits

Duckietown already had an existing system architecture. As metioned before, the FSM is closely related to the system architecture, since it defined the high-level behaviour of the system. There was an existing infrastructure for the FSM, which could be modified to include the newly developed functionality. The infrastructure consisted of the fsm ROS package, the configuration of the FSM in the form of .yaml files, as well as a tool to visualise the FSM structure.

The fsm package consists of two nodes, namely the fsm_node and the logic_gate_node. The fsm_node is in charge of determining the current state and computing state transitions, and the logic_gate_node acts as a helper node to the fsm_node. For more information, see the README of the fsm package, found at 20-indefinite-navigation/fsm/README.md.

TODO for Jacopo Tani: README for fsm in indefinite navigation seems out of place

previous task next (2 of 24) index
for:Jacopo Tanitask

The following was marked as "todo".

TODO for Jacopo Tani: README for fsm in indefinite navigation seems out of place

File book/fall2017_projects/11_heroes_system_architecture/30-final-project-report-heroes.md.

File book/fall2017_projects/11_heroes_system_architecture/30-final-project-report-heroes.md
in repo duckietown/docs-fall2017_projects branch master17 commit 2fcca8c7
last modified by Andrea Censi on 2018-09-02 16:46:23

Created by function create_notes_from_elements in module mcdp_docs.task_markers.

While the fsm package handles the computation of state transitions, the FSM states and transitions can be configured using the supplied .yaml files. The fsm package then reads the configuration in order to know which states and transitions are available in the system. This allows for separation of the computation and configuration of the FSM.

There exists a tool to parse and visualise the FSM configuration (in the form of an FSM diagram), found at 00-infrastructure/ros_diagram/parse_fsm.py. The tool parses the .yaml configuration file and outputs a .dot format graph, which can be converted to .png.

Opportunity

Modified 2018-02-22 by Sonja Brits

During Fall 2018, many new projects were being developed by multiple teams. This created the need for someone to ensure harmony between the projects and the system during the process.

Duckietown was being expanded with new functionalities such as parking and deep learning lane following. The previous FSM was not equipped to deal with the new features, therefore it had to be further developed.

Definition of the problem

Modified 2018-02-22 by Sonja Brits

Ensuring that development of the new projects integrate into the existing system with as little as possible chaos. This implies ensuring that all teams understand their package’s objective and their impact on the bigger system.

Contribution / Added functionality

Modified 2018-02-22 by Sonja Brits

The contribution of this project was in the form of both organisational activities, as well as software development. System integration of project modules. The approach can be summarised as follows:

  • Become one with the goals of Duckietown
  • Be familiar with the current system architecture
  • Track changes and identify how they influence the system.
  • Keep close communication with project teams.
  • Act as middlemand/helper to facilitate negotiation of contracts in and between groups.
  • Monitor status of projects to find possible problems.

Formal performance evaluation / Results

Modified 2018-02-22 by Sonja Brits

Be rigorous!

  • For each of the tasks you defined in you problem formulation, provide quantitative results (i.e., the evaluation of the previously introduced performance metrics)
  • Compare your results to the success targets. Explain successes or failures.
  • Compare your results to the “state of the art” / previous implementation where relevant. Explain failure / success.
  • Include an explanation / discussion of the results. Where things (as / better than / worst than) you expected? What were the biggest challenges?

Future avenues of development

Modified 2018-02-28 by tanij

The existing framework for the FSM made it relatively easy to update it to include new functionalities (once you’ve decided on the system architecture). The FSM is configured using .yaml. files, which are then loaded into the fsm_node.

Development of the updated FSM was done in response to a need before demo day, and while it has been tested on its own, it has not been tested thoroughly with all other parts of the system yet.

Because of mathjax bug

No questions found. You can ask a question on the website.