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.

AMR-One. 00 Introduction to the AMR-One Project

This post is the introduction to the AMR-One project series, a set of posts and videos on how to plan, manage and execute a technical project as well as on how to technically develop an autonomous robot.

The AMR-One project objective is to develop a prototype of an autonomous mobile robot for the industry, as a personal project, with some basic characteristics:

• Rotational base with damped traction system
• Safety system
• Pinhook system to hook trolleys from the bottom and carry them.
• Two navigation modes:
• Magnetic band guidance with RFID tags control
• SLAM based navigation using ROS
• Cloud monitoring (over AWS)

High, this is Alejandro Alonso and I will be here, through this interesting trip, where we will explore the details of this fascinating project!

During the following posts I will cover:

• The product strategy, roadmap, and product requirements (basic to have good focus and scope definition).
• The project management aspects, including
• The project management plan (rules on how to manage the project)
• Work breakdown structure (tool to identify the tasks)
• Planning from an agile perspective, including the Gantt and dependency graph as well as backlog and sprints plan
• Risk management, 
• Cost and time control
• Change management control, to approach correctly any change in the project
• The technical design, covers:
• The architecture of the system, both hardware, and software
• Electrical design
• Mechanical design
• Software design
• The manufacturing process, using modular structures and a few 3D printed parts

See the following introductory video.

I hope you enjoy this trip with me. Let’s make robots!

Cloud Monitoring for robots as IOT using AWS

AWS is a great Cloud Computing platform for many applications. Here I describe how I integrated ROS based mobile robots with IoT (IoTcore), Elasticsearch (Opensearch), and Kibana (OpenSearch Dashboards) to get Cloud Monitoring.

This video explains that under a personal project named "AMR-One" that covers the design and development of AMR-based solutions.

Link to the video: https://youtu.be/k_uQZ-rj-6M 

Related posts:

• Cloud Computing for our exponential world
• Is Amazon AWS Robomaker worth it?
• Is ROS ready for industry?
• ROS, for more than proofs of concept

Is Amazon AWS Robomaker worth it?

Amazon released AWS Robomaker last year (2018) as a service that makes it easy to create robotics applications at scale. But, what does it mean and how this could help us in our developments and release of real products?

The product

AWS RoboMaker nowadays is focused on extending the Robot Operating System (ROS) framework with cloud services. [1].

AWS Robomaker service suite includes nowadays (2019) the following components:

• Cloud Extensions for ROS: With them, it is possible to offload some resource-intensive computing processes that are used in robotics applications to the cloud and free up local compute resources. These extensions allows to integrate with AWS services like Amazon Kinesis Video Streams for video streaming, Amazon Rekognition for image and video analysis, Amazon Lex for speech recognition, Amazon Polly for speech generation, and Amazon CloudWatch for logging and monitoring. RoboMaker provides each of these cloud service extensions as open source ROS packages, so it is possible to build functions on the robot by taking advantage of cloud APIs[2]. Having said that, obviously AWS charges fees per usage of the cloud services. This seems to be the business model of AWS Robomaker for Amazon.

• Development Environment, based on AWS Cloud9, so it is possible to launch a dedicated workspace to edit, run, and debug robotics application code. RoboMaker's development environment includes the operating system, development software, and ROS automatically downloaded, compiled, and configured. Plus, RoboMaker cloud extensions and sample robotics applications are pre-integrated in the environment.

• Simulation system based on Gazebo, that supports large scale and parallel simulations, and automatically scales the underlying infrastructure based on the complexity of the simulation.

• Fleet Management service allows over-the-air deployment to deploy a robotics application into a robot fleet securely, so updates could be easily deployed in a full fleet or part of a fleet of robots.

(C) Amazon AWS Robomaker

Observations

The product sounds really interesting, but let's consider the following goods and bads from my personal point of view:

• One of the interesting things of being cloud based is that it could be used for development from anywhere, without the need to have ROS installed in the developers PC. This is a good starting point, but this is not usually a preferred long term solutions for developers, who use their preferred IDEs and tools for static code analysis. Anyway you could always use your IDE and tools and use only AWS cloud services.

• This solution support ROS Kinetic and Melody, the latest two long term support versions of ROS1, also it supports ROS2.

• Cloud extensions are really interesting. Having the capacity to run powerful computer vision algorithms in a massive computational environment in a transparent way is definitely a good option. The same happens with the other cloud based services offered by AWS. But you have to keep in mind that you need to ensure a reliable communications channel if your dependency to the cloud services is critical to your specific application to work properly. 

• It is very interesting that AWS Robomaker is always considering the idea of a fleet, so simulations and services could be used for the full set of robots.

• One of the things I really like is the option to deploy updated OTA (Over-the-air) to one or more robots in a fleet. Imagine you have 10 robots installed in a customer. If you update all of them in a shot may be risky. With this service you could update just one, then three and after everything is ok, then the rest, easily, with no headaches. 

• One of the things I like of the cloud services offered by AWS is that you pay per use, so you may even charge to customers based on this model in case you offer a robot-as-service business model

• You also could have cloud based metrics of the robots, so you could do preventive maintenance or monitoring.

• About the simulations, definitely developers could create much more powerful simulations in AWS Robomaker than if they have Gazebo simulator locally installed in their top notch powerful PCs, as AWS offer expandable computing power. This is just a question of how much computing power you need and how much money you are prepared to pay.

• About real product applications, nowadays I see that there is a risk on the dependency for reliable wifi connection. If your application depends on it, you need to implement alternative ways of communications, so you may need to implement a solution that switches from wifi to 4G in case wifi fails or degrade.

• Last thing is that somehow using AWS you need to accept that you are creating a dependency to these services, so you will not be easily able to implement other similar solutions with on-board computing in the future. Anyway, Amazon looks to be a good partner for a long term relationship.

---

Reference:

[1] What is AWS Robomaker: https://docs.aws.amazon.com/en_pv/robomaker/latest/dg/what-is-robomaker.html

[2]AWS Robomaker web page: https://aws.amazon.com/robomaker  

Is ROS ready for industry?

Recently I published my latest book “ROS Programming with Python” in Amazon. Some people asked me free promotional units of the book (just email me if you want yours), but what was really interesting was to find people very reluctant to ROS, saying it is just for education and not for the real Industry. I think ROS is starting to offer interesting options for Industry, but to evaluate that we need to know in advance that there are three different approaches of ROS: ROS 1, ROS 2 and ROS Industrial. Let me briefly explore them:

ROS 1

The Robot Operating System (ROS) is a flexible framework for writing robot software. It is a collection of tools, libraries, and conventions that aim to simplify the task of creating complex and robust robot behaviour across a wide variety of robotic platforms.

ROS 1 born as a solution for single robots, the PR2 from Willow Garage, although it was designed to be used in a variety of robots with no real time requirements.

Today we see ROS used not only on the PR2 and robots that are similar to the PR2, but also on wheeled robots of all sizes, legged humanoids, industrial arms, outdoor ground vehicles (including self-driving cars), aerial vehicles, surface vehicles, and more.

ROS 1 is nowadays the approach of ROS that most people knows, with several releases, being the last LTS versions (Long Term Support) Kinetic and Melodic. In fact, when you talk nowadays about ROS, it is widely accepted that you really are talking about ROS 1.

ROS Industrial

ROS-Industrial (or ROS-I) was created in 2012 to develop collaboration between ROS and the industry. 

ROS-Industrial is an open-source project that extends the advanced capabilities of ROS software to manufacturing.

ROS capabilities, such as advanced perception and path/grasp planning, can enable manufacturing robotic applications that were previously technically infeasible or cost prohibitive.

ROS-Industrial is released under the business-friendly BSD and Apache 2.0 licenses.

With ROS-I, BMW Group Logistics was able to incorporate several different sensors into their STR to enable sensor fusion within each mobile robot. ROS-I allows the different hardware and sensors contained within the vehicle to communicate with each other, and also allows the robot to communicate with different IoT solutions. BMW uses a cloud-based operating platform for central coordination of the STRs.

BMW, Microsoft and Open Robotics on an automation solution using ROS-I

ROS 2

ROS 2 was first introduced in 2014 in ROSCON 2014 conference. ROS two is not a new version of ROS, but a new promising approach, with different releases, that is much more prepared for the Industry than ROS 1.

Robotics and business evolution asked for new use cases that were not considered when ROS 1 was designed and were the reason of creating a new approach of ROS: ROS 2. Some of these use cases are, as described by Brian Gerkey, CEO of Open Robotics and former Director of Open Source Development at Willow Garage:

• Teams of multiple robots: while it is possible to build multi-robot systems using ROS 1, there is no standard approach, and they are all somewhat of a hack on top of the single-master structure of ROS 1. In the other hand, ROS 2 is designed as a distributed system for single or multiple robots, not depending on a Master and replacing the messaging layer to rely on DDS (Data Distribution Services).

• Real-time systems: we want to support real-time control directly in ROS, including inter-process and inter-machine communication (assuming appropriate operating system and/or hardware support). While ROS 1 is not designed for Real time, ROS 2 could work in real time while using RTOS. 

• Non-ideal networks: we want ROS to behave as well as is possible when network connectivity degrades due to loss and/or delay, from poor-quality WiFi to ground-to-space communication links. ROS 2 is designed for this approach while not ROS 1.

• Production environments: while it is vital that ROS continue to be the platform of choice in the research lab, we want to ensure that ROS-based lab prototypes can evolve into ROS-based products suitable for use in real-world applications.

WHAT ROS APPROACH THEN?

The rivalry may be more between ROS 1 and ROS 2, considering ROS-I definitely more for Industrial robots and manipulators.

I like the recommendation given on July 2019 by Dan Rose and Nick Fragale from Rover Robotics with help from Open Robotics:

Demographic	Description of user	Advice
Students	Those who are just learning to use ROS	Stick with ROS 1 for now. Many of the concepts in ROS 1 and ROS 2 are the same so learning ROS 1 will help you to learn ROS 2 later on.
Professors	Those teaching ROS	Keep teaching ROS 1 for now but start thinking about curriculum for ROS 2. There are many entities interested in helping to develop curriculum for ROS 2 including Rover Robotics so you don’t have to go at it alone
Researchers	Those using ROS to publish papers	Unless your paper is specifically to show off using ROS 2 our advice is to stick with ROS 1 for the time being.
Large Companies	Those who are in R&D groups funded by a large corporate entity	Strongly consider ROS 2 to reduce the amount of technical debt in the future. Put people with experience with ROS 1 on the project.
New Robotics Startups	Those who are thinking about starting a robotics company	Strongly consider ROS 2 to reduce the amount of technical debt in the future. Hire people with experience with ROS 1.
Existing Robotics Startups	Those working at a robotics startup that’s either using ROS 1 or not using ROS at all.	This is the hardest group to offer advice to. It really depends on where you are at with your startup. Keep an ear to the ground on ROS 2, at some point you will want to switch but it will be like ripping off a band-aid.
Robotics OEM	Those who make either robots, sensors for robots, or anything that needs a ROS driver	Now is a good time to switch. ROS 2 Dashing is the first LTS release so its now safe for OEMs to start porting drivers without fear of new features that will break functionality. Additionally we have seen large companies like Amazon, Intel, and Microsoft devote significant resources towards ROS 2 development.

COMPANIES USING OR SUPPORTING ROS

Some Companies Using ROS: NASA, BMW, Clearpath Robotics, Fetch Robotics, Pal Robotics, Robotnik, Yujin Robots, Robotis, Shadow Robot, Husarion, Neobotix, Gaitech, Sony, Ubiquity Robotics, Open Robotics, Rover Robotics, DJI, Infinium Robotics, etc.

ROS-I is supported by an international Consortium of industry and research members: ROS Industrial Consortium. ROS Industrial Consortium includes companies such as ABB, Airbus, Bosch, BMW, IFM, Intel, Pepperl+Fuchs, Siemens, Universal Robots, Yaskawa and much more.

-----
Reference:

• ROS Industrial Consortium Members
• Top 10 ROS-based robotics companies in 2019
• Opportunities for ROS in industries and research
• ROS-Industrial for Real-World Solutions
• ROS 2. Is it time to switch?
• Why ROS 2?
• Changes between ROS 1 and ROS 2
• About ROS
• ROS-Industrial, merging ROS and the industry
• ROS-Industrial oficial web page

ROS, for more than proofs of concept

It was not so far in time when I used to program robots using assembler language, a sort of machine code extremely close to the hardware of the machine. In those times programming a robot for complex functions, like navigating autonomously from one room to another was a difficult and time consuming project, that may take months for a team of people.

Robotics is evolving very fast as well as the open source movement. A really interesting outcome of both evolutions is ROS (Robot Operating System). ROS is an open-source, meta-operating system for robots, is a robotics middleware (i.e. collection of software frameworks for robot software development). It provides the services you would expect from an operating system, including hardware abstraction, low-level device control, implementation of commonly-used functionality, message-passing between processes, and package management. It also provides tools and libraries for obtaining, building, writing, and running code across multiple computers.

Nowadays it is possible to program a proof of concept for a robotics system in few days, thanks to ROS and all the open source, already available tools. Its integration with Gazebo Open Source Simulator is also a great help on the design and test of algorithms and behaviors.

Just as an example, let me share with you a development I did recently, using ROS. It took me about 10 hours to write on my own an application for a robot to work as a messenger, able to go to any room or location in a house  or an office to deliver goods. The function of the robot is very straightforward: You just put something on the tray of the robot and indicate in the touch screen where to deliver. Then the robot, using a 360 degrees laser scanner for detection of the environment and SLAM navigation technology, finds a trajectory to the required location. This development would have taken easily 6 months of work for a team of 5 people 10 years ago. Now you could have it in 10 hours of only one developer and with a hardware technology (robot platform, lidar, embedded computer) 

HERE you could also find all the documentation about the development of this solution.  In fact this documentation will be one of the chapter of my next book about ROS that I expect to publish soon.

But ROS is not only for developing a proof of concept, but real products for consumer and industrial market. I will talk more about it in future posts.

Thanks for the Open Source philosophy, thanks for the developers of Linux, the Open Source Operating System in which ROS works, thanks for all the hard work done by Willow Garage team for the development did of ROS and thanks to the incredible community of developers that share their knowledge and code for the Robotics evolution. This is the key factor of this time. We all are working to make the Robotics technology evolve, by sharing, for the art of sharing.

GIThub repository: https://github.com/aalonsopuig/MrMess_Robot.git

Reference:
[ Wikipedia. https://en.wikipedia.org/wiki/Robot_Operating_System ]
[ Ros.org http://wiki.ros.org/ROS/Introduction ]