System Architecture MSD19

Internal Navigation

1. Main
2. System Architecture
3. Implementation
4. Conclusions & Recommendations
5. Manuals

Architectural Framework

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:

Problem Space

• Requirement1: Develop a safe system that will not cause damage or harm in case of malfunction
• Requirement2: Choose a solution that will enable to develop the project from simple to complex
• Requirement3: Formalize solution such that it can be transferrable to future work
• Context1: Drone platform and display
• Context2: Robot soccer MSL
• Problem1: How to track a ball for a referee such that they can make clear decisions
• Problem2: How to design a system using low computational resources

Solution Space

• Perception: Computer vision, Deep NN
• Navigation: Path planning in 1D, Path planning in 2D
• Platform: Crazyflie, Sensors, Camera, Power
• Communication: UWB, Radio

Operation Space

• Middleware: ROS, Crazyflie
• External Code Libraries: Craztflie_lib, OpenCV, libraries in Python
• Implementation: Executable software code, Virtual simulation
• Deployment: Model tests, hardware tests, software debugging

System Decomposition

Strategy

Definitions

Explanations

Realised

Definitions

Explanations

Layered System Hierarchy

Based on the aforementioned architectures, the system was tested at various stages ensuring at each layer of abstraction the design is sufficiently developed. Hierarchy between each layer indicates the functionalities needed to achieve the requirements of the design[3]. Enabling the lower layers to use information obtained from upper layer. Decisions taken for team division, coordination and work packages were accordingly mapped with milestones and deadlines to handle the items at each layer as project progressed. A selection was made in the workflow on the priority for which every functionality contributes towards as seen below. Several functions more of which regarding perception together with the hardware integration of this function and integration with navigation is part of our future work.

References

[1] Muller, Gerrit. 2018. System Architecting, vol. 18, Gaudí Systems Architecting, http://www.gaudisite.nl

[2] Ramaswamy, Arunkumar et al. “SafeRobots: A model-driven Framework for developing Robotic Systems”. 2014 IEEE/RSJ: 1517-1524.

[3] Maier, Mark W. 2009. The Art of Systems Architecting, 3rd Edition. Hoboken: CRC Press. p164