Approach function study for concierge-type robot by model-based development with user model for human-centred design

Abstract

Service robots are common sights in everyday life. The service robots are expected to provide useful services with a high degree of usability, and a high degree of user experience (UX) to users and other persons around the service robots. In addition, the human-centred design (HCD) is being used in various industries, and HCD can be used also in the service robot industry for improving usability and UX. We have been researching a model-based development with user model (MBD/UM) as a practical HCD process for service robots. Here, we studied an approach function on a concierge-type robot that should have a high degree of usability and a high degree of UX from users’ viewpoint, by applying MBD/UM for HCD. The result of our study shows that MBD/UM can be a practical HCD process for developing service robots.

Background

Service robots are becoming more common in everyday life. The service robots are expected to provide useful services with a high degree of usability and a high degree of user experience (UX) from users’ viewpoint. We surveyed required functions on concierge-type robots, and found that an approach function was important for the robots because the robots had to approach users before talking with the users. Therefore, we studied the approach function with a high degree of usability and a high degree of UX, by applying a development method which we named the model-based development with user model (MBD/UM) [1] as a practical process of human-centred design (HCD) [2].

Current development process and MBD/UM for HCD

Embedded-system products are expected to have a high degree of usability and a high degree of UX to satisfy user requirements. But, the products sometimes failed to satisfy the user requirements, because the products were designed on the basis of ideas and proprietary technologies of individual manufacturers. Therefore, HCD becomes a popular way to satisfy user requirements.

We have been studying MBD/UM as a practical HCD process for service robots, especially those at risk of injuring stakeholders, i.e., users and other persons in the environment.

Figure 1 shows HCD process model taken from ISO 9241-210:2010.

Fig. 1

HCD process model

Problems of current development process

Design solutions were evaluated by product samples and stakeholders. Therefore, long time and large cost were required to produce hardware of the product samples, and there were risks to injure the stakeholders at evaluation.

And products were produced from the manufactures’ viewpoints, and then sometimes failed to satisfy user requirements. Therefore, HCD using paper prototyping [3] and mock-up [4] became popular. However the paper prototyping and the mock-up were not suitable for evaluating products which had various movements, because only limited movements of product could be implemented by the paper prototyping and the mock-up.

And there were some researches evaluating design solutions with a digital mock-up of product and a user model (UM) on a simulation tool such as a 3D CAD. The representative researches were “Virtual User Modeling and Simulation” (VUMS) [5] by VERITAS Project—FP7 IP [6] in EU, and “Digital Human” [7] by National Institute of Advanced Industrial Science and Technology [8] in Japan. These method of evaluating the design solution by digital mock-up and UM were suitable for evaluating the products with simple functions controlled by stakeholders, but were not suitable for evaluating the products requiring condition-dependent actions and/or real time reactions in response to various behaviors of stakeholders, because only limited functions of product and limited behaviors of stakeholder could be implemented in the digital mock-up and UM.

And there were some researches regarding the model-based development (MBD) [9]. MBD was a development method to produce design solutions with a device model of product and to evaluate design solutions repeatedly with the device model by simulation, instead by using an actual product sample. However in MBD, user activities were defined as part of device model or environment model; that is, UM was not implemented as an independent model separating from the device model and environment model. Therefore, only limited functions of product could be evaluated by simulation, due to a lack of UM which could simulate various behaviors of stakeholders.

Aim and approach

The aim of this study was to complete an approach function which would satisfy the user requirements on a concierge-type robot, by applying MBD/UM as a practical HCD process with advantages as follows:

• To reduce time and cost required to produce the hardware of the product sample at evaluation.

• To evaluate the product by simulation, under various conditions and also repeatedly under the same condition.

• To eliminate risks injuring test participants in the evaluation, and to reduce the risks in the certification.

We studied the approach function by MBD/UM consisting of Persona [10], model-based systems engineering (MBSE) [11], MBD and RT middleware (RTM) [12] as an MBD tool. RTM was a modular-based middleware with an ability of model-based simulation (MBS) which could replace the individual modules. We implemented MBD/UM as a practical HCD process as follows:

• Understand and specify the context of use by Persona. Persona can describe both a profile of a stakeholder and a context of use of a product. Therefore, Persona can be effective to understand and to specify the context of use.

• Specify the user requirements by MBSE. MBSE can define user requirements for a product, and models of product and stakeholder as diagrams, drawn based on the profile of stakeholder and the context of use. Therefore, MBSE can be effective to specify the user requirements and the models of product and stakeholder.

• Produce design solutions to meet user requirements for MBS on RTM. MBD can produce design solutions for MBS with a device model of product and UM of stakeholder by using RTM, based on the user requirements and the models. Therefore, MBD can be effective to produce design solutions to meet user requirements.

• Evaluate the designs against requirements by MBS on RTM. MBD can evaluate the design solutions against the user requirements by MBS with the device model and UM on RTM. Therefore, MBS on RTM by MBD can be effective to evaluate the designs against requirements.

We added 2 steps to HCD process model as follows:

• Produce product sample on RTM. A product sample can be produced on RTM by replacing the device model and UM with actual subsystems with hardware.

• Certify the product sample on RTM. The product sample can be physically certified safely by test participants on RTM.

Figure 2 shows MBD/UM as a practical HCD process.

Fig. 2

MBD/UM as a practical HCD process

Object robot and function

We surveyed the required functions on a concierge-type robot, hereafter referred to as Robot, providing services in an indoor hallway, and then, found that Robot should at least have an approach function, an emergency braking function and a follow function, in addition to a basic function talking with a user, hereafter referred to as Target, around Robot.

Among the required functions, we focused on the approach function, because Robot had to approach Target before talking with Target, and Robot had some risks to injure Target or to give Target fears during approaching.

For studying the approach function on Robot from users’ viewpoints, we applied MBD/UM as a practical HCD process for implementing a high degree of usability and a high degree of UX to satisfy the user requirements.

Figure 3 shows the environment of the approach function.

Fig. 3

Environment of approach function

Methods

We studied the approach function on Robot with physical safety as the usability and psychological security as UX, in accordance with MBD/UM as a practical HCD process. UM represents a typical user in individual user groups, and can be a base of further study for personalization.

Plan the human-centred design process

To start MBD/UM as a practical HCD process, we focused on the approach function in a wide hallway of a building such as a hospital, a shopping mall, or a nursing home.

And, to plan MBD/UM process, we surveyed situations in which the function was required, and then, we chose the situations as follows:

• 1. Target calls Robot for asking something. In this situation, we assumed that Target waited for the arrival of Robot while paying attention, because Target asked Robot to approach.

• 2. Robot intentionally approaches Target to inform something. In this situation, we assumed that Target was standing but only was sometimes paying its attention to surroundings, sometimes not, because Target did not know the approach of Robot. Therefore, Target would be at a greater risk of colliding with Robot, when Target was not paying its attention.

On the basis of these situations, we planned MBD/UM process for designing the approach function with physical safety and psychological security on Robot. And then, we started HCD cycle by MBD/UM with surveys of experience to understand and to specify the context of use of the function.

Understand and specify the context of use by Persona

As the 1st step of MBD/UM as HCD cycle, the context of use has to be understood and specified for determining the user requirements. Therefore, we considered possible causes of collision between Target and Robot in a hallway including light collisions without injury, and collision hazard by Robot.

We assumed that lack of attention was a cause of the collision or hazard between people in the hallway. So, we surveyed the causes of such inattention, and then chose mobile phone operation as a cause on the basis of our own experiences and the report [13] concluding that the mobile phone operation was a risky pedestrian behavior when crossing a street by distraction.

Then, to verify our assumption regarding the causes of collision or hazard, we clarified the situations in which persons collided with each other or pass such a hazard in a passage or hallway by administering a questionnaire to 9 respondents. The questionnaire asked the respondents if they had experienced any collisions or felt a collision hazard in passages or in the hallways, as follows:

• Have you experienced any collisions or felt a collision hazard with other people during walking?

• Have you experienced any collision or hazard with attentive people, inattentive people or both?

• What were the inattentive people doing at the experience of the collision or hazard? Operating a mobile phone or others? If others, please describe what they were doing.

The result of the questionnaire showed that all respondents had had experiences of the collision or collision hazard with others. The result also showed that the inattentive people faced more risks of collision than attentive people, and the mobile phone operation was a cause of collision or hazard in the case of the inattentive people.

Table 1 shows the result of the question regarding the experience of collision or hazard.

Table 1 Experience of collision or hazard

The questionnaire asked the approach pattern when the respondent experienced the collision or hazard, as follows:

• Did the people approached at a constant velocity or by a deceleration, at the collision or the collision hazard?

The result to this question showed that the approach at constant velocity gave Target more fear of collision than the approach by deceleration.

Table 2 shows the result of question regarding the relation between the approach pattern and the fear of collision.

Table 2 Approach pattern and fear of collision

By these results, we defined a user profile of Target by Persona, and then, we assumed the context of use of Robot in the narrative of Persona, as follows:

• Target is standing sometimes attentive to its surroundings, sometimes inattentive, when Robot approaches.

• Target is inattentive during the mobile phone operation.

• Target feels fear of collision, if Robot approaches at constant velocity and stops suddenly.

To the above, we added 4 assumptions on the basis of our own experience as follows:

• Target feels a fear of collision, if Robot approaches very close to Target.

• Target becomes attentive by being warned.

• Target feels a fear of collision, if Robot moves faster than Target.

• Inattentive Target may start walking suddenly.

Specify the user requirements by MBSE

As the 2nd step of MBD/UM as HCD cycle, the user requirements have to be determined on the basis of the specified context of use. Before clarifying the user requirements, a model of the stakeholder has to be specified by drawing the diagrams in MBSE for understanding and defining the activities of stakeholder on the basis of the context of use. Then, using the model of stakeholder, the user requirements for the product can be determined by using the requirement diagram in MBSE. And, on the basis of the user requirements, a model of product can be defined by using the state machine diagram in MBSE.

Therefore, we first defined a model of Target by MBSE, for clarifying the user requirements for the approach function by Target.

Figure 4 shows the model of Target by a state machine diagram in MBSE.

Fig. 4

Model of Target by state machine diagram

In this study, we focused on the states of “Standing attentively”, “Standing inattentively” and “Monitoring environment”, because we assumed that Robot would move slower than Target and would not be able to catch walking Target.

Then, on the basis of the model of stakeholder, we specified user requirements for the approach function on Robot for standing Target, sometimes attentively, sometimes inattentively by mobile phone operation, by using a requirement diagram in MBSE.

After that, we summarized the requirements as follows:

• The approach function has to warn an inattentive Target of Robot’s approach at an appropriate distance and to warn Target who may be starting to walk suddenly, for ensuring psychological security.

• The approach function has to stop Robot at an appropriate distance to avoid a collision, for ensuring physical safety.

• The approach function has to start deceleration at an appropriate distance so as not to induce any fear of collision in Target, for ensuring psychological security.

• Robot moves slower than Target.

Next, we defined a model of Robot by MBSE regarding the approach function, on the basis of the user requirements.

Figure 5 shows the model of Robot regarding the approach function by a state machine diagram in MBSE.

Fig. 5

Model of Robot regarding approach function by state machine diagram

And, the following values were required by the model of Robot in Fig. 5.

• An appropriate distance to Target at which to stop

• An appropriate distance to Target to start deceleration

• An appropriate distance to Target to give a warning

We assumed that determining a personal space for talking would give an appropriate distance to Target at which to stop, because Robot approached Target to talk with. We examined the idea of such a personal space by conducting an experiment with 7 test participants. We measured the personal spaces by having each test participant approach a standing person and adjust the distance to the person by moving back and forth on foot, in a wide hallway.

Table 3 shows the result of the survey of the personal space for talking.

Table 3 Personal space for talking

We assumed that a distance to an obstacle where a person starts deceleration would be an appropriate distance to Target for Robot to start deceleration, because we assumed that the distance to the obstacle was important for deciding to start the deceleration, when person and obstacle were getting closer at a velocity slower than a pedestrian.

Therefore, we surveyed the distance to an obstacle at which a person started deceleration in an experiment with 7 test participants by LRF unit. We measured the distance by examining how the test participants steered a service robot with their eyes at an average velocity of 860 mm/s as Robot approached an obstacle from the front in a wide hallway.

Table 4 shows the results of the distance to obstacle in the front at which the participants started deceleration.

Table 4 Distance to obstacle to start deceleration

We assumed that a distance getting closer to Target during a reflex time of Target would be an additional distance to the distance at which starting deceleration for adjusting the appropriate distance to warn Target.

Then we surveyed the reflex time from a warning sound until Target reacted to the sound in an experiment with 10 test participants. Therefore, we measured the reflex time from a warning sound until a button released as the reaction.

Table 5 shows the results of the reflex time measurements.

Table 5 Reflex time from warning sound until reaction

Next, for designing the approach function for both attentive Target and inattentive Target, we clarified differences in their behaviors.

And then, we researched a way to distinguish inattentive Target from attentive Target. As a typical behavior of the inattentive Target, we focused on mobile phone operation. For distinguishing inattentive Target from attentive Target, we surveyed the pose of people operating a mobile phone.

Figure 6 illustrates the poses of people; the left drawing shows a figure not operating a mobile phone, and the right drawing shows a figure operating a mobile phone.

Fig. 6

Poses of people

In Fig. 6, we focused on the ratio of “Ha _h  − He _h ” to “S _h  − He _h ”, and the ratio of “Ha _v  − E _v ” to “S _v  − E _v ” to distinguish the pose of inattentive Target operating a mobile phone from the pose of attentive Target not operating a mobile phone, because we found that the horizontal component of a hand position was between the horizontal components of the shoulder and head, and the vertical component of a hand position was between the vertical components of the shoulder and the elbow, during mobile phone operation.

• H _h (%): Horizontal position of hand.

  $$ H_{h} = \frac{{Ha_{h} - He_{h} }}{{S_{h} - He_{h} }}*100 $$

  (1)

• H _v (%): Vertical position of hand.

  $$ H_{v} = \frac{{Ha_{v} - E_{v} }}{{S_{v} - E_{v} }}*100 $$

  (2)

Figure 7 illustrates the pose of Target operating a mobile phone, and the elements of the formulas (1) and (2).

Fig. 7

Pose of Target operating mobile phone

Therefore, we surveyed the pose of people operating a mobile phone with 14 test participants in an experiment in which the test participants approached Kinect unit on foot in a wide hallway. The data used in the analysis were stable readings made during the approach.

Table 6 shows the results regarding the pose of inattentive people operating a mobile phone. The “Always distinguished” column shows the proportion of test participants who were always recognized as operating a mobile phone. The “Sometimes distinguished” column shows the proportion of test participants who were sometimes recognized as operating a mobile phone. The “Minimum recognition rate” column shows the minimum recognition rate of mobile phone operating poses in all of test participants.

Table 6 Pose of inattentive people operating mobile phone

For distinguishing the pose of Target operating a mobile phone from the pose of Target not operating a mobile phone, we chose a combination of H _h and H _v values on the basis of the conditions as follows:

• A hand locates close to the center of the body in the horizontal axis.

• A hand locates higher than elbow in the vertical axis.

• All test participants sometimes satisfies the combination of H _h and H _v .

• The minimum recognition rate of the combination of H _v and H _v in all test participants is over 50 %.

By the result of experiment, we chose the combination of (H _h  < 80 %) and (H _v  > 35 %) as the values distinguishing the pose of people operating a mobile phone from the pose of people not operating a mobile phone.

Produce design solutions to meet user requirements for MBS on RTM

As the 3rd step of MBD/UM as HCD cycle, a design solution has to be produced to meet the user requirements. Therefore, we produced a design solution of the approach function on Robot for MBS on RTM to meet the user requirements.

For producing a design solution of the approach function for both attentive Target and inattentive Target, we surveyed the required abilities to the approach function suitable for both attentive and inattentive Target, and then, we assumed that Robot had to have abilities to distinguish the poses of inattentive Target from attentive Target, to measure distances to Target, and to warn Target. And for simplifying an environment of approach function, we supposed that Robot would approach Target in a wide indoor hallway.

Figure 8 shows the environment where Robot approaches.

Fig. 8

Environment where Robot approaches Target

And then, we designed a hardware configuration of Robot with the abilities to recognize the pose of Target, to measure the distance to Target, and to warn Target in addition to a basic ability to move Robot, based on the model of Robot shown in Fig. 5.

Therefore, we adopted Kinect unit to recognize and distinguish the pose of Target in Kinect subsystem, the laser range finder (LRF) unit to measure the distance to Target in LRF subsystem, a speaker unit to warn Target in Warning for Target subsystem, and a drive unit to move Robot in Motor drive subsystem.

Figure 9 shows a hardware configuration of Robot.

Fig. 9

Hardware configuration of Robot

And then, we defined the configuration of product sample including the environment of the approach function on RTM. This configuration consisted of Robot and Target. And Robot consisted of Commander subsystem, Kinect subsystem, LRF subsystem, Master controller, Warning for Target subsystem and Motor drive subsystem as follows:

• Commander subsystem specifies movements of Robot, by a velocity.

• Kinect subsystem analyzes the pose of Target, and then outputs the attentiveness of Target as the result of analysis.

• LRF subsystem analyzes the distance to Target, and then outputs the size of Target, the relative position to Target, and the relative velocity to Target as the results of analysis.

• Master controller evaluates information from Commander subsystem, Kinect subsystem and LRF subsystem, and then outputs an appropriate velocity and an appropriate warning level as results of approach function. And, Master controller also has an ability to visualize movements and positions of Robot and Target, and key values for monitoring a simulation status and an experiment status.

• Warning for Target subsystem warns Target with the warning level specified by input.

• Motor drive subsystem moves Robot with the velocity specified by input.

• Target is monitored by Kinect subsystem and LRF subsystem, and is warned by Warning for Target subsystem. And Target monitors a distance to Robot, and then recognizes a velocity of Robot.

Figure 10 shows the configuration of the product sample.

Fig. 10

Configuration of product sample

On the basis of Fig. 10, we defined a configuration of design solution for MBS. This configuration consisted of a device model of Robot and UM of Target with sensor subsystems. And the device model of Robot consisted of Commander subsystem, Warning for Target subsystem, Motor drive model subsystem, and Master controller. And, UM of Target with sensor subsystems consisted of Target, Kinect subsystem, and LRF subsystem.

Figure 11 shows the configuration of the design solution for MBS.

Fig. 11

Configuration of design solution for MBS

And then, we defined variables and formulas as follows. The subscript x means the direction for Robot to move.

• 1. TD ^{personal space} _x [mm]: Personal space of Target as the appropriate distance to Target for Robot to stop.

• 2. TD ^{start deceleration} _x [mm]: Appropriate distance to Target for Robot to start deceleration.

• 3. TD ^slowdown _x [mm]: Specified distance to Target for Robot to start slowdown.

• 4. t _n [s]: Time from when Robot started movement.

• 5. t ^stopped _n [s]: Time when Robot stopped.

• 6. t ^warned _n [s]: Time when Robot warned Target.

• 7. t ^approach _n [s]: Time from when Robot started deceleration.

• 8. Tv ^absolute _x (t _n ) [mm]: Velocity of Target.

• 9. TAt(t _n ) [s]: Attentiveness of Target.

• 10. Cv ^specified _x (t _n ) [mm/s]: Velocity being specified by Commander subsystem.

• 11. TD ^relative _x (t _n ) [mm]: Distance to Target from Robot, which is measured by LRF subsystem. And this value is calculated by UM of Target in MBS with following formula.

  $$ TD_{x}^{relative}( {t_{n} }) = TD_{x}^{relative} \left( {t_{n - 1} } \right) - Tv_{x}^{relative } \left( {t_{n - 1} } \right)*\left( {t_{n} - t_{n - 1} } \right) $$

  (3)

• 12. Tv ^relative _x (t _n ) [mm/s]: Relative velocity to Target from Robot.

  $$ Tv_{x}^{relative } ( { t_{n} } ) = \frac{{TD_{x}^{relative} \left( { t_{n - 1} } \right) - TD_{x}^{relative} \left( { t_{n} } \right)}}{{t_{n} - t_{n - 1} }} $$

  (4)

• 13. D ^notify _x (t _n ) [mm]: Distance to Target from Robot where Robot warns Target.

  $$ D_{x}^{notify} ( {t_{n} }) = TD_{x}^{slowdown} + TAt\left( {t_{n} } \right)*Tv_{x}^{relative } \left( { t_{n} } \right) $$

  (5)

• 14. D ^approach _x (t _n , t ^approach _n ) [mm]: Distance to the border of personal space of Target from Robot when Robot is approaching.

  $$ D_{x}^{approach} ( {t_{n} ,t_{n}^{approach} } ) = D_{x}^{notify} \left( {t_{n} } \right) - TD_{x}^{personal space} - Tv_{x}^{ relative} (t_{n - 1} )*\left( {t_{n}^{approach} - t_{n - 1}^{approach} } \right) $$

  (6)

• 15. Rv ^absolute _x (t _n ) [mm/s]: Velocity of Robot. If TD ^relative _x (t _n ) > D ^notify _x (t _n ) then Robot keeps specified velocity as follow.

  $$ Rv_{x}^{absolute} \left( {t_{n} } \right) = Cv_{x}^{specified} \left( {t_{n} } \right) $$

  (7)

  Else if TD ^relative _x (t _n ) > TD ^{personal space} _x then Robot decelerates as follow.

  $$ Rv_{x}^{absolute} ( {t_{n} } ) = Rv_{x}^{absolute} \left( {t_{n - 1} } \right)*\left( {1 - \frac{{Rv_{x}^{absolute} \left( {t_{n - 1} } \right)*\left( {t_{n} - t_{n - 1} } \right) }}{{D_{x}^{approach} \left( {t_{n - 1} ,t_{n - 1}^{approach} } \right)}}} \right) $$

  (8)

  Else Robot stops as follow.

  $$ Rv_{x}^{absolute} ( {t_{n} } ) = 0 $$

  (9)

• 16. PHS _{at stop} [0_worst – 1_best]: Physical safety of Target at stop, by the ratio of actual distance when Robot stopped to the appropriate distance determined by the personal space. 0 means that Robot collided Target.

  $$ PHS_{at stop} = \frac{{TD_{x}^{relative} \left( {t_{n}^{stopped } } \right) }}{{TD_{x}^{personal space} }} $$

  (10)

• 17. PSS _{at warned} [0_worst – 1_best]: Psychological security of Target at warned, by the ratio of actual distance when Robot warned Target to the appropriate distance to warn. 1 means that Target became attentive at the appropriate distance.

  $$ PSS_{at warned} = \frac{{TD_{x}^{relative} \left( {t_{n}^{warned } } \right) }}{{TD_{x}^{start deceleration} + TAt\left( {t_{n}^{warned} } \right)*Tv_{x}^{relative} \left( {t_{n}^{warned } } \right)}} $$

  (11)

On the basis of the configuration shown in Fig. 11, we defined a configuration of design solution for MBS on RTM.

Figure 12 shows the configuration for MBS on RTM.

Fig. 12

Configuration for MBS on RTM

• Motor drive model subsystem consists of SEvMotorDrive_Model0.

• Warning for Target subsystem consists of SEvSound_Unit_4_Target0.

• Master controller consists of SE_Master_Controller0.

• Commander subsystem consists of SEvCommander0.

• UM of Target with sensor subsystems consists of SEvTarget_Model0.

Evaluate the designs against requirements by MBS on RTM

As the 4th step of MBD/UM as HCD cycle, design solutions have to be evaluated against the user requirements. Therefore, we evaluated the design solution against requirements by MBS on RTM with the configuration shown in Fig. 12.

Figure 13 shows a screenshot at MBS by the ability to visualize movements and positions of Robot and Target, and the ability to visualize distances from Robot for notifying, for starting deceleration, and for stopping.

Fig. 13

Screenshot at MBS

In Fig. 13, “Robot” is the position of the center of the front of Robot, “Target” is the position of the center of the front of Target, D ^notify _x is the calculated distance for notification, TD ^slowdown _x is the specified distance for starting deceleration, and TD ^{personal space} _x is the specified distance to stop by the personal space of Target.

Produce product sample on RTM

As the 1st additional step to HCD process in MBD/UM, a product sample has to be produced on the basis of the design solution. Therefore on the basis of the configuration of product sample shown in Fig. 10, we produced a product sample on RTM by using a concierge-type robot developed by Vector Inc., Japan as the base of Robot.

Basic hardware specifications of Robot are as follows:

• External dimensions: Width 455 mm / Depth 455 mm / Height 1200 mm.

  Maximum velocity: 500 mm/s. (By pre-experiment)

The specifications of Kinect unit are as follows:

• Operation range: 0.8–3.5 m.

  Field of view: Horizontally 58° / Vertically 45° / Diagonally 70°.

The specification of LRF unit is as follows:

• Maximum measuring distance and angle: 5600 mm / 240°.

Figure 14 shows the configuration of the product sample on RTM. We replaced UM of Target with sensor subsystems by LRF subsystem and Kinect subsystem, and replaced Motor drive model subsystem by Motor drive subsystem.

Fig. 14

Configuration of product sample on RTM

• LRF subsystem consists of SEvLRF_Monitor0 and LRFCapture_URG0 (from the National Institute of Advanced Industrial Science and Technology).

• Kinect subsystem consists of SEvKINECT_Monitor0 and RT_Kinect_UserTracking0 (from the National Institute of Advanced Industrial Science and Technology).

• Motor drive subsystem consists of TRobotRTC0 (from the Tokyo Metropolitan Industrial Technology Research Institute).

Certify the product sample on RTM

As the 2nd additional step to HCD process in MBD/UM, the product sample has to be certified to meet against user requirements. At first, we verified the compatibility of each actual subsystem with hardware in Fig. 14 with the corresponding subsystem by model in Fig. 12, by replacing the subsystem by model with the actual subsystem(s) with hardware, in Fig. 12. In this way, we certified the compatibility of LRF subsystem and Kinect subsystem with UM of Target with sensor subsystems, and the compatibility of Motor drive subsystem with Motor drive model subsystem.

After the verification of each subsystem, we certified the product sample on RTM with the configuration in Fig. 14.

Figure 15 shows the screenshots of pose of an attentive Target not operating a mobile phone and an inattentive Target operating a mobile phone by Kinect unit.

Fig. 15

Screenshots of attentive Target and inattentive Target

Results

This section shows the results of evaluation of the design solution and the result of certification of the product sample.

Results of evaluation by MBS

We evaluated the design solution against requirements by MBS, with the configuration shown in Fig. 12. In this study, Robot was smaller and slower than typical adults, then we assumed that we could apply the values and formulas derived from the surveys with test participants as follows:

• Cv _x ^specified(t _n ) [mm/s]: 470. 470 mm/s is the velocity specified at evaluation and certification.

• Tv ^absolute _x (t _n ) [mm/s]: 0. 0 mm/s means that UM of Target is standing.

• TD _x ^{personal space}[mm]: 700. 700 mm is the average distance of the result of the survey on personal space for talking shown in Table 3 as the appropriate distance to stop for UM of Target.

• TD _x ^slowdown [mm]: 700/1600. We studied the differences in the sense of psychological security between the sudden stop and the decelerated stop. 700 mm was the value for the experiment of sudden stop around the border of personal space, and 1600 mm was the average value of distance to start deceleration shown in Table 4 as the appropriate distance to start deceleration for UM of Target. 1600 mm was the average distance to start deceleration at the average velocity of 860 mm/s. We assumed that this average distance could be applied also at the velocity of 470 mm/s because we assumed that the distance for deceleration from 470 mm/s would be shorter than the distance for deceleration from 860 mm/s.

• TAt (t _n ) [s]: 0.0/1.4. We studied the differences in psychological security between attentive Target and inattentive Target. 0.0 s was the reflex time of attentive Target, and 1.4 s was the worst reflex time of inattentive Target in Table 5 for UM of Target.

Table 7 shows the result of the evaluation by MBS. By the result, we confirmed that TD ^relative _x at which a warning was issued was similar to D ^notify _x and that TD ^relative _x at which a stop was issued was similar to TD ^{personal space} _x .

Table 7 Result of evaluation by MBS

Table 8 shows the result of the evaluation regarding physical safety and psychological security. By the result, we confirmed that PHS _{at stop} was always very good and PSS _{at warned} was very good when Robot approached by deceleration.

Table 8 Physical safety and psychological security at MBS

Results of certification of product sample

We certified the approach function on the product sample with 4 test participants. For comparing results at certification with the results at the evaluation, we applied the same values and the same formulas which we applied at evaluation as follows:

• Cv ^specified _x (t _n ) [mm/s]: 470

• Tv ^absolute _x (t _n ) [mm/s]: 0 (Test participant was standing.)

• TD ^{personal space} _x [mm]: 700

• TD ^slowdown _x [mm]: 700/1600

• TAt (t _n ) [s]: 0.0/1.4

Table 9 shows the result of certification by experiment. By the result, we confirmed that TD ^relative _x at which Robot warned was similar to D ^notify _x , and TD ^relative _x at which Robot stopped was similar to TD ^{personal space} _x , as we produced the sample product.

Table 9 Result of certification by experiment

Table 10 shows the result of certification regarding physical safety and psychological security. By the result, we confirmed that PHS _{at stop} was always very good and PSS _{at warned} was very good when Robot approached by deceleration.

Table 10 Physical safety and psychological security at certification

The approach function on the product sample was certified safely with the test participants. And the results at the certification were very similar with the results at the evaluation by MBS.

And by a questionnaire after the examination in the certification, we also surveyed the psychological security when Robot stopped and the sense of time which Robot took till stop.

Table 11 shows the result of the questionnaire regarding the psychological security and the sense of time till stop.

Table 11 Psychological security and sense of time till stop

By the result of questionnaire, we confirmed that the psychological security was very good and the sense of time till stop was appropriate for both the attentive Target and the inattentive Target, when Robot decelerated to a stop. And we also found that the psychological security was inadequate when Robot stopped suddenly even though the distance to Target was similar to that in the case of Robot stopping under deceleration.

And the tendencies of the answers to the question regarding the psychological security were similar to the tendencies of the results of PSS _{at warned} in the experiment. This means that PSS _{at warned} could be used as an evaluation criteria of psychological security.

Discussion

We studied the approach function with physical safety as the usability and psychological security as UX on Robot by using MBD/UM for HCD.

At first, we understood and specified the context of use by Persona. Persona was found to be effective to describe a profile of user and context of use of Robot because Persona could be a user profiling method.

And we specified user requirements by MBSE. MBSE was effective to describe the user requirements and models because the user requirements and the models could be defined by various diagrams in MBSE, such as the requirement diagram and the state machine diagram.

Then, we produced a design solution to meet user requirements for MBS on RTM. For producing the design solution, MBD was effective to produce a device model of Robot and UM of Target as subsystems for MBS on RTM without the need for developing any new hardware.

And then, we evaluated the design against requirements by using MBS on RTM, and we confirmed that the design solution met the user requirements.

After the evaluation of the design solution to meet the user requirements, we verified each actual subsystem in the configuration for MBS on RTM in Fig. 12, by replacing each subsystem by model in Fig. 12 with corresponding actual subsystem(s) with hardware in Fig. 14.

After verifying each actual subsystem, we produced a product sample on RTM by replacing all the subsystems by model with the corresponding actual subsystems with hardware and we certified the product sample on RTM.

The analyses of the results of the experiment and questionnaires regarding the physical safety as the usability led us to the following conclusion:

• By the ability for Robot to stop automatically at the border of personal space, we could reduce the risk for Robot to collide with Target; thereby, the physical safety was guaranteed.

Furthermore, we concluded the followings regarding the psychological security as UX:

• By the ability for Robot to decelerate to a stop at the appropriate distance, both the attentive Target and the inattentive Target felt that the time till stop was appropriate and the psychological security was very good. On the other hand, both the attentive Target and the inattentive Target felt that the time till stop was too short and the psychological security was very bad, against the sudden stop.

• By the ability for Robot to warn Target at the appropriate distance that was adjusted by adding a distance related to a reflection time based on the attentiveness of Target, the inattentive Target could notice Robot approaching and became attentive. Therefore, in the case of the decelerated stop approach, the inattentive Target felt the same psychological security as the attentive Target felt. And even in the case of the sudden stop approach, Target felt a little better psychological security.

By the results of the analysis after certification, we also confirmed that we completed the approach function on the product sample with the physical safety and psychological security for both attentive people and inattentive people in accordance with MBD/UM for HCD, with the ability to stop at the border of personal space, the ability to start deceleration at the appropriate distance, and the ability to warn Target at the appropriate distance according to the attentiveness of Target.

Conclusions

The aim of this study was to complete the approach function which satisfied the user requirements on a concierge-type robot by applying MBD/UM as a practical HCD process with the advantages as follows:

• To reduce time and cost required to produce the hardware of the product sample at evaluation.

• To evaluate the product by simulation, under various conditions and also repeatedly under the same condition.

• To eliminate risks injuring test participants in the evaluation, and to reduce the risks in the certification.

We completed the approach function on Robot which satisfied the user requirements by implementing the physical safety as the usability and the psychological security as UX, by MBD/UM for HCD.

By conducting evaluations with models without product sample until the design solution met the user requirements, we reduced the time and cost required to produce the hardware of the product sample at evaluation of the approach function. And we could produce the product sample based on the design solution which had been evaluated by models.

By the evaluation with UM of attentive Target and inattentive Target, we confirmed that design solution could be evaluated by MBS under various conditions and also repeatedly under the same condition.

And by the evaluation with UM instead of actual stakeholder, we confirmed that MBD/UM eliminated risks to injure test participants at the evaluation. And then by the verification of each actual subsystem in MBS, we confirmed that MBD/UM reduced risks to injure test participants at the certification with the actual product sample and the actual stakeholder.

Then, we completed the study of the approach function by MBD/UM as a practical HCD process with the advantages.

In the further study, we will continue to research the required functions on concierge-type robot including the functions for personalization, by MBD/UM for HCD.