AMR-One. 03 Architecting the solution

This is the third on the series of posts about the AMR-One Project. Today I will talk about architecting the solution.

In the previous post I described the requirements, so we know now what are the functions that the system should accomplish. But before defining the tasks to accomplish these requirements, we need to have an idea of how are we going to build the solution. For that, some people tend to create more technical requirements, in the language of the developers. I prefer to spend some time working on a pre-design of the whole system, from the mechanical, electrical, and software sides, involving representative people from each of the disciplines. It is essentially an iterative process, but having a basic architecture already opens minds to understand the tasks needed to build the system. 

When we have this general pre-design of the system, we could go further on the class definition for SW, materials for mechanics, or technologies for hardware.

Let's see as an example how this architecture has been defined in the AMR-One project.

The AMR-One case

As we saw in the episode about the roadmap, there are at least two versions of the product, with different functionalities. But we will consider the mechanical, hardware, and software approach for both versions 1.x and 2.x.

The mechanical approach

The mechanical approach starts with an overall analysis of the kinematics of the needed system, then continue with some freehand sketches and then with some draft ideas using some computer tools, but not going in deep on the design.

The hardware architecture

The hardware and electrical architecture define the components (sensors and actuators) but what is more important, helps to define the processing systems and the functions assigned to each of them. (click on the image to see it bigger)

HW architecture

We define 4 processing systems: 

• Safety PLC (Flexisoft)
• Low-level controller (LLC)
• High-level controller (HLC)
• Cloud base system

Going a bit further on the functions assigned to them we have that:

• The Safety PLC is responsible for ensuring the safety measures are executed reliably. It uses several inputs (Safety Lidar and safety stop buttons) to determine when there is a dangerous situation and the system should stop. There is therefore a program inside this PLC to ensure this behavior.

• The Low-Level Controller (LLC) is responsible for the Low-Level functions, which are the following:
• Sensory reading
• Traction motors PIDs controls
• Velocities (linear and angular) conversion into inputs for the PIDs controls
• Magnetic guidance
• RFID tags reading and execution of actions
• Pinhook control
• Buzzer control for warnings
• Device HMI data
• ROS publisher to connect with HLC/Cloud Monitoring
• ROS publisher/subscriber to connect with HLC/ROS navigation (AMR-One v2.0)

• The High-Level Controller (HLC) is responsible mainly for:
• Communication with the LLC
• Communication to the cloud
• User interface (AMR-One v2.0)
• Localization, navigation, and mapping based on ROS (AMR-One v2.0)

• The cloud-based processing system is not described in the hardware architecture because it would not require additional hardware from us.

The software structures

As mentioned, there are four processing systems, each of them with programs inside. 

The structures are quite self-explanatory. Only to mention that the items with yellow background correspond to v2.0 of the project and the rest correspond to v1.0 (click on the images to see them bigger)

See the following video for more details:

Now we know how to approach the solution and we are prepared to work on building a Work Breakdown Structure to define the Epics and tasks of the project, but this will come in the next post.