Automation and Computers

Circuitos. Amplificador con transistor bipolar

noreply@blogger.com (Alejandro Alonso Puig) — Fri, 16 Jun 2023 20:17:00 +0000

En este capítulo vamos a profundizar en uno de los clásicos de la electrónica analógica: El amplificador en emisor común con divisor de tensión.

Se trata de un uso del transistor NPN en su zona activa con el fin de amplificar una señal pequeña. Base de amplificadores diversos, como los de audio.

Análisis teórico

El divisor de tensión formado por Rb1 y Rb2 polariza la unión Base-Emisor con una tensión

VB = VCC . Rb2 / (Rb1+Rb2) = 1.15V

Para que la base siempre esté polarizada, hay que tener en cuenta que la señal de entrada (Vin) se sumará a la componente continua (del divisor de tensión). Esta ha de superar la tensión de polarización mínima de la Base, incluso en valores pico negativos de señal de entrada. Es decir que:

VB + Vin(min) > VBE(on) + VE

Donde:

VBE(on) es la tensión base-emisor mínima para polarizar el transistor. Su valor está entorno a los 0.6-0.7V para transistores de silicio (los comunes)

Podemos estimar matemáticamente todos los demás valores de funcionamiento del transistor en reposo (sin señal de entrada Vin), lo que nos permitirá identificar la recta de carga y el punto quiescente:

VBE (tensión Base-Emisor) la podemos aproximar a 0.7v. Aunque implicará un error de precisión, en la mayoría de los casos nos permitirá obtener valores bastante aproximados.
VE (tensión de Emisor respecto de masa) es igual a VB - VBE = 1.15v - 0,7v = 0.45V
IE (corriente de Emisor) por ley de ohm es igual a VE / Re = 0.45v / 10Ω = 45mA,
IC (corriente de Colector) es igual IB + IE pero IB es muy baja (ver curva característica), por lo que se puede aproximar que IC ≈ IE = 45mA.
VRc (tensión en Rc, o entre fuente (VCC) y Colector) es igual a Rc . IC = 4.5V
VC (tensión de Colector respecto de masa) es igual a VCC - VRc = 4.5V
VCE (tensión Colector-Emisor) es igual a VC - VE = 4.05V

Volviendo al circuito:

Rc permite establecer (junto con VCC) la recta de carga estática, permitiendo calcular los puntos de corte y saturación. El punto Q de trabajo será la intersección de la recta de carga con el VCE calculado.
Re aumenta la estabilidad del amplificador, pero ha de utilizarse en paralelo con un condensador (Ce)
Ce es un condensador de desacoplo para atenuar componentes alternas y mejorar la estabilidad del amplificador
Ci y Co son condensadores de acoplo que eliminan la componente continua. Para ello han de elegirse de manera que su reactancia sea baja para las frecuencias utilizadas en el amplificador.
La gráfica siguiente muestra como es la respuesta frecuencial de la reactancia (XC) de Ci y Co en este amplificador de ejemplo.

Análisis en simulación

Para simular este amplificador, utilizaremos un circuito de pruebas para transistores BJT que he desarrollado sobre el simulador de Falstad.

Se puede acceder a la simulación del amplificador en este enlace: ENLACE

Poniendo el amplificador en reposo (desactivando la fuente de señal pero dejando la fuente de tensión), obtenemos valores

IB=384µA, superior a los 200µA para el punto Q calculado arriba,
IC=38.5mA, algo inferior a los 45mA calculados previamente
VCE=4.8V, algo superior a los 4.05V calculados previamente
VBE=690mV, similar a los 0.7V considerados previamente

Pareciera que o bien la simulación, o bien los cálculos son incorrectos, pero debe tenerse en cuenta que el transistor elegido en la simulación es un modelo genérico que no funciona exáctamente como el BC547 utilizado, por lo que los datos obtenidos son diferentes, pero orientativos.

Análisis empírico

El paso siguiente es montar el circuito y medir los valores anteriores, con un BC547 real, con el fin de comprender mejor el comportamiento del transistor.

Una vez montado el circuito, con el uso de un polímetro obtenemos los siguientes datos en reposo:

IB=137µA, muy diferente de los 200µA para el punto Q calculado arriba,
IC=38.5mA, algo inferior a los 45mA calculados previamente
VCE=3.9V, algo inferior a los 4.05V calculados previamente
VBE=690mV, similar a los 0.7V considerados previamente

Comparativa

Tenemos por tanto tres casos con resultados diferentes. ¿Cómo podemos fiarnos de la teoría o la simulación si difiere de la realidad?

Esta es una cuestión que nos lleva a algunas consideraciones importantes:

Una simulación solo puede acercarse a la realidad si los modelos de los componentes se corresponden con los utilizados en la realidad. En nuestro caso el BC547. Al haber utilizado un modelo genérico, es natural esperar diferencias, aunque eso no quita valor a la simulación como acercamiento al comportamiento del sistema.
Hemos asumido, por simplicidad, que VBE = 700mV en vez de 660mV del caso específico de este transistor. Para mejorar la precisión en este caso es recomendable inspeccionar el datasheet del componente para identificar mejor sus parámetros.
También hemos asumido, por mantener sencillo el ejemplo, que el voltaje resultante del divisor de tensión se mantiene constante (VB = 1.15V), pero esto no es así, porque al tener la carga del transistor, se produce una pequeña caída de tensión. Como consecuencia el valor real es VB = 1.12V. Esta diferencia, aunque es de solo 30mV, junto con la del punto anterior, de 40mV son fundamentalmente las causantes de las diferencias entre el modelo teórico y el empírico, aunque también hay otros elementos que influyen, como la temperatura del componente.

Visualización con osciloscopio

Hasta ahora hemos podido visualizar datos concretos con el polímetro, pero el osciloscopio nos va a permitir:

Ver y comparar las señales de entrada y salida, así como su distorsión
Visualizar el punto Q y la recta de carga, así como las zonas de corte, saturación y activa.

Para la visualización de entradas y salidas, disponemos las sondas de un osciloscopio de doble canal del siguiente modo:

Lo que nos permite ver la amplificación en tensión de la salida (señal roja o amarilla) respecto de la entrada (azul) y su desplazamiento en fase.

Otra interesante visualización es la de la recta de carga y punto Q. Para ello utilizaremos un osciloscopio de doble canal, que permita modo XY y lo conectaremos según se muestra a continuación. Es importante asegurarse que la tierra del osciloscopio no coincide con la masa del circuito amplificador para que esta disposición funcione.

Una de las sondas permite medir el valor de corriente IC (a traves de su relación con la caída de tensión en la resistencia shunt) y la otra sonda permite medir el valor de VCE (aunque invertida por tener ambas masas del osciloscopio compartiendo punto central, algo necesario porque dichas masas no están aisladas entre si) Por esto, visualizaremos la información como si aplicásemos un espejo vertical.

De esta manera, se muestra tanto el punto quiescente (Q) como la recta de carga en el cuadrante superior izquierdo del osciloscopio.

Distorsión de la señal amplificada

Finalmente podemos observar los efectos de la distorsión de la señal cuando entra en zona de corte y saturación.

Para ello no tenemos más que sustituir Rb2 por un potenciómetro y mover este para alterar la tensión sobre la base y por tanto su corriente IB, lo que desplaza la señal de salida por la recta de carga arriba y abajo. Esto es algo que observaremos tanto en el osciloscopio en modo XY como en el osciloscopio que nos muestra la señal de salida, ya que esta quedará distorsionada.

Concluímos así este análisis teorico-práctico del comportamiento del transistor bipolar en modo emisor común, para aplicaciones de amplificación.

Se muestra a continuación el vídeo explicativo completo.

Circuitos. Simulación de transistores BJT

noreply@blogger.com (Alejandro Alonso Puig) — Tue, 13 Jun 2023 14:03:00 +0000

Comienzo una serie de posts sobre circuitos electrónicos, en el que pretendo explicar, esta vez en español, el funcionamiento de algunos montajes, con una cobertura muy completa, que pasa por la explicación teórica, la simulación, el montaje y el análisis con instrumentación de laboratorio.

Hoy comenzaré mostrando una herramienta que considero de gran interés para la simulación de transistores BJT en modo emisor común. Se trata de un circuito configurable, que he desarrollado sobre el simulador de Falstad. Es un circuito que permite seleccionar múltiples entradas y salidas, así como múltiples valores para los componentes, con el fin de probar diferentes circuitos basados en transistores BJT. Permite además ver con detalle todas las señales que circulan por el circuito, así como la curva de entrada y de salida, pudiendo visualizar la recta de carga, punto quiescente y estados del transistor (corte, saturación, activo).

Con todo esto, podemos simular circuitos de amplificación, seguidores de tensión, circuitos de conmutación, etc. Una herramienta útil para comprender mejor el comportamiento del transistor y evaluar el comportamiento de circuitos basados en el tran
sistor bipolar.

Se puede acceder al circuito de simulación en este enlace: ENLACE

Además, en el siguiente vídeo se puede encontrar un tutorial se de funcionamiento.

AMR-One. 05 Project Management Plan

noreply@blogger.com (Alejandro Alonso Puig) — Thu, 29 Sep 2022 20:43:00 +0000

This is the fifth on the series of posts about the AMR-One Project. Today it is time to talk about what is a Project Management Plan, how to prepare it, and its application to the AMR-One project.

The Project Management Plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed.

But... we already talked about it in my previous post The Project Management Plan. But the important thing is how you prepare it and why. For that, I used the AMR-One Project example and prepared the following video that I hope you like:

Interview: Technological Startups

noreply@blogger.com (Alejandro Alonso Puig) — Wed, 31 Aug 2022 15:05:00 +0000

I was interviewed recently about challenges and recommendations for Technological Startups. Although the interview is in Spanish, I share with you the written translation of the interview in English. Also, the video may include English and Spanish subtitles if you like.

Click to watch the interview

Good morning Alejandro, On this occasion and taking advantage of your experience as an advisor to technology startups, we would like you to tell us a little about the challenges that a startup of this type faces.

A technology startup faces multiple challenges. Perhaps the most important of all is to understand the customer and the market, but there are of course many other challenges, such as identifying the right product or service, knowing how to shape and industrialize it, finding investment, correctly designing and executing the marketing and sales strategy, or just grow.

Could you give us some guidelines that a technology startup should take into account in its first steps?

The Market

The first thing is to select the market in which to operate. It has to be interesting, fun, and motivating for entrepreneurs.

You need to know the sector and the client very well. Do it first-hand, not just from third-party reports.

It is also necessary to take into account cultural, idiomatic, usability aspects, barriers, competitors, regulatory aspects, registered patents, etc.

The Product

On the other hand, there is the product or service. This must be focused on the client and their needs. In many cases, the form of the product is more important, that is, the contribution of value that the customer perceives from the product than the product itself.

It is recommended to start with a minimum viable product. In other words, to get basic results with the minimum investment in time and cost, that allow the product or service to be tested in the target market.

Sometimes the entrepreneur focuses on making a product with a very high technological contribution, investing too much time with its associated opportunity cost, when the priority may be to verify if the market is really willing to pay for that product or functionality.

One of the techniques that is usually recommended is that of "validated learning", which consists of testing assumptions about the interest of customers, aspects that we believe are important to them and perhaps not, and measuring our progress in some way, not by the sales made, but through learning, which is what brings us closer to finding what meets the customer's need or desire.

When Thomas Edison invented the light bulb, it did not work out the first time, but he made more than a thousand attempts, to the point that one of his collaborators asked him why he persisted in building a light bulb if after more than 1000 attempts he had not succeeded. Edison replied: They are not failures, I learned 1000 ways of how not to make a light bulb.

But you also have to know how to make the decision to persevere or pivot your strategy.

Escalability

The product or service must be scalable, that is, if it is successful, scale factors can be applied, such as offering more units to cover the market, creating accessories or adding functionalities.

There must be a multiplier factor that turns the startup into a money-making machine when the time is right.

Business Plan

A good business plan is a roadmap. You have to be honest and consider alternatives.

The plan must analyze all the critical aspects of the business: the market, the value proposition, the team, the marketing and sales plan, the growth plan, the financial plan,... and of course a Plan B in case things do not go as expected.

Financing

To obtain financing, a startup can go through crowdfunding processes, search for business angels, and many other investment models, but in order to access this investment, the business model must be prepared very well, demonstrate that the idea has passed a certain validation of the market, that it is scalable and that the correct team is available, not only technical but also experienced advisors who mentor and accompany the company not only in its initial start-up but also during its journey and growth.

We already know the Chinese proverb: "If you want to go fast go alone. If you want to go far go together".

AMR-One. 04 Work Breakdown Structure (WBS)

noreply@blogger.com (Alejandro Alonso Puig) — Tue, 30 Aug 2022 08:50:00 +0000

This is the fourth on the series of posts about the AMR-One Project. Today I will talk about the Work Breakdown Structure tool as a way to get the tasks of a project.

The concept

Once we have somehow the scope, requirements, or definition of what we are going to do, we could prepare the Work Breakdown Structure (WBS).

The Project Management Institute (PMI) PMBOK defines the WBS as a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.”

Basically is an iterative process that takes one large work product, and breaks it down into smaller, manageable work packages.

In a WBS such elements are the items that are estimated in terms of resource requirements, budget, and timing

WBS applied to AMR-One Project

In the case of AMR-One, I made a simplification of the process, aligning the Product Roadmap, the Requirements, and WBS.

So in the WBS I added all Initiatives from the Roadmap as L1, and the Features or Epics as L2. Also I added one column to define the version of the product where these Epics will apply.

WBS related to Roadmap and Requirements

I didn’t split it into more levels as in this way it is quite aligned with the requirements already defined.

Now from here, and having the architectural approach mentioned in the previous video, we could start identifying atomic tasks within each Epic. This is work to do with the technical team, identifying dependencies, resources, time, and cost estimation.

Epics decomposition in atomic activities

And that is all so far.

In the next post, I will explain to you how to prepare a good Project Plan. It is not only to have a plan of tasks, time, and costs. It is much more than that!

See the following video for more details:

Interview: AGVs and AMRs in the Industry 4.0

noreply@blogger.com (Alejandro Alonso Puig) — Sat, 30 Jul 2022 09:18:00 +0000

I was interviewed recently about what the AGVs and AMRs are, and why they are so important for the industry. Although the interview is in Spanish, I share with you the written translation of the interview in English.

click to see the interview (in Spanish)

Could you explain what automated intralogistics vehicles are and what they are useful for?

There is no doubt that the industry increasingly requires to operate in an automated way, otherwise, it could not serve the growing demand of the market, while reducing costs and improving the quality of the products and processes.

One of the ways to go in this direction is to use what are called automated intralogistics vehicles, which can move material completely unattended.

I'll give you two examples:

Case 1: Automotive manufacturing

The first example is in the automotive sector, where car assembly lines operate continuously and therefore require a constant flow of parts from what is called the kitting area, which is where the parts are located, to the assembly area. In this case, the automated vehicles deal precisely with this task without pause, communicating and interacting on their way with different elements of the factory such as doors, elevators, robotic cells, and even people if needed.

Case 2: Online Shopping

Another example is that of the orders we make online to Amazon, Zara, or Aliexpress, among others, in some cases with delivery times on the same day. This would be impossible without automation.

In this case, your order enters the web and from here it enters the supplier's order and warehouse management system. These systems are connected to a Fleet Management System, which manages the dozens or hundreds of automated vehicles that will pick up the products of your order and take them to the picking area, where the operator or even a robot introduces them into the box that then arrives at home.

In all this process there are a lot of technologies involved, such as artificial intelligence algorithms, perception systems, artificial vision, etc.

Could you briefly tell us about the difference between the two types of automated vehicles you mentioned: AGVs and AMRs?

AGVs, an acronym for Automatic Guided Vehicles, normally follow a band on the floor, which is like a road with forks. It is a very proven and very safe technology to drive the vehicle along fixed routes.

While the AMRs, acronym for Autonomous Mobile Robots, do not require these bands, using other sensors, such as laser scanners or artificial vision based systems and have a greater decision-making capacity, such as to avoid a person or decide the best route to reach a destination.

The important thing is to choose the technology that best meets the needs of the industry in each case.

AMR-One. 03 Architecting the solution

noreply@blogger.com (Alejandro Alonso Puig) — Fri, 29 Jul 2022 10:00:00 +0000

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. 02 Product Requirements

noreply@blogger.com (Alejandro Alonso Puig) — Mon, 13 Jun 2022 14:02:00 +0000

Today I will talk about "Product requirements”, from a conceptual point of view, and how they have been handled under the AMR-One Project, where an autonomous mobile robot for the industry is developed.

The concept

Requirements Engineering is one of the processes of Systems Engineering, that is focused on defining, documenting, and maintaining requirements.

In the Waterfall Model, requirements engineering is presented as the first phase of the development process while Agile Methodologies, like Scrum, assume that requirements engineering continues through the lifetime of a system.

Basically, a requirement is a singular documented need that a particular design, product, or process must be able to perform.

Once all stakeholders are aligned, the requirements serve as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

The steps

The steps to follow with the requirements are in summary:

Eliciting and expressing requirements (getting the Requirements from the client)
Prioritizing requirements, for example in the form of:

Must be done
Should be done
Could be done

Analyzing requirements to ensure they are complete, clear, and consistent
Analyzing also requirements from the technical point of view to ensure they are feasible in terms of time, cost and execution.

Types of requirements

When defining requirements it is good practice to cover several types of requirements, like:

Business requirements (Define why the product is needed)
Business rules (budget, policies or regulations, brand uniformity requirements,…)
User Requirements (what tasks the users can do with the product)
Functional Requirements (describe what the product should do)
Non-functional Requirements (describe how well a product must perform)
External interfaces
Physical settings
Development constraint

In the following video, you could see this more in detail and how requirements are applied to the AMR-One Project, where an autonomous mobile robot for the industry is developed:

AMR-One. 01 Product Strategy and Roadmap

noreply@blogger.com (Alejandro Alonso Puig) — Tue, 17 May 2022 08:09:00 +0000

This is the first on a set of posts about the project AMR-One.

AMR-One Project's scope is the development of an autonomous mobile robot for the industry. The set of posts covers not only the technical part but also project management and strategic concepts.

In this post we will mention the strategic part of the product, talking about the Product Strategy and Product Roadmap.

A Product Strategy is a high-level plan that defines your product goals throughout its life cycle and how it will support the organization’s goals. The product strategy will also answer who the product will serve and how it will benefit them.

These plans are then brought to life on the roadmap.

A Product Roadmap is a plan of action for how a product or solution will evolve over time. Product owners use roadmaps to outline future product functionality and when new features will be released.

To build a roadmap, product owners should consider market trajectories, customer value propositions, strategic goals, and effort constraints. Once these factors are understood, the product owner can work with their team to start prioritizing initiatives and epics on the roadmap.

The roadmap should be updated as often as necessary so that it can remain an accurate source of truth.

Having that roadmap we should go ahead with the Product Lifecycle Management, which is the process of managing the entire lifecycle of a product from its inception through the engineering, design, and manufacture, as well as the service and disposal of manufactured products.

See my previous post: 5 tips on ... Product Strategy & Product Roadmap

See the following video on how these concepts are applied to the AMR-One project:

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

noreply@blogger.com (Alejandro Alonso Puig) — Sun, 15 May 2022 13:52:00 +0000

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

noreply@blogger.com (Alejandro Alonso Puig) — Mon, 02 May 2022 14:00:00 +0000

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

The Project Management Plan

noreply@blogger.com (Alejandro Alonso Puig) — Mon, 04 Apr 2022 16:47:00 +0000

[3 minutes reading]

The Project Management Plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed. In my previous post I explained the early steps before preparing it.

I would say that one of the most important keys to preparing a good Project Management Plan is to understand why this document is needed and how it could really help the success of the project.

This document, as mentioned at the top of this post, describes the rules for the execution of the project. We need to understand that in a project there might be many people involved and many phases to execute. It is key to have a common point of understanding of the rules for the management of the project, so anyone could read them when needed. Rules could change of course, but always under some kind of control.

Source: PM illustrated

The Project Management Plan could include the following important sections and components:

Scope management plan. Establishes how the scope will be defined, developed, monitored, controlled, and validated.
Scope baseline. The scope baseline provides the project and product definition.
Requirements management plan. Establishes how the requirements will be analyzed, documented, and managed.
Project life cycle description. The project life cycle determines the series of phases that a project passes through from its inception to the end of the project.
Development approach. The development approach defines whether waterfall, iterative, adaptive, agile or a hybrid development approach will be used.
Schedule management plan. Establishes the criteria and the activities for developing, monitoring, and controlling the schedule.
Schedule baseline. The schedule baseline is used to assess the impact of the changes in the project schedule.
Cost management plan. Establishes how the costs will be planned, structured, and controlled.
Cost baseline. The cost baseline is used to assess the impact of the changes to the project cost.
Quality management plan. Establishes how an organization's quality policies, methodologies, and standards will be implemented in the project.
Resource management plan. Provides guidance on how project resources should be categorized, allocated, managed, and released.
Communications management plan. Establishes how, when, and by whom information about the project will be administered and disseminated.
Risk management plan. Establishes how the risk management activities will be structured and performed.
Procurement management plan. Establishes how the project team will acquire goods and services from outside of the performing organization.
Stakeholder engagement plan. Establishes how stakeholders will be engaged in project decisions and execution, according to their needs, interests, and impact.
Change management plan. Describes how the change requests throughout the project will be formally authorized and incorporated.

Not all these sections are mandatory. Of course, tailoring practice depends on the kind of project and complexity, company culture, and other factors. But in general, I consider it good practice to have all of these sections included as they cover most of the key important aspects of a project.

---

Bibliography:

Before starting a Project

noreply@blogger.com (Alejandro Alonso Puig) — Tue, 01 Mar 2022 17:59:00 +0000

[3 minutes reading]

So you have a nice corporate Products Roadmap (see my previous post 5 tips on ... Product Strategy & Product Roadmap) that includes the products that will help your business succeed. Now let’s start with its execution, step by step.

These steps are defined in the phases that compose the project life cycle (not the product life cycle). In this case, I will consider how PMBOK groups these phases.

There are some initial steps that are quite common in all kinds of projects, even if they use Linear Process models or Iterative Process models (see my previous post 7 tips to choose a Methodology for Software Development):

Source: Project Management Body of Knowledge (PMBOK) seventh edition

Pre-Project Work

This phase is where we should evaluate in some detail the real business need of the project and the estimation of the costs through the preparation of the Business Case document. It might be a very detailed study or just something simple and quick depending on the project, but is something key to work on. It is not uncommon to find companies that jump from the corporate Products Roadmap (if they even have one) to the project execution, and this directs them to big holes of investment in projects with no clear ROI.

A Needs Assessment often precedes the Business Case. The Needs Assessment involves understanding business goals and objectives, issues, and opportunities and recommending proposals to address them.

The project Benefits Management Plan is the document that describes how and when the benefits of the project will be delivered and describe the mechanisms that should be in place to measure those benefits.

Starting the Project

So we have this Business Case that gives us some understanding of where we are investing the money from the company. Well, the next step is to prepare a Project Charter. This is a formal summarized document that includes the following information:

Project purpose;
Measurable project objectives and related success criteria;
High-level requirements;
High-level project description, boundaries, and key deliverables;
Overall project risk;
Summary milestone schedule;
Preapproved financial resources;
Key stakeholder list;
Assigned project manager, responsibility, and authority level; and
Name and authority of the sponsor or other person(s) authorizing the project charter.

This document is approved by the Project Sponsor and when it is signed, gives the Project Manager full authority to start the project.

Many people see this document as “another boring document that the bureaucracy of the company demands” but this is not at all that. It is a key document to understand the whole key elements of the project from the management standpoint. Without it, management might take decisions without enough global vision of the project.

Once the Project Charter is approved I recommend going ahead with a kickoff meeting. It is the first meeting with the customer or sponsor and the project team, to give a vision of the project. Many companies do not pay enough attention to this meeting, but it is crucial for the success of the project as we will involve the team in the project from the beginning. This will help identify risks and help in the planning process.

Organizing and preparing

Here is where the Project Management Plan is prepared. The project management plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed. It includes all the rules of the game of running a specific project, including the methodology we would like to follow.

This part is so important that I will dedicate my next post to this subject, so I see you then!

---

Bibliography:

5 tips on ... Product Strategy & Product Roadmap

noreply@blogger.com (Alejandro Alonso Puig) — Wed, 02 Feb 2022 18:02:00 +0000

[5 minutes reading]

Product Strategy defines what your product should achieve and how that supports the organization, and is brought to life through the product roadmap.

A Product Roadmap is a high-level summary that shows the vision and direction of your product offering over time. It is a key strategic document as well as a plan for executing the product strategy.

Clearly, both are key for a product-focused company, and many books, posts, videos, courses talk about it. Here I will just share with you a few key tips that I learned from my professional experience in the software and automation business. I wish these tips will help you to get a successful business.

Tip 1. Product strategy and roadmap should support market needs. It is sooooo common, especially for small companies, to focus on what they want to do and not what the market wants to use and pay for! This is a very common mistake and might put at risk the survival of the company. Recommendation: Base your decisions on market analysis, conversations with customers, demo prototypes, proofs of concept, or even sales experts' gut feelings, but consider the customer needs, not your desires.

Tip 2. Your customer is your mate. Many companies just see customers as the people or companies that pay for their products, but customers should be seen as colleagues, mates to ensure we build a win-win relationship with them. Otherwise, customers will come and go, because they will see you in the same way, as the supplier of something they just need at that moment. Recommendation: Work with the customers in the definition of your roadmap, not just getting their inputs, but involving them in an evolving adventure to have products that will help them as well as you.

Tip 3. A roadmap might be flexible, but not too much. A Roadmap is a guide for the whole company. It might be used by the sales department to advance future products to the customers, or by the development team to plan resources, or by the finance department to prepare treasury plans. Some companies tend to adapt the roadmap depending on the commercial opportunities and customers. Roadmaps should have some flexibility to adapt to changing circumstances, but too many changes produce confusion in the organization. Recommendation: Define a Roadmap. September is an adequate moment, so resources could be allocated for the new year, although any time of the year is good if you do not have one. Once you have that roadmap, evaluate the risks and impact of any change you might want to do before applying it.

Tip 4. Pay attention to the cost of building a product. Many companies consider that a product costs what it is needed to make it in terms of time and resources, but it is not. There are many other costs related to a product that should be considered from the beginning, like integration testing phases, standardization and industrialization, proofs-of-concept (POC) with customers, documentation, rules compliance (like CE, etc), demos, internal training, and something that many times is not considered: Maintenance. Because there might be bugs, improvements, design mistakes that will need time and resources, especially in a new product launch. Recommendation: Plan considering all the phases of a product life cycle, not only on the few first ones.

Tip 5. Give a good product or you will lose the good customer. Quality, quality, quality. This should be a must in any product and many times is not so. The rush to have a product in the market means many times reductions in the validation and industrialization phases. Recommendation: I know it is a trade-off not always easy to solve. The key is to take a strategic decision, planning in advance the time and resources to ensure the product is good enough for the market. Be agile in the execution and reduce functionalities if needed, but not reliability.

As you could understand, product strategy and product roadmap are very serious strategic decisions. Good practices will not always ensure success, but bad practices will definitely make the company fail. So let’s pay full attention to do it well.

I recommend reading this post: What is the key to get a successful product?

Work with external developers! Seriously?

noreply@blogger.com (Alejandro Alonso Puig) — Fri, 23 Apr 2021 11:28:00 +0000

[5 minutes reading]

We are in a very fast technological world, where we need to surf over the waves all the time. As companies, we need to give more and more added value to customers, not to beat the competitors, but to help customers with better solutions, that also help them to be better productive companies.

To do so, many companies only look at their internal resources and try to do everything on their own, instead of looking for other companies or freelancers to help them. This usually happens due to some incorrect assumptions:

Our product is "secret” so my intellectual property is at risk if I use external developers. WRONG!
No one understands our products except our employees. WRONG!
The cost of working with external developers is too high. WRONG!
I will later have dependencies on external developers for maintenance. WRONG!
…and many other

Some others think in the opposite way, but sometimes with wrong considerations:

Incorporating external professional resources will give as fast results in a short time. WRONG!

The reality is as follows:

In many cases, companies do not have the capacity to overcome all the developments needed, and therefore, or they delay deliveries, or lose market opportunities.
In most cases, it is possible to fragment developments in parts, modules, or services, so internal people could focus on the core "secret intellectual property" parts and external developers could work on the rest.
You have to focus on doing well what you do well. If you want to be on everything you will lose focus and opportunities
Using good external developers, even being more costly than internal resources, in the end, could be less costly because you may use your internal resources for other more valuable developments and external resources, in the long run could do the work faster.
Working with external developers as part of a team helps your internal resources to learn from the external developers and do a smooth technology transfer while development is done, so no dependencies will later exist from external developers.

So, externalizing development is a good option, but you need to have some extremely important considerations, especially when you start working for the first time in this way:

The external development service most of the time requires very clear requirements, usually more detailed than the ones you might use internally, because they do not know many internal assumptions you usually have, due to your knowledge of your products. So consider it will take time from your side.
Set clear short-time deliverables, in an agile manner. This will allow getting results and integrating them into your product soon.
Set weekly meetings with the external developers, to follow up on progress. This meeting is not to make pressure, but to help the external service to have a clear common understanding during development.
Encourage your team to work frequently with your external developers during the development process and involve them in the testing phases. This is an investment of time from your resources that will give you two things: a) smooth knowledge transfer of the guts of the development for future maintenance, b) help your team to learn from other professionals.
But there is probably one of the most important things you have to consider: Having external development services is an investment, not a one-time work. The first time you work with an external service, it will take you time, effort, and money just to help them understand your projects, your standards, your methods, your products, and learn to work together as a team, so do not expect fast and cheap results in the first work. But, this investment in time, money, and effort will greatly help you in subsequent works asked for the same development service. They will work with you like one, already knowing your team, your expectations, your product, your culture, your standards, processes, and methodologies. This is when you really start getting the fast and good delivery, worthing the effort, time and money spent in the past. This is what the graph at the beginning explains.

In the end, it is more a strategic decision than a quick-fix solution for internal capacity problems. Working with external developers, before you have serious capacity problems will help to be prepared for the peaks and valleys that will come.

Why demos are like demons for developers?

noreply@blogger.com (Alejandro Alonso Puig) — Sun, 21 Feb 2021 11:43:00 +0000

[5 minutes reading]

If your team of developers consider demos are a stressfull waste of time that delays development, then you may have an issue that this post could help to solve.

Some weeks ago, a robotics engineer working for a company in Singapore shared to me his concern with his boss, who was asking for a weekly demo to potential customers of an uncomplete prototype. This is quite a common situation and the reason why I decided to write this post.

It is clear that demos are key for a business success. Having customers and stakeholders involved in demos gives them not just a way to evaluate a product, but also a living experience. We are rational, but also emotional. Demos should also touch the rational and emotional inside of the audience. But why developers think demos are demons conspiring against development?

Sometimes because demo preparation takes long, as reinventing the wheel every time.

other times because it involve the same developers and the team do not see them as an opportunity to get good feedback for development and business.

and many other, the product or prototype is not properly tested and mature for a demo, so the stress of developers for a highly probable demo failure is too high

But really there are really good things we could do about demos. Let me tell you some key actions I recommend to follow:

Have clear requirements of what the demo should do. These requirements usually are a subset of the product requirements and will give clarity on what features will be part of the demo.

Prepare a demo as much standard and automated as possible, so it could be executed with minimum amount of supporting people. This reduces cost of demo and transmit simplicity to the audience.

Prepare a written Demo Plan, describing roles of people involved in the demo, what should they do, in what sequence, describing the preparation of the demo, the execution and the post-demo actions.

Keep always one unique interlocutor for each demo, who would give turns to others to clarify specific points of the demo if needed.

Before doing a demo, ensure the features have been tested properly and a rehearsal of demo is done.

Share with the development team clear reasons why demos are important and a good way to test, learn and correct features, as well as for the business.

Rotate the responsibility of doing a demo between different people, so they could learn and dilute stress between each other. Consider also doing demos with sales or product management team instead of developers as main executors of the demo, may be with a developer as support in case of doubts. This shows simplicity to audience and usually sales and product management people are more adequate for communication with customer than developers.
If your company requires doing demos with developers, take care of the amount of demos a developer does. Usually, developers need to develop and could understand dedicating part of their time for demos, but too much time doing demos and low time developing may demotivate them.

Give clear expectations to the audience. I saw many times failing demos of products, with the promise to be mature products when they were really prototypes in alfa version. Being sincere to the audience on what you are showing will ensure adequate expectations and prevent deception and stress if something wrong may happen. Anyone could understand a failure if they know is an alfa/beta version but not if they believe it is a finished product.

At the end demos are important and necessary for a company success. The way we prepare and do demos will directly influence the mood of the people involved in the demo and the experience of the potential customers.

Robotics Museums. A seed for passion

noreply@blogger.com (Alejandro Alonso Puig) — Sun, 24 Jan 2021 14:26:00 +0000

[3 minutes reading]

A good museum is not only a way to keep the history of our human evolution, but also could be an opportunity to discover inner passions. Also good Temporary Exhibition, Shows and Fairs are interesting ways to see more actual works.

Few weeks ago I visited The Robot Museum of Madrid (Spain) managed by my friend Daniel Bayon. In this museum I have since 2017 several of the robots I worked on, like Sam, Melanie and Retrobot among others.

This was not only a good opportunity to meet my friends and robots, but also to see again the collection this museum is offering. Some of them from the 80's that reminded me my origins in this passionate world.

From left to right: Daniel Bayon, Angel Hernández and Alejandro Alonso

Museums solely dedicated to robotics are not common yet. More common are the temporary exhibitions in different science museums around the world. Many times this exhibitions (either temporary or permanent) are linked to activities for kids related to STEM and robotics/programming workshops. Particularly I see it interesting, because the changes usually comes from the young people and interestingly, more and more is happening that young people, specially in STEM disciplines, wants to work only on what motivates and passionates them, not having any fear to loose a job if they don't like it.

It is anyway not so easy, in one part because sometimes there are not enough job offers in what people loves, but other times is because people do not find their inner passion. Fortunately Robotics is one of those professions that are more and more offering good profesional opportunities. If we could unveil their passion at least for those who has robotics in their heart, then we will help the world to have a change done by passionate people and not just by workers.

Robotic museums around the world

This is a list of museums that I either visited or know they have at least a permanent section related to robotics. If you know more, just let me know and I will add to the list. Most of them are nowadays temporary closed due to Covid-19

Europe

The Robot Museum. (Madrid, Spain)
Tekniska museet. There is a permanent Robot Zone in this museum. (Stockholm, Sweden)
Science Museum Leonardo Da Vinci. It has a permanent section Robotics and Biotechnology (Milan, Italy)

USA

American Computer & Robotics Museum. Founded in May of 1990 by visionary collector George Keremedjiev. The museum exhibits span 4,000 years of human history, from original cuneiform tablets to the first personal computers, and include topics such as Artificial Intelligence, Quantum Computing, the Space Race, Cracking the Enigma Code, and more. (Bozeman, MT, USA)
Carnegie Science Centre. It has a permanent exhibition called Roboworld. (Pittsburgh, PA, USA)
MIT Museum Robot Exhibit. (Pittsburgh, PA, USA)
Computer History Museum. This museum, although devoted mainly to computers history, opened a permanent gallery on 1987 devoted to Smart Machine. (Mountain View, CA, USA)

Asia

Miraikan (Japan). With a permanent exhibition of robotics
Robotics Museum Expected to open in 2022. (Seoul, Korea)
Suzhou Robot Museum (China)
Robotics Park (India)

Temporary Robotics exhibits

What is more common is to have temporary exhibits about robotics. Usually most of the Science Museums have this kind of exhibition, usually once every one or two years. Just to mention here are some of the past exhibitions done in some of these museums. Clic on the museum links below to access to those past robotics exhibitions:

MIT Museum (Cambridge, PA, USA), Science Museum (London, UK), Science + Industry Museum (Manchester, UK), Museum of Science & Industry Chicago (Chicago, IL, USA), Science Museum Group (UK), Vitra Design Museum (Germany), National Museum of Scotland (Scotland), V&A Dundee (Scotland), Hong Kong Science Museum (Hong Kong)

My Compact Lab briefcase. Ideas for Christmas gifts?

noreply@blogger.com (Alejandro Alonso Puig) — Sun, 13 Dec 2020 16:27:00 +0000

This is not my usual kind of post, but a friend told me it would be a good idea to share details of my compact lab briefcase, as may give ideas for gifts in these Christmas days.

First, I have to say that in the deep of my heart I feel I am a Maker Geek. I love Software, Electronics and Mechanics and over all that, I love making things covering these three disciplines, mainly in the field of automation and robotics.

During these last few years, I have been collecting items slowly to have a portable briefcase [Shop] that I could carry anywhere. The objective of this post is to give you details of all items and where to buy them if you like.

Picture 1

Here you will find all items sorted by groups, with reference to the locations in following pictures and links to manufacturers or online shops.

Electronics Instrumentation

Instrumentation is a collective term for measuring instruments that are used for indicating, measuring and recording physical quantities.

Multimeter (Picture 2, Item 1). [Shop] Commonly they are used to measure voltage, resistance and current, although defending on models you may measure transistors, diodes, capacitance, frequency and other. This is the most basic device in electronics.
LCR meter. If your multimeter do not have the functionality to measure inductance, capacitance and resistance with precision, you may need an LCR. In my briefcase I got a small measuring tool (Pic. 2, Item 2) for detecting inductances, capacitors, resistors, diodes, triodes, NPN and PNP transistors, N-channel and P-channel MOSFETs, IGBTs, JFETs, triacs and other components. [Shop].
Digital Tweezers. (Pic. 2, Item 3). [Shop] This is usually is a sort of multimeter with the shape of a tweezzer, very specific to measure SMD components. In my case mine measures Inductance, capacitance, resistence, diodes, voltage, but also frequency and could generate functions (sine, pulse, noise and custom made). You could see my video about this device here (VIDEO)
Oscilloscope. This is one of the most useful instrumentation devices in a laboratory. In my case I have two devices covering this function: a pocket size 2 channel 1Mhz, 10MSa/s Miniware DS212 unit that also has waveform generation capabilities (Pic. 2, Item 4). [Shop] (VIDEO) and a USB BitScope BS10U with active logic probes (Pic. 2, Item 4). [Shop] (VIDEO) that connected to a laptop and using an includes sw gives a bunch of good functionalities: 2 channel 100Mhz, 40 MS/s oscilloscope, waveform generator, 8 channel logic analyzer, protocol analyzer and an RF & Baseband Spectrum Analyzer.

Picture 2

Frequency meter: is an instrument that displays the frequency of a periodic electrical signal. It is used fo testing radio equipment, measuring vibration, strain, transducers... In my case this functionality is included in the Items 3, 4 and 5 of Pic. 2 although there are many bench specific devices for this purpose.
Arbitrary Waveform Generator (AWG): This tool produces waveforms that can be injected into a device under test and analyzed as they progress through it, confirming the proper operation of the device or pinpointing a fault in it. Also, user defined signals could be defined. In my case this functionality is included in the Items 3, 4 and 5 of Pic. 2 although out of this briefcase I have a portable JDS-2900 [Shop]
Logic Analyzer: Is an electronic instrument that captures and displays multiple signals from a digital system for an analysis based on states, timing and so on. In my case this functionality is included in the Item 5 of Pic. 2. There is anyway a pocket size logic analyzer I tested recently: The Miniware LA104 [Shop] (VIDEO)
Protocol Analyzer: This device is used to analyze communication protocols between devices. I use protocol analyzer mainly for CAN, RS232, I2C, SPI. In my case this functionality is included in the Item 5 of Pic. 2
Spectrum Analyzer: While an oscilloscope gives a visualization of signals in a time domain, a spectrum analyzer gives that visualization in a frequency domain. It means that the display of a spectrum analyzer has frequency on the horizontal axis and the amplitude displayed on the vertical axis. Very useful for frequency filters and RF based devices analysis. In my case this functionality is included in the Item 5 of Pic. 2
Other: Depending on your specific needs you may use other devices like a datalogger, current clamp, EMC and EMF Measuring Instrument...

Power Supplies

A power supply is an electrical device that supplies electric power to an electrical load.

Fixed Power Supply: These are the common power supplies we may find at home that supply a specific voltage with no control on current in specifications. In Picture 3 below we find a common 12v 3A Power supply with Barret connector (Item 6), 2A USB Power supply (Item 8) with several cables from USB-A to USB-B, MiniUSB-B, MicroUSB-B, USB-C, sometimes connected via a USB hub (Item 9) with 4 ports or more.
Adjustable Power Supply: There are from the simplest ones that only allow controlling the voltage, to programable power supplies that could be controlled form external devices. The most common electronics power supplies can control both voltage levels and current limits, very convenient when you want to limit the current while testing. In my briefcase I have an extremely portable Digital Power Supply. It is the Miniware MDP-XP (Item 7) [Shop] (VIDEO) that could control voltage and current (up to 30V/5A) from a wide input source (DC4.2V-30V). It also includes a display where actual current draw graphs could be visualized.
Batteries: They allow powering devices when you do not have a power outlet available. In my case I found most useful to have an 8000mAh, 5V/2A Power Bank (Item 10) [Shop].

Picture 3

With the USB power supply or the 12v/3A fixed power supply, I could power any device from my briefcase if needed, although most of them already have batteries integrated. If I need to use any of them in a place where no power outlet is available, I may use the power bank + adjustable power supply or an adapter to the car lighter.

Soldering tools

They help soldering of electronic components, cables and other stuff.

Soldering Station: consists of one or more soldering tools connected to the main unit, which includes the controls (temperature adjustment). In my case, in order to save space, I got the Miniware TS100 60W soldering iron (Pic.4 Item 48) [Shop] with temperature control (100℃ - 400℃) with 12-24v input.
Heat Gun: is a device used to emit a stream of hot air, usually at temperatures between 100 °C and 550 °C. They are used in electronics to desolder and rework surface-mounted circuit board components, but also used for shrinking tube (Item 43), functional testing of overheat protection devices, in order to safely simulate an overheat condition. Usually they are bulky devices, being the smallest one I found the electric Tacklife [Shop] and the gas Ancor [Shop], but in order to have something ever smaller I decided to take a gas one (Item 49) with deflector [Shop]
Blowtorch: This tool produce a flame from butane gas. For that purpose I use a small one (Item 49) with the proper adapter. With it's side could melt some low temperature metals properly and help curving plastic parts.
Other Soldering and Desoldering tools: Many other tools are needed like Tin lead solder wire (Item 47), Tip tinner (Item 45), Lighter (Item 46), Several soldering tips (Items 40), Cooper mesh for desoldering (Item 42), Desoldering suction pump (Item 44), SMD removal kit (Item 39) [Shop] and a small 10x eye magnifier (item 38) [Shop]

Picture 4

Electronic components and breakouts

It is quite convenient to have electronic parts, breakouts, cables, connectors, and any needed stuff to do your own projects wherever you go.

Electronic components: Most common are fixed and variable resistors, capacitors, diodes, inductances, leds, voltage regulators, switches, push buttons, connectors, operational amplifiers and some other integrated circuits, but it really depends on the kind of projects you may be focused on. (Picture 5, Item 12)
Prototyping power breadboards and protoboards (Item 15. top)
Breakouts: Again, it depends on what you do. I do mostly digital electronics, so common breakouts in my case are digital level conditioners, motor drives, relays boards, USB to TTL/RS422/CAN converters, displays... (Item 15)
Simple-board computers (SBC) or Single-board microcontrollers: These programable boards (Like Raspberry-PI or Arduino) are really useful for processing and treating signals as you want. In my case I always go with an Arduino board because it gives me a quick and easy way to create programs on the go to test communications, generate signals, and so on. (Item 15)

Picture 5

Cables and connectors: Picture 6 below shows not only cables that I may use on electronic devices (Item 51) but also for prototyping (item 50) with breadboards and testing (Item 52)

Picture 6

Hardware and other tools

This really depends on how much you have to do in this part, but for me the most basic elements for a maker (that could fit in a briefcase, remember!) are as follows:

Screwdrivers of different types (Pic.5 Item16), (Pic.7 Item 19, 20 and 31)
Minidrill (Item 29) [Shop] with several bits, cutting disks and sanding bits (Pic.5 Item 14)
3D Printing Pen (Item 28) very useful to repair ABS and PLA broken parts that you manufactured with your bench 3D printer or to create small parts on the go. The smallest I found is the RP900A [Shop]. Some PLA and ABS filament is needed (Pic.5 Item 17)
Third hand with magnifier and light: This is so useful! I got the Toolour model that I stored in the first compartment (Pic.1) [Shop]
Other common tools: Cutter (Item 22), Tweezers (Item 23), 3 colours pen (Item18), wire-stripper (24), protractor (25) several metallic rulers (Pic.7-Item 26 and Pic.1), Calliper (Item 27), Scissors (36), headlamp (Pic.5 Item 13), Nuts and bolts (Pic.5 Item 11)....

Picture 7

In Summary

With this briefcase I feel the liberty to continue doing makers stuff at any moment, wherever I go without carrying big boxes full of things.

I hope you get some ideas for this post to cover your needs or get nice gifts for people that matters to you!

Alejandro Alonso

Safety Systems for Mobile Robots

noreply@blogger.com (Alejandro Alonso Puig) — Thu, 23 Apr 2020 20:41:00 +0000

Reading Time: 4 minutes

A Mobile Robot should be safe, not colliding against people or goods as a result of potential failures. In order to ensure this is possible, Safety Systems should be able to control the movement of the Mobile Robot even if the Main System fails. A Safety System may allow the Main System to try to avoid an obstacle, but if the Mobile Robot gets dangerously close to the obstacle, the Safety System may stop directly the motors, overriding the control from the Main System, although informing to it.

This short post gives a quick overview of what are Safety Systems for Mobile Robots and why they are so important.

Safety Standards

In order to make the Mobile Robot system safe, there are some safety standards. To comply with these safety standards, Mobile Robots must include some safety sensors and devices to avoid and prevent risks

AGVs (Automated Guided Vehicle) are a specific set of Mobile Robots for Industry, able to perform specific tasks usually critical for production. This kind of Mobile Robots have very specific mandatory standards to follow:

AGV safety standards in the USA are defined by ANSI B56.5 - 2012, Safety Standard for Driverless, Automatic Guided Industrial Vehicles and Automated Functions of Manned Industrial Vehicles.
AGV safety standards in Europe are found in EN1525: 1997 “Safety of industrial trucks – Driverless trucks and their systems”

While both safety standards are important, there are gaps that fail to cover some of the latest technology. As mobile robots become more autonomous, correct their path while in motion, and gain new features and functions such as robotic arms, new safety standards are required. One of the most promising safety standards for new technologies in Mobile Robotics is ANSI/RIA 15.08 – Safety Standard for Industrial Mobile Robots and Mobile Manipulators – (in progress)

Safety Devices

A safety system as defined in the safety standards mentioned may require one or more safety elements. Typical Mobile Robots Safety devices are:

Safety Laser scanner
Contact Bumpers for stopping Mobile Robots (Quite uncommon nowadays)
Emergency Stop Buttons
Safety PLC

The different safety devices could be used together, usually controlled by a Safety PLC, as it is shown in the following image of a typical Mobile Robot safety system: Two safety laser scanners, two safety stop buttons, motor encoder and motor brake, all connected to a Safety PLC. In this kind of system, the safety PLC could know the speed of the Mobile Robot and activate different laser detection fields. Also, could stop the Mobile Robot activating the motor brake in case an emergency stop button or in case the laser scanner detect an object in the protective field. Usually Safety PLCs are connected to other systems that control the kinematics and behavior of the Mobile Robot. This other system could reduce the speed of the Mobile Robot in case the laser scanner detects an object in the warning field, so the Safety PLC informs this other system in such case.

Typical integration of safety system in a Mobile Robot. Source: Sick AG

This post just gives a general overview of Safety Systems. If you want more information about Safety Systems implementation, I would recomend you to read the thirteen pages document "Safety Systems for Mobile Robots" I prepared.

----
Reference:

AGV Network. Understanding AGV Safety Systems
Robot Safety Standards for Industrial Mobile Robots. RIA, Robotics Industries Association. 2017.
EN 1525
ANSI B56.5
EN ISO 13855
S300 Safety laser scanner operating instructions. SICK AG.
Keyence. Safety Laser Scanner SZ Series Manual
What Are Safety PLCs. Huffman Engineering. 2017.

Cloud Computing for our exponential world

noreply@blogger.com (Alejandro Alonso Puig) — Fri, 28 Feb 2020 14:09:00 +0000

4 minutes reading

National Institute of Standards and Technology defined Cloud Computing in 2011 in the NIST Definition of Cloud Computing document, telling us about three types of Cloud-based Service Models: IaaS, PaaS and SaaS

We could compare these models with a full On-Premises model (Traditional IT):

IaaS (Infrastructure As A Service): Where the provider offers the infrastructure, so you do not need to pay attention to this part and focus on the relevant parts of your solution.
PaaS (Platform As A Service): The provider offers you up to the Runtime level. It means that you have ready an environment where the infrastructure, O/S, middleware and runtime are all available and you focus on your data and applications. An example of this may be AWS Robomaker, where you could have all the infrastructure, plus the O/S (Ubuntu xx.xx for example), plus a middleware (ROSx), plus the runtimes needed, simulators, etc. so you focus on programming using the full created environment. See my previous post about AWS Robomaker
SaaS (Software As A Service): The provider offers the full solution for you. An easy example is Gmail

From 2011 Cloud Computing has evolved a lot and NIST document, although still correct in its foundations, may require to cover a bit more on the complexity that nowadays cloud has. Anyway is still a good document to understand Cloud foundations.

There are many providers of solutions for one or more of the service models mentioned. The most known ones are Microsoft (Azure), Amazon (AWS) and Google (Google Cloud) at least for IaaS and PaaS although there are others like IBM Cloud and Oracle Cloud that worth to mention.

More and more companies are using these cloud-based services to offer as well other XaaS (“Anything As A Service), From RaaS (Robot As A Service) to GaaS (Games as a Service) and although cloud-based solutions are not always well accepted by customers that are worried mainly about security and accessibility matters, the cloud is undoubtedly where everything will go as soon as we ensure that customers feel comfortable with it (ensuring their safety, reliability and accessibility), almost everything will be cloud-based. Just think that nowadays all Bank services are available via Internet (BaaS) and we accept operating with it, being our personal and company accounts involved.

Cloud is where scalability and elasticity are possible and the World needs scalability. Cloud is where multi-devices hardware-agnostic and OS-agnostic solutions are possible, where worldwide access is possible, even from the International Space Station. Cloud is where multi-connectivity with any device is possible. It doesn’t matter if it is an IOT device, a database server, a robot, a tablet or even a human brain. Cloud is the only option that really we have to continue our exponential technical growth. And remember, world evolution is an exponential function, not a linear one.

Educational Robotics. A growing business with purpose

noreply@blogger.com (Alejandro Alonso Puig) — Fri, 31 Jan 2020 20:20:00 +0000

I like the definition from Wikipedia of educational robotics: "... a subdiscipline of robotics, applied to the educational field that focuses on the design, analysis, application and operation of robots. It can be taught in all educational levels, from kindergarten and primary education to postgraduate. "

However, it goes much further than creating robots and programming them, also encouraging humanistic cohesion in the group, what is so often forgotten when we talk about technology.

It is common for an educational robotics training to include a challenge, so that students can solve it with materials such as: mechanical parts, sensors, actuators and embedded systems. These materials, complemented with computer tools, allow working on solutions to the challenge. In this way, not only is there a theoretical learning process, but also a practical one, through a series of phases, very similar to those applied in the design of automated solutions for the commercial and industrial market: Analysis, design, construction, programming, testing, documentation and presentation or delivery. Depending on the age and real interest of students, it is possible to dive more in the complexity of these phases, getting from the most basic to the most complex, always from an entertaining and motivating point of view.

Many times this educational training can be complemented with other competitions between teams, from the same center, from other centers or independent teams, organized well by educational centers, companies or other institutions, in order to promote STEM talent (science, technology, engineering and mathematics) and identify innovative solutions in the field of robotics.

Educational robotics empower in the students, future researchers and business people, a series of competencies, awakening in many cases relevant vocations.

Fortunately, educational robotics is taken seriously in many developed countries, being part not only of curricular programs of educational centers, but also of extra curricular training offers (training centers, academies, etc.).

Also it is clearly a business, as the $1.3 billion international robotics education market in 2019 is set to grow to $3.1 billion by 2025, according to findings by market research firm HolonIQ

Source: HolonIQ

As Vicepresident of HISPAROB, Spanish technological platform for robotics, I have to say that we take educational robotics very seriously, as a way to empower talent and scientific-technological knowledge in current and future generations. Among our theme clusters, we have one about Educational Robotics, formed by 26 entities (manufacturers, distributors, training centers, etc.) highly active, seeking collaboration and cohesion of efforts so that robotics reaches not only the brain, but also to the soul of people. That is why at HISPAROB we are greatly grateful for the effort of this group, a reference in Spain and we encourage other groups and teams worldwide to continue helping robotics to reach the people with passion.

Global Robot Cluster (GRC) The biggest Cluster of Clusters

noreply@blogger.com (Alejandro Alonso Puig) — Sun, 22 Dec 2019 15:14:00 +0000

On November 2019, I had the fortune and responsibility to represent Hisparob and Spain in the General Assembly of Global Robot Cluster (GRC) in South Korea, invited by the Daegyeong Robot Enterprise Association (REPA) and financially supported by the Government of Daegu in South Korea.

REPA, starts in 2017 the initiative to form the Global Robot Cluster (GRC) together with three other countries, as an entity that intends to represent most of the countries in the world, under the objective of promoting exchange and collaboration in the field of robotics.

In Nov 2019, eleven countries became part of the GRC:

South Korea, represented by Daegyeong Robot Enterprise Association (REPA)
United States of America, represented by MassRobotics and Silicon Valley Robotics (SRV)
France, represented by FFCR and Coboteam
Spain, represented by Hisparob
Singapore, represented by Singapore Industrial Automation Association (SIAA)
Uzbekistan, represented by Uzbekistan Robotics Federation (URF)
Israel, represented by Israeli Robotics Association (IROB)
Russia, represented by Russian Association of Robotics (RAR)
Philippines, represented by Mechatronics and Robotics Society of Philippines (MRSP)
Malaysia, represented by Malaysia Robotics and Automation Society (MyRAS)
Turkey, represented by ROBODER

By 2020 Thailand and Denmark may also join the GRC.

GRC members. 2019

GRC is a great initiative and I strongly recommend clusters of different countries to join as members. We live in a Global world and most countries in the world have already learned from previous crises the importance of being part of this Global World, to expand opportunities.

Hisparob in Spain tries to help to facilitate this step by promoting international relations for the benefit of our partners and the progress of robotics in our country and in the world.

I want to express a special recognition to GRC, REPA, the Government of the city of Daegu in South Korea and the Spanish companies Dahn Ghun and GR-EX for contributing in one way or other to facilitate this great opportunity for our associates and for our country.

Alejandro Alonso Puig
Vice President HISPAROB

The 8th Edition of Daegu Robot Expo (South Korea)

noreply@blogger.com (Alejandro Alonso Puig) — Sun, 24 Nov 2019 11:05:00 +0000

November 2019 has been the date for this edition of Daegu Robot expo, where we saw a variety of robots, mainly anthropomorphic, although we saw some few professional drones, UGVs, educational robots and parts.

Between the professional drones we saw a huge engine drone, a quadcopter with fuel combustion engine from ATD Lab.

Also a fixed wing drone from Joydrone, with vertical take off and landing

Yujin Mechatronics showed between other things the collaborative robot arm P-rob from the swiss company F&P Robotics

IA Korea showed some scara type robots that they distribute as well as linear actuators

Rainbow Robotics, a spin-off from Hubo Labs in Korea showed their RB Series cobots. They offer a user friendly android based GUI, allowing users to easily configure and operate the robot.

Man&Robot co ltd showed Automatic Screw Assembly Machine Using Cooperative Robot.

Ruben offered 3D vision guided robotics and Bin picking system based on Fanuc robots

QRS co ltd showed their bin picking solutions based on Denso arms

Mintrobot Co Ltd showed their PAL-A4 and PAL-A6 robots. Scara and orthogonal

Stäubli showed their well known robot arms as well as their Stäubli Robotics Suit of software

Educational robots company, distributed in Spain by Dahn Ghun company

Also we saw some smart 3d printers, using either PLA or ABS for non industrial creations.

Wego showed Ugvs mainly, from Clearpath as well as developed by wego.

Einbot showed a deep learning visual inspection robot sorting solution

Robot Campus of Korea Polythecnic showed research works with Dobot educational arms, drones and other automation systems

Oto Robotics showed their industrial articulated robots OTR-6 and OTR-20. 6 axis pick and place robot and 6 axis welding robot.

Woelsung TMP manufacturer of robots for testing and handling radioactive materials, showed one of their telemanipulators for handling of radioactive materials, drug production, nuclear applications including testing, medical applications, and pharmacy.

Mirae Robot showed a set of small educational humanoid robots from Robotis

Hyundai robotics showed their huge clean robot for LCD glass screens manipulation as well as a variety of Industrial robots

Daiso cell. Showed their force sensors, torque sensors and load cells.

DGM Tech showed their rehabilitation exoskeleton

Yaskawa showed their general industrial robot solutions.

Daegu Machinery Institute of components and materials foundation showed several entertainment applications with third party robot arms, like cotton candy, coffee serving and ice making

Sensor Solution showed some sennors for measuring displacement, preasure and torque.

and last but not least, Kuka showed one of their industrial robots

This was all from the 8th Edition of Daegu Robot Expo in South Korea.

by Alejandro Alonso Puig

Is Amazon AWS Robomaker worth it?

noreply@blogger.com (Alejandro Alonso Puig) — Tue, 15 Oct 2019 20:14:00 +0000

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.

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?

noreply@blogger.com (Alejandro Alonso Puig) — Sun, 29 Sep 2019 21:11:00 +0000

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: