Low-Cost High-Tech Robotics for Ambient Assisted Living: From Experiments to a Methodology

2.1 A Robotic Platform Built from Off-The-Shelf Components

Several commercial robots are available. We present here four of them:

• The Miabot [19] robot is rather small (about 10 cm long) and fast (3.5 m/s). It has a built-in Bluetooth connection and must be connected to a local central computer to be Web-controlled. Even if it was not really designed for that, it can carry a small camera or other sensors.

• Another robot of view is the WoWee Rovio [28]. It includes a mobile base, a mobile camera, and a Wi-Fi connection. Its size is 30 × 35 × 33 cm. It can be remotely controlled from anywhere in the world. When the battery is low, it is supposed to come back automatically to its charging dock. Its total cost is about 300 euros, which is acceptable for our purpose. The WoWee Rovio is an interesting robot for an AAL environment, but it is not an open robot, and it is difficult to add new features. In case of failure, the WoWee Rovio is also difficult to repair. For example, such a common operation, as replacing batteries, requires soldering.

• The Jibo social robot [17] should be available by the end of 2015 and should cost about 500 euros. It is about 28 cm tall and 15 cm wide. Its face consists of a touchscreen, and interaction is possible by poking it. It is designed to recognize the faces of the family members. It cannot move but can be motor driven through 360°. Thus, it could be a very interesting robot to monitor, not a whole house, but a room.

• The Romo [23] robot uses a smartphone to control the motors. It can be remotely controlled from anywhere by using the smartphone connectivity. When used as a toy, it can perform autonomous missions. When controlled remotely, it provides an interesting telepresence functionality. The physical separation of the smartphone and the mechanical base makes it easy to repair.

From our point of view, ease to repair is essential. We consider that a robot built from off-the-shelf components (which could be easily repaired or replaced) is a better alternative than an off-the-shelf robot. The main components of such a robot can be identified as follows. First, a mechanical base is required. Second, it must be controllable. Third, it must be Web-controlled. Thus, we can use three main components: the top level component manage the network and communicates with the medium level component, who controls the mechanical base.

• The top-level component must communicate either with the distant user of the robot or the medium-level component. It must also handle additional tasks such as positioning or video monitoring.

  We think that using a smartphone can be a good choice to do that, as smartphones generally embed processing capabilities, webcam, GPS, Wi-Fi and Bluetooth. The smartphone can be connected to the local network through a Wi-Fi connection or its 3G/4G card. It can be connected to the medium-level component through Bluetooth, which presents a cheap and reliable solution. It has enough computing power to manage an additional positioning system.

• The medium-level component makes the robot move (which means controlling motors) and receives commands from the top-level component. For that purpose, we may use a micro-controller, such as an Arduino. Several Arduino shields are available to monitor the working speed and direction of the motors. We can use either a relay shield including four relays or a motor shield based on a voltage regulator such as 78M05. An additional Arduino shield is required to allow Bluetooth communication between the Arduino and the smartphone. The Bluetooth shield is fully qualified to respect the Bluetooth version 2.0.

• As a mechanical base, we have used an open robotic platform, which includes two tracks. It is a 4WD Rover 5 from RobotBase. Other choices should have been made, but this platform is a good representative of rolling robots. The size is close to that of the WoWee Rovio. When powered, it can move forward or backward and turn. The maximum speed is 1 km/h. The Rover 5 is strong enough to carry a mass of up to 2 kg (Figure 1).

Figure 1:

Components of the Web-Controlled Home Robot.

The main advantage of our solution is its modularity: a smartphone, a micro-controller, and a mechanical base. It includes six commercial components (Figure 2):

• A mobile Rover 5 robot used as robotic platform (60 euros)

• An Android Smartphone (<80 euros)

• An Arduino UNO (20 euros)

• A Bluetooth shield (20 euros)

• A motor command shield (20 euros)

• Two batteries (one for the Arduino, one for the motors)

Figure 2:

The Web-Controlled Home Robot.

The total cost, smartphone included, is comparable to that of a WoWee Rovio, i.e. 300 euros. The price of the positioning system is not included in the total cost. A commercial sensor cost is about 80 euros. To achieve 2D positioning, three sensors are needed. Owing to the range of a sensor, i.e. 10–20 m, the cost of the positioning system is related to the size of the house. These prices are expected to decrease in the near future.

The reliability and the maintainability of our mobile home robot is significantly higher than that of a WoWee Rovio or a Miabot. In case of failure, we only need to replace one component. More, the diagnosis is very easy because each component can be individually tested.

When using 2000 mAh lithium batteries, we have a 30-min autonomy when the robot is continuously moving. We have several hours of battery life when the robot is waiting for commands. Using more powerful batteries may drastically increase the autonomy of this prototype.

Automatic battery charging is not available on our prototype. It is not in the scope of the paper, but solutions to give more power autonomy to the robot could be used. For example, batteries could be charged using an inductive power transfer, which start to become popular for cellphones.

2.2 Software Architecture

We also need to face software concerns. A solution for the software is to install it fully on the robot. In an AAL environment, such a proposal has severe limitations. First, configuration will not be easy if the robot must be used from the outside. Moreover, an approximate configuration can lead to an insecure system, and unauthorized persons could take control of the robot. Second, installing the whole software on the robot will increase the total cost of the robot because a single smartphone could not be powerful enough. For example, if image analysis is required, we need more than a smartphone. Third, if the software is on the robot, it is difficult to make it evolve. Fourth, more energy will be required if the server is installed on the robot, and its autonomy will decrease.

From our point of view, it is important to install as much software as possible in the cloud (see Figure 3). The embedded system on the robot should be reduced as much as possible to handle only basic functions. The robot system must handle commands coming from the cloud to make the robot move. It also sends photos, videos, or any information coming from its sensors, to the system in the cloud. The information processing is mainly performed in the cloud. Thus, the whole system will be much more easy to deploy, configure, and make secure. We can expect a plug and play system, which is able to communicate with a distant server, by using a classical Internet connection (offered by the Wi-Fi or 3G/4G of the smartphone).

Figure 3:

Architecture

To make the whole system work, a distant server is needed, either in the cloud, or in the local cloud. The difference between the cloud and local cloud is quite easy to understand. The local cloud offers the same services than the cloud, but the servers are in the habitation of the robot’s owner. The local cloud increases the privacy because data stored on the servers can only be accessed by the robot’s owner. To ensure the reliability and the security of the system, a direct access between the distant user and the robot is forbidden. The distant server will connect both sides.

2.3 Technological Choices

Several technological choices could be made to ensure the communications between the robot, the server in the cloud, and a distant user (also called client). We investigate the HTTP protocol and the WebSocket one.

The HTTP protocol is a stateless protocol that requires the establishment of a TCP connection for each transaction. The establishment of a new TCP connection may be time consuming and sometimes takes several seconds. A moving robot left unsupervised just a few seconds can be dangerous. The WebSocket protocol ensures a permanent connection to the server after the establishment of the TCP connection. In this context, the WebSocket protocol is more suitable to guarantee real-time control of the robot than the HTTP protocol.

The WebSocket protocol was standardized in 2011 [16]. A WebSocket communication requires a single connection that is maintained until the server or the client explicitly ends it. Both the client and the robot send and receive information to and from the Web server through WebSocket. The client, respectively the robot, sends a command to the server that is forwarded to the robot, respectively the client.

The client side does not require any change. It only requires a browser. Indeed, all recent browsers are compliant with the WebSocket standard. On the other side, the robot requires a specific application to create a WebSocket connection. The jWebSocket framework provides tools for implementing communications using the WebSocket protocol. The jWebSocket framework eases the process to implement the WebSocket protocol in a java application or even mobile application (Android applications). The server uses a combination of the Apache Web server and Tomcat to interpret the WebSocket protocol. The Apache server is transparent because it only forwards WebSocket requests to the Tomcat server. The Tomcat Server processes the WebSocket transactions.

As the distant server connects both sides (see Figure 4), two WebSocket connections are required in order to establish an end-to-end connection, i.e. a connection between the client and the server and a connection between the server and the robot. All messages sent by the robot (respectively the client) are forwarded by the server to the client (respectively robot). Hence, the server may have the role of an application-layer gateway. When the software version is different on both sides, the server can translate the message from one version to another. In case a message is not supported by one version, the server can prevent unnecessary transmissions and restrain some functionalities.

Figure 4:

The WebSocket Architecture.

2.4 Properties

The AAL environment is extremely complex and vulnerable. In order to offer a high level of quality, the users (relatives/caregivers or elders) need a reliable and secure system. Services offered to the users have to ensure a high level of quality. Hence, the properties such as security, reliability, robot positioning, and acceptance have to be supported by the overall system. A low-cost system cannot sacrifice these properties on the altar of the cost.

2.4.3 Localization

In order to localize the robot, a positioning system is necessary. We designed a low-cost localization platform for 2D positioning (Figure 5). Let us assume the robot only has to monitor a flat floor, i.e. the relative z-coordinate is always constant. In cases where different floors have to be monitored, a robot may be on each floor. They can communicate between them in order to extend the control in the whole habitation.

Figure 5:

The Positioning System.

The positioning system involves four TelosB wireless devices. One of them (called main) is placed on the robot. The three others (called auxiliary) are placed in strategic locations of the room, in the corners for example. Owing to multipath components and attenuation, Non-Line of Sight propagation increases the noise and reduces the accuracy of the system. The places must be chosen in such a way that the robot is most of the time in Line of Sight with the auxiliary sensors. In this way, the communication would be done with very little interference.

Figure 5 shows the whole system and the interaction between the components. Auxiliary sensors send messages periodically. After receiving a message from an auxiliary sensor, the main sensor gathers information: identity of the sender (ID) and receiver’s received signal strength indicator (RSSI). Once the main sensor acquires a message from each of the three fixed sensors, it will create a data packet which contains the three pairs of ID – RSSI value for each sender, and will send it through the USB interface to the Arduino board. In order to optimize the energy consumption and to reduce unnecessary transmission, the server computes all the values to determine the robot’s position. To approximate the position of the mobile robot, the server uses the Newton–Raphson method. This method attempts to find a solution in the nonlinear least squares sense. The Newton–Raphson’s main idea is to use multiple iterations to find a final position based on an initial guess (by example, the center of the room), that would fit into a specific margin of error.

The first results show that RSSI values are not constant due to multipath components. Hence, the precision of our system is about 2 m. Such a precision is sufficient to know approximately where the robot is.^[1] Indeed, such a precision is not enough to perform some specific tasks such as giving medicine, checking a patient’s temperature and pulse.... In order to have an autonomous mode, the precision has to be about a few centimeters. With ultra-wideband (UWB) signals, the precision can reach up to 2 cm [10]. However, the cost of UWB transceivers is quite expensive (about 400 euros). Nowadays, this type of technology is not mature enough to be used in the house of dependent people. Owing to this cost, UWB positioning system is more suited to industrial environment.

The localization system eases the process to control the robot. The Web interface is appropriately designed to integrate the localization feature. The web interface will contain the cartography of the house, and the robot will be able to reach a destination, only by clicking on the map.

2.5 Experiences

In this section, we present some experiments that illustrate the capabilities of our system. The server is connected to the local network of our laboratory. However, due to the flexibility of our architecture, the server could be hosted in the cloud. It is hosted to a public address so any user is able to access it from anywhere using just a Web browser. Beside the server, one robot is available. The system is tested under two scenarios:

• some colleagues in Romania access the robot from the Military Technical Academy of Bucharest (about 2500 km from our laboratory).

• the user is local to the laboratory.

In order to show the performances of the system, we define the following performance metrics:

• the Round-trip time between components is the time to receive a response after sending a request without counting the delay due to other components.

• the End-to-end round-trip time is the total time to receive a response after sending a request, i.e. it is the sum of the Round-trip time between the whole components of the system. The increase in the End-to-end round-trip time significantly degrades the QoS of applications.

In Table 1, we present the Round-trip time related to component connections when the user accesses the robot from different locations (laboratory and Romania). All times are expressed once the WebSocket connection is established.

It is interesting to see that the most important delay is added by the Bluetooth connection between the Arduino board and the smartphone. Indeed, the data rate of the Bluetooth shield is quite low (2 Mbps). The time to transmit the data from the robot to the phone, or inversely, is proportional to the data rate. This is the principal factor to this delay. Moreover Bluetooth system is a contention-based system. The delay to access to a free medium or the retransmissions due to collisions increase the Round-trip time significantly. However, it is interesting to use a Bluetooth connection between the smartphone and the robot due to its low consumption. As mentioned in Ref. [22], the power consumption of Bluetooth is 10 times lower than Wi-Fi.

The Round-trip time between the smartphone and the server is quite low. Unlike Bluetooth systems, Wi-Fi systems have a high throughput. The transmission time is significantly reduced. The Round-trip time induced by Wi-Fi is roughly four times lower than the one obtained with Bluetooth.

The Internet delay, i.e. when the user is located in Romania, is almost negligible compared with local access. The university of Brest, respectively, Academy of Bucharest, has a guaranteed bandwidth of 3 Gbps, respectively, 1 Gbps, on its national network. Hence, the difference in time is particularly due to the propagation time.

In Table 2, the End-to-end Round-trip time is analyzed under two different locations (local and Romania) and two protocols (HTTP and WebSocket). The End-to-end Round-trip time is an important parameter because it is the main criteria to determine if real-time control is possible. To control a distant robot with an acceptable quality of experience, it is commonly accepted that the delay never exceeds 400 ms. We can see that the HTTP protocol cannot guarantee the delay bound. Indeed the time to establish the connection, to send a request, and receive a response significantly exceeds the delay bound. The WebSocket protocol is more suitable for real-time control. The WebSocket protocol has two main parts: a handshake and the data transfer. Being designed to work well in the Web infrastructure, the protocol specifies that the WebSocket connection starts its life as a HTTP connection, offering backward compatibility with no-WebSocket systems (older browsers). The handshake of the WebSocket protocol has slightly the same time than the HTTP protocol. Once the connection is established, control frames are periodically sent to maintain the connection. Hence, the time is significantly reduced compared with the HTTP protocol. For all scenarios, the End-to-end Round-trip time does not exceed 300 ms which is quite acceptable to transmit QoS traffic.

2.6 From Experiment to Methodology

In this section, we presented a prototype of a low-cost high-tech robot for AAL. We showed its design and the requirements it fits. We also gave some results to show the effectiveness of the remote control of such a robot.

Nevertheless, to achieve the building of this prototype, we had to experiment with several solutions, to construct a solution, to modify it, to rebuild it again, and so on. We used a bottom–up approach. This experimental building lead us to capitalize our experiments in a development methodology, which will be presented in the next section. This methodology could be used in several domains where hardware, software, networks, and environments are concerned and use a top–down approach.

3.1 Available Development Methods

The first we have found is the Y-CIM model proposed by Scheer [25]. This model presents the link between the logistics chain and the product development, beginning from the requirements of the future products and the early design, until the shipping of the finished products and their maintenance (see Figure 6).

Figure 6:

General Scheme of the Y-CIM Model.

The X-modell of Mertens [20] is inspired by the previous, but its separates the description in two processes that intersect (see Figure 7). One process is about the development, the design, its matter is only the immaterial aspects of the product. The other is about the materials, the parts, the logistic related to the product. The intersection matches the production, when all needed material resources to produce are ready: parts, materials, tools, people, machines, and the immaterial resources are ready too: programs for the NC machines, etc.

Figure 7:

General Scheme of the X-Modell.

About the design of safe complex systems involving people, computers, and communication, the XUP model [8] gives us a very interesting approach (see Figure 8), that has several similarity with the X-Modell of Mertens. In fact a model dedicated to the problems of the safety, security, and dependability should take into account the human behavior, and more generally the environment of the system. On the left of the X it seems that the topics are functional, but on the right, the topics are about the material aspects, in relationship with the environment, involving humans.

Figure 8:

General Scheme of the XUP Development Method.

But all of these models and methodologies forget the environmental impacts, like the finished character of the Earth to provide raw materials and to receive a lot of waste. All, forget, too, the potential of the reuse of components or the reuse of material. The issue is how to introduce these concepts in a new larger model compatible with the previous. In the next paragraph, we present our methodology, the X-Development method, a resource-based method, that opens the door to the evaluation of the environmental impacts at each step of the development, especially during the early design stage.

3.2 Synthesis: the X-Development Method

The actual formulation of the X-development method was designed by members of our team [26]. The X-development method can be understood as a scheduling of tasks. The general scheme is presented in Figure 9 where the time is the horizontal axis.

Figure 9:

General Scheme of the X Development Method.

We considered that a system could be produced only when its definition is completed. The materials needed to produce the system should be available when the production starts. By using the ^– \ _– shaped representation of the well-known waterfall method [24], we have added a lower left task (Selection and Collect) to represent the fact that the bulk materials and the standard elements have to be collected before the production.

At the bottom of the graph, we have added a rectangle to represent the environment existing before the beginning of the process and still remaining after the whole life cycle. The rectangular shape means that the environment is conservative, all the materials used to build the system and its consumption will go back to the environment at the end of the lifespan or will be recycled or reused. The result is that the system modifies the environment during its usage and after. If these aspects are not taken into account at the beginning of the design, we can have environmental consequences.

We have added the upper right task (Integration) to include the famous V cycle [15], which leads to the X shape. We consider that the crucial node of the graph is the meeting point of the branches. Above this point, it is the field of the information, data, software, and others, whereas below this point, they are the physical and material fields. We have drawn a horizontal arrow through the central point to represent the Time. The whole scheme could be understood as a PERT – each line as a task, and each node as a transition between tasks. The process of the design begins on the upper left branch by the definition of the specifications. Early during this stage, the designer should specify the environment in which the system will work and the borders between this environment and the system.

In fact, there are coupled phenomena in the environment that have effects on the system. This last should be protected against or it exploits these. The behavior of the system is not independent of its environment; we should consider the system and its environment as a whole. In this aim, we use the concept of super-system well known by the specialists of technical thermodynamics. The super-system is the set composed by the system and the elements of the environment that interact with it. It can be considered as a temporal window that follows the product along its life cycle and after.

Then, the exchanges between the system and its environment will be mostly known and so is the geometry of the interaction. This knowledge is sufficient for choosing the resources (materials, components, etc.) that should be used to build the structure of the system [27]. So it is possible to start the task of the selection of the raw materials and components to be used, in parallel to the engineering design process. There are vertical arrows not drawn in Figure 9 matching these information exchanges. These quantities are physically dimensioned below the middle horizontal line, and above they can be transformed as dimensionless variables and parameters. On the right of the central node of the scheme, the production process of the parts and the assemblies start below the middle line, beyond the integration process of the software is performed. At both right ends, each result forms an integrated set. The software is commonly embedded inside the whole system.

In the next subsection, we explain how to formalize the method in the way to find performance indicators of the product, and how to connect the problem to the indicators used for the studies about environmental impacts and life cycle analysis (LCA). We concentrate on the left part of the X development method, to present interactions between Specification and Selection, as this part is the most decisive.

3.3 From the Method to the System

We write the interactions in the super system and the characteristics of the system in the expression (1):

where {P} is the set of performances, {S} the functions, {F} the constraints (temperature, pressure, etc.), {G} the geometry of the device and its components, {M(p)} the properties of the materials. The symbol := means that the performances are resulting from the design and the constraints.

From the designer’s point of view, the constants of the problem are the requirements and the environment. He translates these into performances, (a subset of {P}), functions (a subset of {S}), and constraints (a subset of {F}). The set {S} contains functions, some of these correspond to the physical behaviors of the product, the chemical behavior, and in certain cases the biological behavior. But {S} includes other functions chosen and/or written by the designers, like control-system functions, or software, that modify the behavior of the product taking into account events or measurements. Taking into account, the targeted performances, the constraints and the functions, the designer chooses the components, the materials, and eventually adds functions to {S} that improve the performances {P}, the value, and the services without respect of {F}, that means no extra cost or impacts.

At the end of the design stage, the product is completely defined in terms of geometry {G}, materials {M(p)}, and the technical functions included in {S}. We cannot think in terms of functionality, length, time, mass, joule, etc. because all of these quantities are physically not commensurable, but they are correlated by flux exchanges, mass, energy, motion quantity, electrical current. It is more convenient to think in a metric space where all the parameters and the variables and parameters are without physical dimension. Using the dimension analysis applied on the parameters and variables introduced previously, many dimensionless ratios can be forged. For the eco-design, other dimensionless parameters can be found in the environmental documentation of the Global Reporting Initiative (GRI) [12] like the EN2 indicator “Percentage of materials used that are recycled input materials.” The indicators having a physical dimension could be adimensioned. Our method is a global approach that includes both software and hardware developments. Hence, traditional methods as TRIZ [3] are compatibles with our model. At this stage, the designer of the mechanical part could use the TRIZ method to search a scalable principle of innovative solution.

3.4 Analysis, Design Challenges

The analysis phase needs to define the goal {P} and the constraints of the project {F}. The aim is to offer new services to the assisted people living at home, using as well as possible the information and communication technologies. The system has to be interactive: the mobile devices are not autonomous, but wireless connected to the Internet, through a local cloud. The mobile devices are mobile elements of a wired and wireless sensors-actuators Home Area Network (HAN). Our hypothesis is that the population of companion robots in the European Union will be in the range 50 M–100 M units, before the middle of the century. We have to identify and quantify the needed services these constitute the set {S}. After that, we define the functionalities and the performances of the robot. We will end this section giving a description of an ideal final result.

In our case, the super system is composed by the robot, present people, remote people, the network, and the near environment. Elderly people’s homes do not have stairs or are restricted so the robot does not need to climb up and down them. In cases where different floors have to be monitored, a robot on each floor (TRIZ-principles 12, 26a, 1a) can be deployed. They can communicate between them in order to extend the control in the whole habitation. The communication between robots is not the subject of the paper, but could be performed through the HAN.

We consider that two people at a maximum use the robot at the same time, one locally, the other remotely. The robot is connected to a teleservice provider, linked to the healthcare insurance and or to the rescue and emergency services. People communicate with sounds and gestures. The first need is to catch the sounds and images and to communicate in both directions. People are supposed to move, the second need is to be able to follow people. People are supposed to be awake for two thirds of the day and to be idle the rest of the time. The need is that the services should be available at least 16 h per day in a mobile mode, and 8 h per day in a static mode. People can use walking sticks or walkers or carry small objects.

The mass M of the robot has to be smaller than the mass of a walker, <3 kg. The maximum speed of the robot is normalized (V < 1 m/s). The size of the robot if it is on the floor should not exceed the size of two shoes because the robot should follow the people in motion. At least the robot should be able to move forward, backward, turn right and left in place, and obviously stop.

The lifespan of the robot should be long because we suppose that the targeted people are not able to accept great changes in their life. The need is between 1 year and 20 years because 1 year is the typical period for a contract with a teleservice provider, and 20 years is within the maximum lifespan of a pet. The yearly production should be between 2.5 M and 100 M units depending on the renewal of robots and percentage of the equipped people. We consider that failures are unavoidable, even if the system contains a lot of redundancies. We take into account the MTBF and the MTTR. The MTBF should be equal to the warranty period; this is a psychological argument based on the acceptability of the failure. It appears that a MTBF of 1 year at least or 2 years is acceptable. The distance range D of the mobile unit should reach 4 km per day, it represents 3000 km during a MTBF period of 2 years.

The MTTR issue is rather different because it is not acceptable to lose the help of a companion robot more than a few hours. But dependent people are visited daily by caregivers. The proposed solution is to adopt a design permitting an easy maintenance done by the caregivers. The robot should be dismounted quickly. Each element can be replaced, reconfigured, and tested during the daily visit.

The energy autonomy is the big issue. We can consider that the robot will move <70 min per day, but the communication system should be on 24 h a day. Batteries of the robot can be charged when people are idle. We consider that the robot will interact with people; the robot has to inform about the level of energy, but the decision to recharged it remains to the people present or far away. One important role of the robot is to stimulate the dependent people to do common acts, like feed the pets or recharge the batteries of the devices. There are other ecological issues; for instance, reducing the waste of rare earth elements used by microelectronics, reducing the carbon footprint, reducing the wastes, recycle copper, plastic, etc.

All of these aspects give us a minimal “functional unit” of 1 year of usage, a range of 1500 km, permanent monitoring, a mass of about 3 kg, the size of two shoes on the floor, an ideal MTTR_i of a few minutes, a minimum MTBF_m of 1 year, the ability to communicate images and sounds through a wireless connection with a bandwidth upper than 1 Mbits/s, etc. We share these aspects in two sets, the first one of the performances {P} and the other one the constraints {F}.

3.5 Consequences on the Architecture

We have the aim to take into account the potential availability of the resources that the product is made of, and the potential impacts that the production, the usage, the maintenance, and the end of life can have on the environment. The X-development method can be understood as a resource-based design methodology, from the beginning of the design to the end of the life cycle of a product.

It appears that all the concepts used are existing, like the dimensional analysis, databases of components, databases about materials, the TRIZ method, the GRI documentations, etc. so our methodology is a kind of road map, describing a succession of stages. We are applying it in the case of the family of the small robots described in a previous parts of this article, researching the architecture and the components that satisfy both the technical and environmental constraints.

The application of the methodology on the design problem of sustainable robots leads to adopt a modular architecture. The mobile platform including its motors and steering system and its sensors, is independent to the central unit and its embedded sensors. We have selected a simple standard platform, made of recyclable materials (ABS, copper, magnets NdFeB, etc.). The controller is based on an Arduino board; because its recyclability is unknown, we decided to keep the component with the lowest mass and the lowest power consumption. The central unit is a smartphone, a tablet-PC, or a Raspberry-Pi: we do not know exactly the recyclability of each, but for the two first, we can reuse an old device that includes a camera, microphone, GPS, etc. and for the third, the component is easily reusable, and the peripherals like the camera and other sensors.

The modular architecture permits the quick replacement of a damaged subsystem by a standard component taken off the shelf. The software can be easily downloaded and installed on the controller or the central unit. The maintenance could be done by people with a moderate knowledge in robotics, like caregivers or daily visitors (postmen).^[2]