System Architecture MSD19: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
No edit summary
No edit summary
Line 6: Line 6:
__TOC__
__TOC__


Autonomous drone referee system architecture has been based on CAFCR[1] where the model presented decomposes the construction into its respective component. Here 4 main components exist in order achieve a fully functioning referee aiding system. A drone platform carries out the movements determined by the action planner and a perception system streams visual into a HMI. Concurrently within the HMI, captured footages are converted into viewpoints within the simulated environment.
Autonomous drone referee system architecture has been implemented by taking into account both CAFCR[1] and SafeRobots[2] frameworks. The focus in the project has been heavily concentrated towards the design and implementation having derived the requirement specifications and hardware resources available
As a tailored approach to our goal the team developed the system level reasoning based on abstract knowledge defined in the Problem space. These were the requirement chosen to be most critical, the context of the problem and which problems we strive most to address.
Then design choices were made based on thereof to define the Solution Space consisting of hardware and other tools to utilise, algorithms for path planning and communication protocols. This namely was the design time and opportunity to mitigate uncertainties.
In the operational space covers the process of developing tangible deliverables that satisfy functional and non-functional requirements that were initially prescribed.  
The overall methodology of our roadmap can be found in the table below:

Revision as of 13:52, 24 March 2020

Autonomous drone referee system architecture has been implemented by taking into account both CAFCR[1] and SafeRobots[2] frameworks. The focus in the project has been heavily concentrated towards the design and implementation having derived the requirement specifications and hardware resources available As a tailored approach to our goal the team developed the system level reasoning based on abstract knowledge defined in the Problem space. These were the requirement chosen to be most critical, the context of the problem and which problems we strive most to address. Then design choices were made based on thereof to define the Solution Space consisting of hardware and other tools to utilise, algorithms for path planning and communication protocols. This namely was the design time and opportunity to mitigate uncertainties. In the operational space covers the process of developing tangible deliverables that satisfy functional and non-functional requirements that were initially prescribed. The overall methodology of our roadmap can be found in the table below:

Retrieved from "https://cstwiki.wtb.tue.nl/index.php?title=System_Architecture_MSD19&oldid=87957"