• High Level Structure

    Andrei Gramakov • 6 days ago • 0 comments

    After some thinking process, I’ve split the robot into 4 subsystems

    • Main Controller
    • Physical Transportation Subsystem
    • Power Subsystem
    • Cat Interaction Mechanism

    To illustrate the structure, I used the Block Definition Diagram of SysML (I hope, correctly):

    As you can see, the CAN interface is already part of the architecture. It is so, because I want to reuse it in my other robot that already uses CAN but.

    Meanwhile, I’m not sure 100% about the interface detail for the Cat Interaction Mechanism… Probably I’ll remove it, since I don’t have a reason to decide about it right now, and according to the Clean Architecture principles, decisions about details should be delayed as much as possible.

    Next time I'm going to develop white boxes for the subsystems.

  • High Level Decisions

    Andrei Gramakov • 09/26/2023 at 22:06 • 0 comments

    Finally, decisions! The real development!

    Last time I published the Intro of the architecture. The main points from there were that we will be using making decisions:

    • Reusability
    • Emphasis on architecture

    Let’s unfold it to the architecture constrains

    Constrains

    • Should follow the Clean Architecture principles
    • Should be modular and reusable
    • Hardware details should go to the thin last layer
    • Most of the development should be done platform-independent.

    Talking about reusability, I want to use the movement system in my other projects, so let’s add also this:

    • Movement logic should be easily detachable of the application logic - to be able to use it in other projects

    And let’s not forget, it is for the cat, so let’s add also this constrains for the hardware:

    • Motors must be quite

    Now let’s decide on the scope

    System Scope and Context

    According to the arc42 system requires having two types of context to be defined in order to define the system scope:

    • Business context. Describes interaction with the environment.
    • Technical context. Describes technical interfaces

    The business context is represented by a diagram with all counterparts interacting with the system. It is quite simple as the system is simple.

    For the technical context, let’s divide the system in two main domains:

    • Physical Transportation System
    • Main Controller

    These domains will all the software in two parts. Also, let’s outline the main components of each domain. To illustrate the context, let’s use a UML deployment diagram:

    I used very general words to keep details to the end. But here I already made several detailed decisions.

    • The Main Controller and the Transportation System are in communication through CAN. I will decide in the hi-level protocol later, but my other robot already uses CAN, so it follows my reusability strategy
    • I specified all the most obvious components. I’ve separated Application logic of Driver Logics already, so it will be much simpler to prepare the next steps. Maybe too early, but we will see…

    Next time we will prepare a Building Block view, designing the full system decomposition.


  • Architecture: Introduction and Stakeholders

    Andrei Gramakov • 09/21/2023 at 20:32 • 0 comments

    Here are the first three chapters of my arc42-based architecture documentation. Next time we are doing the architecture constrains and maybe the system scope. It is necessary if I want to make it right, but if you are bored, please wait for 2–3 posts, when we will start describing the system structure 🙂

    Introduction and Goals

    This project is an effort of establishing a development workflow via practical product development.

    There are two main requirements for the project:

    • The product should be a working and entertaining for a cat autonomous toy.
    • Components, processes and libraries of the project must be developed to be reusable in other projects.

    The project is based on the following principles:

    • Architecture-oriented
      • Develop the right architecture using architectural best practices
    • Result-oriented and minimalistic
      • Progress over perfection
    • Integration-oriented
      • Reusing existing libraries, projects, etc. Minimum development of individual pieces
    • Reusable in my other projects
      • It should be done automatically with a good architecture. But I want to make several special decisions to make the project easy to transfer to my another robotic project.

    Quality Goals

    NQualityMotivation
    1Cat FriendlinessThe product should be interesting and attractive for a cat
    2SafetyThe product should be safe for pets, it should not harm the pet in any way
    3Development ReusabilityThe project components should be easy to reuse in other projects. Especially in my own projects

    Stakeholders

    Role/NameExpectations
    Cats (especially Bastet)Cats should get a simple, funny toy that is able to entertain them.
    DevelopersDevelopers must get a polished, transparent quality product that can be reused or valuable from the education point of view
    Andrei GramakovI suppose to do two things at once: 1. improve my architect skills, 2. move my another enormously big robotic project.
    Potential employers of Andrei GramakovShould get an illustrative entry in my portfolio to better understand my skills and experience.


  • Selecting the Tools

    Andrei Gramakov • 09/18/2023 at 20:24 • 0 comments

    There are some decisions to make. These decisions are basically our tools preparation. Let’s start from the frameworks

    Frameworks

    Architecture frameworks:

    • arc42 - describes the structure, tools are up to implementors, can be used with other frameworks
    • 4+1 - Generic and can be not enough for complex systems, can be used with other frameworks
    • C4 model - lacking the structure, often used with arc42
    • UML - SW oriented language. No documentation structure can be used with other frameworks. But as a visual framework it is very developed and widely used.
    • RM-ODP - for Distributed Processing. It seems not very suitable for the project
    • Systems Modeling Language (SysML) - extension of UML to support not only SW systems. Should be
    • TOGAF - popular framework for enterprise architecture. To be honest, looks too complicated for me and my project.
    • ArchiMate - a visual addition to TOGAF. These folks are super developed and have a very steep learning curve, so I will skip them for this time.

    My choice is: 

    🎉 arc42 + SysML 🎉

    Having them two, I will have a text guidance + visual guidance. Also, I already have a quite comprehensive experience with UML, so it should help the process.

    Subjects of Development

    Now let’s consider what we are going to create. In the book Clean Architecture, the author provides a picture like this to illustrate what is the clean architecture:

    We should start from defining the core and delay the rest decision as long as possible. The outer layer should be dependent on the inner one.

    Next Step

    Next time, I will define some basic entities we will be working with and will describe the first chapters of the arc42 template, such as:

    1. Introduction and Goals
    2. Constraints
    3. Context and Scope
    4. Solution Strategy

  • Architecture of Architecture

    Andrei Gramakov • 09/14/2023 at 21:37 • 0 comments

    Okay, to build an architecture I need some model or workflow. I could come up with something, but it contradicts to one of the project principles - “integration first”. I don’t want to reinvent new things if they are already invented. So let’s see what we have…

    Also, there are several nice articles for orientation in all this ocean

    I need some time to think about it, so the next step is postponed for the next time… But the next time we will have the guidance (I’ll explain my choice) and we will do some pretty stuff!

  • LeOn, a Cat Companion. Architecture First.

    Andrei Gramakov • 09/10/2023 at 19:56 • 0 comments

    With this post, I start my new robotic project. This project will have several important features:

    • Architecture-oriented
      • Develop the right architecture using architectural best practices
    • Result-oriented and minimalistic
      • Progress over perfection
    • Integration-oriented.
      • Reusing existing libraries, projects, etc. Minimum development of individual pieces
    • Reusable in my other projects
      • It should be done automatically with a good architecture. But I want to make several special decisions to make the project easy to transfer to my another robotic project

    What is the project about?

    It is a cat companion. A simple robot that can move around, avoid big obstacles and move a stick for playing with a cat.

    What is the first step?

    I’m starting with the architecture development. I will try to make the most abstract decisions first, leaving the implementation details to the very end.

    The first step is development of the use cases. Basically, there are 3 actors for this robot - a cat, a cat owner, and me, a robotic developer. As a developer, It is important for me to have a moving platform (legs, wheels, etc.) reusable by other projects, so it is also reflected in my use case diagram:

    That is it for now. Next time we will probably define the system requirements based on each use case.