WO2020031718A1 - 制御装置、制御方法、およびプログラム - Google Patents

制御装置、制御方法、およびプログラム Download PDF

Info

Publication number
WO2020031718A1
WO2020031718A1 PCT/JP2019/029181 JP2019029181W WO2020031718A1 WO 2020031718 A1 WO2020031718 A1 WO 2020031718A1 JP 2019029181 W JP2019029181 W JP 2019029181W WO 2020031718 A1 WO2020031718 A1 WO 2020031718A1
Authority
WO
WIPO (PCT)
Prior art keywords
state transition
robot
failure
unit
state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2019/029181
Other languages
English (en)
French (fr)
Inventor
淳 入江
洋貴 鈴木
栄良 笠井
匡伸 中村
アンドリュー シン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to US17/263,854 priority Critical patent/US12233556B2/en
Priority to CN201980051303.7A priority patent/CN112512763B/zh
Priority to JP2020536453A priority patent/JP7310820B2/ja
Priority to EP19846081.8A priority patent/EP3835008A4/en
Publication of WO2020031718A1 publication Critical patent/WO2020031718A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Program-controlled manipulators
    • B25J9/16—Program controls
    • B25J9/1674—Program controls characterised by safety, monitoring, diagnostic
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Program-controlled manipulators
    • B25J9/16—Program controls
    • B25J9/1656—Program controls characterised by programming, planning systems for manipulators
    • B25J9/1661—Program controls characterised by programming, planning systems for manipulators characterised by task planning, object-oriented languages
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/04—Program control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Program control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0428—Safety, monitoring

Definitions

  • the present technology relates to a control device, a control method, and a program, and more particularly, to a control device, a control method, and a program that can prevent a failure of a robot operation before it occurs.
  • Patent Literature 1 discloses a technique for determining whether an operation is correct based on a time-series pattern of sensor output data expected when the operation is successful and a time-series pattern of the sensor output data during operation. I have. Each broken line portion of the time-series pattern is treated as one state, each node is treated as an event for a state change, and an allowable range is set for each state and the event to monitor a state transition.
  • the user needs to set an allowable range for each state and event. Further, it is not possible to automatically update the time-series pattern of sensor output data expected when the operation is successful, or to perform recovery when it is determined that the operation fails.
  • the robot can automatically update the data used as a criterion for judging whether the operation is successful or not, and if the operation is judged to have failed, the robot can automatically restart the operation.
  • the present technology has been made in view of such a situation, and is intended to prevent a robot operation failure from occurring.
  • the control device may lead to a failure of the task when the transition of the state of the robot at the time of executing the task follows a failure state transition set in advance as a state transition leading to the failure of the task.
  • a state transition determining unit that controls an operation of the robot so as to perform a predetermined process.
  • the transition of the state of the robot at the time of execution of the task follows a failure state transition that is set in advance as a state transition that leads to failure of the task, a predetermined state before the task failure occurs.
  • the operation of the robot is controlled so as to perform the above processing.
  • FIG. 3 is a block diagram illustrating a hardware configuration example of a robot.
  • FIG. 3 is a block diagram illustrating a functional configuration example of a control unit. It is a flowchart explaining a failure state transition generation process. It is a flowchart explaining a control process.
  • FIG. 21 is a diagram illustrating another example of updating a failed state transition related to the task of “grabbing an object”. It is a block diagram showing other examples of functional composition of a control part. It is a block diagram which shows the example of a structure of a failure state transition update part.
  • FIG. 11 is a diagram illustrating a first example of a failure state transition including recovery regarding the task of “grabbing an object”.
  • FIG. 14 is a diagram illustrating a second example of a failure state transition including recovery regarding the task of “grabbing an object”.
  • FIG. 11 is a diagram illustrating a first example of a failure state transition including recovery regarding the task of “handing an object to a person”.
  • FIG. 14 is a diagram illustrating a second example of a failure state transition including recovery relating to the task of “handing an object to a person”. It is a block diagram showing other examples of functional composition of a control part.
  • FIG. 4 is a block diagram illustrating a configuration example of a recovery control unit. It is a flowchart explaining a recovery execution process. It is a figure showing the example of composition of a control system.
  • FIG. 18 is a block diagram illustrating a configuration example of a computer.
  • FIG. 1 is a diagram illustrating an example of an external appearance of a robot according to an embodiment of the present technology.
  • the robot 1 shown in FIG. 1A is an arm type robot.
  • the robot 1 includes a base unit 11, an arm unit 12 extending from the base unit 11, and a hand unit 13 attached to a tip of the arm unit 12.
  • the robot 1 is provided in a factory or the like, and performs a predetermined task such as grasping and moving an object.
  • a robot 2 which is a humanoid robot capable of bipedal walking as shown in FIG. 1B may be used.
  • the robot 2 also has an arm portion and the like, and can move an object by grasping it.
  • the robots 1 and 2 shown in FIG. 1 execute a predetermined program by a built-in computer, and take an autonomous action by driving each part.
  • processing performed in the robot 1 which is an arm type robot will be described as appropriate.
  • the same processing as the processing performed by the robot 1 is performed by the robot 2 or a robot of another shape such as a robot that can walk on four legs.
  • the robot 1 When performing a task such as grabbing and moving an object, the robot 1 monitors its own state at each timing. When the state transition of the robot 1 is following the same transition as the failure state transition that is the state transition leading to the task failure, the robot 1 warns the user before reaching the failure state. Perform an action.
  • the robot 1 has failed state transition information that is information indicating failed state transition for each task.
  • the failure state transition information is generated in advance at a predetermined timing and prepared in the robot 1.
  • the state includes an operation and an event.
  • the operation represents an event that the robot 1 actively performs. Events such as “moving the arm” and “recognizing” are included in the operation.
  • the event represents a passive event detected in the robot 1. An event such as “lost” is included in the event.
  • each state is not represented by a value, but it is determined whether or not the state of the robot 1 corresponds to each state.
  • the state includes recognition results such as an image recognition result, an abnormal sound detection result, and an odor detection result.
  • the state also includes a recognition result, such as the shape, slipperiness, and softness, of the object specified by gripping the object.
  • FIG. 2 is a diagram showing an example of a failed state transition.
  • the failure state transition shown in FIG. 2 represents a state transition that leads to failure of the task of “grabbing an object”.
  • the task of “grabbing an object” is, for example, a task of recognizing, grasping, and lifting an object placed near the robot 1.
  • the state of the robot 1 is first a state # 1 in which the arm unit 12 is raised, and then a state # in which the object to be grasped is recognized # It becomes 2.
  • the object to be grasped is recognized based on, for example, an image captured by a camera or sensor data detected by a sensor.
  • the state of the robot 1 is the state # 3 in which the arm 12 is moved.
  • the robot 1 drives each unit to move the arm unit 12. If the arm unit 12 is not moved, it is treated as not causing a task failure.
  • the state of the robot 1 is the state # 4 in which the object to be grasped has been lost.
  • a warning action is executed as indicated by the arrow A1.
  • the robot 1 drives a speaker or the like to warn the user by voice that the object to be grasped has been lost. If the object to be grasped is not lost, it is treated as not causing a task failure.
  • the state becomes the state # 4 in which the object to be grasped is lost, and after the warning action is performed, it is determined whether or not the arm unit 12 is further moved.
  • the state of the robot 1 is a state # 5 in which the arm 12 is moved.
  • state # 5 When the state is changed to state # 5, it is determined that the task is in a pre-failure state, which is a state before the task reaches a failure, and an emergency stop action is executed as indicated by the arrow A2.
  • the robot 1 stops driving each unit and does not move the arm unit 12. By not moving the arm unit 12, the task does not fail.
  • the state transition composed of states # 1 to # 5 is set as a failure state transition when the task of “grabbing an object” is executed.
  • a warning or emergency stop action is executed.
  • the robot 1 can be moved to the pre-failure state by urgently stopping the operation when the user attempts to move the arm unit 12 by following the failed state transition even after losing the object to be grasped and issuing a warning, thereby performing the task 1 Can be prevented, and it is possible to prevent the arm portion 12 or the like from hitting a surrounding object.
  • FIG. 3 is a diagram showing another example of the failure state transition.
  • the failure state transition shown in FIG. 3 represents a state transition that leads to the failure of the task of “handing an object to a person”.
  • the task of “handing an object to a person” is, for example, a task of holding an object placed in the vicinity of the robot 1, inserting the object forward of a nearby person, and releasing the object to hand the object to the person.
  • the state of the robot 1 is first a state # 11 in which the object is held by the hand unit 13, and then the hand unit 13 is put in front of the person.
  • State # 12 The operation of holding the object is realized by recognizing the target object based on the output of a sensor such as a camera, and driving the arm unit 12 and the hand unit 13.
  • the state of the robot 1 is the state # 13 in which the human hand is not touching the object.
  • a warning action is executed as indicated by the arrow A11.
  • the robot 1 drives a speaker or the like to warn the user by voice that the hand is not touching the object. If a human hand touches the object, it is treated as if it did not cause the task to fail.
  • the state is the state # 13 in which the human hand is not touching the object, and after the warning action is executed, it is determined whether or not the hand 13 is looking at the object that is being put out. Whether or not the user is looking at the object is determined based on, for example, the direction of the line of sight of the person specified by analyzing an image captured by the camera.
  • the state of the robot 1 is the state # 14 in which the person does not look at the object.
  • a warning action is executed as indicated by the point of the arrow A12.
  • the robot 1 drives a speaker or the like to warn the user by voice that he or she concentrates on viewing the object. If a person is looking at the object, it is treated as if the task did not fail.
  • the state is state # 14 in which a person is not looking at the object. After the warning action is executed, it is determined whether or not the force of the hand unit 13 holding the object is relaxed.
  • the state of the robot 1 is a state # 15 in which the force of the hand unit 13 for grasping an object is relaxed. If the force of the hand unit 13 for gripping the object is not loosened, it is treated as not causing a task failure.
  • the state transition consisting of states # 11 to # 15 is set as a failure state transition when the task of “handing an object to a person” is executed.
  • a warning or emergency stop action is executed.
  • the robot 1 can be brought into a pre-failure state and perform an operation for grasping the object again. Can prevent a task from failing and prevent a falling object from being dropped.
  • the failed state transition is set for each task, and information representing such a transition is prepared in the robot 1.
  • the robot 1 determines that the task will fail if the transition of its own state follows the same transition as the failure state transition, and performs an optimal operation according to the task before actually failing. , It is possible to prevent failure.
  • FIG. 4 is a block diagram illustrating a hardware configuration example of the robot 1.
  • the robot 1 is configured by connecting the input / output unit 32, the driving unit 33, the wireless communication unit 34, and the power supply unit 35 to the control unit 31.
  • the control unit 31 is configured by a computer having a CPU (Central Processing Unit), a ROM (Read Only Memory), a RAM (Random Access Memory), a flash memory, and the like.
  • the control unit 31 executes a predetermined program by the CPU and controls the entire operation of the robot 1.
  • the computer constituting the control unit 31 functions as a control device that controls the operation of the robot 1.
  • control unit 31 monitors its own state based on information supplied from the input / output unit 32 and information supplied from each drive unit of the drive unit 33.
  • control unit 31 determines whether or not the transition of its own state follows the same transition as the failed state transition based on the failed state transition information of the task. When determining that the transition of its own state is following the same transition as the failure state transition, the control unit 31 executes a predetermined action before actually causing a failure.
  • the input / output unit 32 includes a camera 41, a microphone (microphone) 42, a speaker 43, a touch sensor 44, and an LED (Light Emitting Diode) 45.
  • the camera 41 sequentially captures the surrounding environment.
  • the camera 41 outputs data of a captured image, which is a still image or a moving image, obtained by shooting to the control unit 31.
  • the microphone 42 detects the environmental sound.
  • the microphone 42 outputs environmental sound data to the control unit 31.
  • the speaker 43 outputs a predetermined sound such as an uttered voice and BGM.
  • the touch sensor 44 is provided at a predetermined portion such as the base unit 11. Touch sensor 44 detects that the user has touched, and outputs information representing the content of the operation by the user to control unit 31.
  • the LED 45 emits light under the control of the control unit 31 to present information to the user.
  • a small display such as an LCD or an organic EL display may be provided.
  • the input / output unit 32 is provided with various modules such as a distance measuring sensor for measuring a distance to a surrounding object and a positioning sensor such as a GPS (Global Positioning System).
  • a distance measuring sensor for measuring a distance to a surrounding object
  • a positioning sensor such as a GPS (Global Positioning System).
  • the driving unit 33 drives according to the control of the control unit 31 to realize the action of the robot 1.
  • the drive unit 33 is configured by a plurality of drive units provided for each joint axis such as roll, pitch, and yaw.
  • Each drive unit is provided at each joint of the robot 1, for example.
  • Each drive unit is configured by a combination of a motor that rotates around an axis, an encoder that detects the rotational position of the motor, and a driver that adaptively controls the rotational position and rotational speed of the motor based on the output of the encoder.
  • the hardware configuration of the robot 1 is determined by the number of drive units, the positions of the drive units, and the like.
  • the drive units 51-1 to 51-n are provided as drive units.
  • the drive unit 51-1 includes a motor 61-1, an encoder 62-1 and a driver 63-1.
  • the drive units 51-2 to 51-n have the same configuration as the drive unit 51-1.
  • the wireless communication unit 34 is a wireless communication module such as a wireless LAN module and a mobile communication module compatible with LTE (Long Term Evolution).
  • the wireless communication unit 34 communicates with an external device such as a server on the Internet.
  • the wireless communication unit 34 transmits the data supplied from the control unit 31 to an external device, and receives data transmitted from the external device.
  • the power supply unit 35 supplies power to each unit in the robot 1.
  • the power supply unit 35 includes a charge battery 71 and a charge / discharge control unit 72 that manages a charge / discharge state of the charge battery 71.
  • FIG. 5 is a block diagram showing a functional configuration example of the control unit 31.
  • the control unit 31 includes an operation output unit 101, an operation acquisition unit 102, a failure state transition determination unit 103, a failure state transition storage unit 104, a failure state transition generation unit 105, and a drive control unit 106. Is done. At least a part of the functional units shown in FIG. 5 is realized by executing a predetermined program by the CPU constituting the control unit 31.
  • the operation output unit 101 receives the information supplied from each drive unit of the drive unit 33 and outputs the information to the operation acquisition unit 102.
  • the motion acquisition unit 102 detects the content of the motion of the robot 1 based on the information supplied from the motion output unit 101.
  • the operation acquisition unit 102 outputs information indicating the content of the operation to the failure state transition determination unit 103.
  • the failed state transition determination unit 103 When executing a predetermined task, the failed state transition determination unit 103 reads and acquires information indicating a failed state transition of the task to be executed from the failed state transition storage unit 104.
  • the failure state transition determination unit 103 specifies the state of the robot 1 based on the operation represented by the information supplied from the operation acquisition unit 102, and determines whether the transition of its own state follows the same transition as the failure state transition Determine whether or not.
  • the failed state transition determination unit 103 controls the drive control unit 106 based on the determination result of the state transition. For example, when the failed state transition determination unit 103 determines that its own state transition does not follow the same transition as the failed state transition, it causes each operation until the task succeeds. In addition, when the failure state transition determination unit 103 determines that its own state transition follows the same transition as the failure state transition, the failure state transition determination unit 103 executes a preset action.
  • the failure state transition storage unit 104 stores failure state transition information of each task.
  • the failed state transition generation unit 105 sets the failed state transition of each task and generates failed state transition information.
  • the failure state transition generation unit 105 outputs the failure state transition information to the failure state transition storage unit 104 and stores the information.
  • the drive control unit 106 controls each drive unit of the drive unit 33 based on the information supplied from the failure state transition determination unit 103 to perform a predetermined operation.
  • step S1 the failed state transition generator 105 sets a failed state transition of a predetermined task.
  • the setting of the failure state transition may be performed, for example, according to the operation of the administrator of the robot 1.
  • step S2 the failed state transition generating unit 105 outputs the failed state transition information to the failed state transition storage unit 104 and stores the information.
  • the above processing is performed for each task.
  • the failed state transition storage unit 104 stores failed state transition information for each task.
  • the failed state transition determination unit 103 specifies the state of the robot 1 based on the operation represented by the information supplied from the operation acquisition unit 102. From the motion acquisition unit 102, information on how the robot 1 is moving (moving the arm unit 12 up, moving forward, etc.) and what information the robot 1 has obtained (image / voice recognition result, other sensor , Etc.) is supplied as information representing the content of the operation.
  • step S12 the failed state transition determination unit 103 applies the state of the robot 1 to the failed state transition.
  • step S13 the failure state transition determination unit 103 determines whether the state transition of the robot 1 follows the same transition as the failure state transition, and a transition to execute an action has occurred.
  • step S13 If it is determined in step S13 that the transition for executing the action has not occurred, the failure state transition determination unit 103 returns to step S11 and repeats the above-described processing.
  • step S14 the failure state transition determining unit 103 controls the drive control unit 106 to execute a predetermined action. As described above, depending on the state of the robot 1, actions such as warning to the user, emergency stop of the operation, and re-grip are performed.
  • the robot 1 can prevent a task from failing by performing an optimal operation before the task fails.
  • the failure state transition may be automatically updated by the robot 1. Updating of the failure state transition is performed, for example, when the number of times that the state has reached the pre-failure state is large.
  • FIG. 8 is a diagram illustrating a first example of updating a failed state transition related to the task of “grabbing an object”.
  • States # 21 to # 23 in FIG. 8 are the same as states # 1 to # 3 in FIG. After the state becomes the state # 23 in which the arm unit 12 is moved, it is determined whether or not the object to be grasped has been lost.
  • the state of the robot 1 is a state # 24 in which the object to be grasped has been lost.
  • the failure state transition of FIG. 8 As indicated by a broken line, when the state becomes the state # 24 in which the object to be grasped is lost, it is determined that the state before failure has been reached, and The emergency stop action is performed without warning. In other words, the failure state transition is updated so that the failure state is easily reached.
  • FIG. 9 is a diagram illustrating a second example of updating the failed state transition related to the task of “grabbing an object”.
  • States # 31 to # 33 in FIG. 9 are the same as states # 1 to # 3 in FIG. After the state becomes the state # 33 in which the arm unit 12 is moved, it is determined whether or not more than half of the object to be grasped is out of the angle of view.
  • the state of the robot 1 is a state # 34 in which more than half of the object to be grasped is out of the angle of view.
  • the robot 1 drives a speaker or the like to warn the user by voice that more than half of the object to be grasped has deviated from the angle of view.
  • the warning action is performed based on a stricter standard than the transition in FIG.
  • a warning action is executed when it is determined that, for example, the entire object to be grasped has deviated from the angle of view and the object has been lost. Since the state in which half of the object to be grasped deviates from the angle of view is a state that is more likely to occur than the state in which the entire object deviates from the angle of view, the failure state transition in FIG. 9 executes a warning action. It can be said that the standards are strict standards. In other words, the failed state transition is updated so that the failed state transition is easily traced.
  • FIG. 10 is a diagram illustrating a first example of updating a failed state transition related to the task of “handing an object to a person”.
  • the state is state # 43 in which the human hand is not touching the object, and after the warning action is performed, it is determined whether the human face is not facing the direction of the object.
  • the state of the robot 1 is a state # 44 in which the human face is not facing the direction of the object.
  • a warning action is executed as indicated by the point of the arrow A42.
  • the warning action is performed based on a stricter standard than the transition in FIG.
  • a warning action is executed. In other words, regardless of the direction of the face, the warning action is not executed as long as the gaze is directed toward the object.
  • the failure state transition in FIG. 10 is a stricter criterion for executing a warning action. It can be said that this is a transition using.
  • FIG. 11 is a diagram illustrating a second example of updating a failed state transition related to the task of “handing an object to a person”.
  • States # 51 and # 52 in FIG. 11 are the same as states # 11 and # 12 in FIG. After the state # 12 is reached in which the hand unit 13 holding the object is extended to the front of the person, it is determined whether or not the hand of the person is holding the object.
  • the state of the robot 1 is the state # 53 where the human hand is not holding the object.
  • a warning action is executed as indicated by the point of the arrow A51.
  • the warning action is executed based on a stricter standard than the transition in FIG.
  • a warning action is executed. In other words, even if the object is not grasped, the warning action is not executed as long as the hand is touched.
  • the failure state transition shown in FIG. 10 is a transition using a stricter criterion as a criterion for executing a warning action because the failure state transition is a criterion that requires more human attention in that it not only touches an object but actually grips it. You can say that.
  • FIG. 12 is a diagram illustrating another example of updating the failed state transition related to the task of “grabbing an object”.
  • the failure state transition shown in FIG. 12 differs from the failure state transition of FIG. 2 in that a state for executing a warning action is added.
  • States # 61 and # 62 in FIG. 12 are the same as states # 1 and # 2 in FIG. After the state becomes the state # 63 in which the arm unit 12 is moved, it is determined whether or not more than half of the object to be grasped is out of the angle of view.
  • the state of the robot 1 is a state # 64 in which more than half of the object to be grasped is out of the angle of view.
  • the transition after the warning action is executed is the same as the transition after state # 3 in FIG.
  • the failure state transition is updated so as to increase the number of states in which the action of the warning is performed, so that the failure of the task can be more reliably prevented.
  • FIG. 13 is a block diagram illustrating another functional configuration example of the control unit 31.
  • FIG. 13 The configuration shown in FIG. 13 is basically the same as the configuration shown in FIG. 5 except that a failed state transition update unit 107 is added. Duplicate descriptions will be omitted as appropriate.
  • the failed state transition updating unit 107 determines that it is time to update the failed state transition, the failed state transition updating unit 107 updates the failed state transition as described above. Whether or not it is time to update the failed state transition is determined based on the information supplied from the failed state transition determination unit 103.
  • the failure state transition update unit 107 outputs failure state transition information indicating the failure state transition after the update to the failure state transition storage unit 104 and stores it.
  • FIG. 14 is a block diagram illustrating a configuration example of the failure state transition update unit 107.
  • the failure state transition update unit 107 includes a failure information acquisition unit 131, an update determination unit 132, an update unit 133, an update determination criterion information storage unit 134, and an update transition information storage unit 135.
  • the failure information acquisition unit 131 acquires information related to task failure based on the information output from the failure state transition determination unit 103 (FIG. 13).
  • the failure information acquisition unit 131 specifies, for example, the number of times that the state has reached the pre-failure state, and outputs information indicating the specified number of times to the update determination unit 132.
  • the update determining unit 132 determines whether to update the failed state transition based on the information supplied from the failure information acquiring unit 131.
  • the update criterion information storage unit 134 stores update criterion information serving as a criterion for determining an update for each task.
  • Whether or not to update the failed state transition is determined, for example, by comparing the number of times the pre-failure state has been reached with the number of thresholds represented by the update determination criterion information. When the number of times the predetermined task has reached the pre-failure state exceeds the threshold number, the update determining unit 132 determines that the failed state transition of the task is to be updated, and outputs information indicating that to the updating unit 133. .
  • the update unit 133 updates the failed state transition determined to be updated based on the information stored in the update transition information storage unit 135.
  • the update transition information storage unit 135 stores information on how to update the failed state transition.
  • the updating unit 133 outputs and stores the failed state transition information indicating the failed state transition after the update to the failed state transition storage unit 104.
  • step S21 the failure information acquisition unit 131 acquires information related to task failure based on the information output from the failure state transition determination unit 103.
  • the failure information acquisition unit 131 acquires, as information relating to the failure, the number of times the state has reached the pre-failure state, details of the failure, and the severity of the failure.
  • the content of the failure is the cause of the above-mentioned action. For example, losing an object, human hand not touching the object, human not seeing the object, half of the object is out of the angle of view, human face is not facing the object, human hand is the object Is not obtained, is acquired as the content of the failure.
  • ⁇ Failure severity is the severity of reaching the pre-failure state. For example, whether there is a collision, whether an object has been dropped, whether an object or a wall has been broken, whether or not it has moved to the limit of the drive area, whether or not a person has been nearby, etc. The corresponding severity is obtained.
  • step S22 the update determining unit 132 determines whether or not the update condition of the failed state transition has been satisfied.
  • step S22 If it is determined in step S22 that the update condition is not satisfied, the process returns to step S21, and the above processing is repeated.
  • step S23 the updating unit 133 updates the failed state transition. Updating of the failed state transition is performed, for example, as in the following 1 to 3.
  • updating is performed so as to determine at an early stage that the pre-failure state has been reached, or so that the criterion for executing the action is a stricter criterion.
  • the state is updated so that it is determined at an early stage that the state has reached the state before the failure. Further, when the failure of the same content is repeated more than the threshold number of times, or when a failure occurs whose severity is higher than the threshold, the criterion for executing the action is updated to be a stricter criterion.
  • the failure state transition of FIG. 8 when the size of the object to be grasped is smaller than a predetermined size, the failure state transition of FIG. 8 is used, and when the size is larger than the predetermined size, the failure state transition of FIG. 9 is used.
  • the failure state transition to be used is switched according to the size of the object to be grasped.
  • the failure state transition of FIG. 10 is used, and if the person is an adult, the failure state transition of FIG. 11 is used. Is switched according to the attribute of the person to whom the object is to be delivered.
  • the user is prompted to update the condition by outputting a sound from the speaker 43 or the like.
  • step S24 the updating unit 133 stores the failed state transition information indicating the failed state transition after the update in the failed state transition storage unit 104, and ends the process.
  • the robot 1 can more reliably prevent the task from failing.
  • the recovery may be executed when the pre-failure state is reached.
  • Recovery is an operation that attempts to execute the task again.
  • FIG. 16 is a diagram illustrating a first example of a failed state transition including recovery regarding the task of “grabbing an object”.
  • the state is the state # 105 in which the arm unit 12 is moved, and if it is determined that the state is the state before the failure, the state of the robot 1 returns to the state # 101 again.
  • the robot 1 controls each unit so that the arm unit 12 is in a raised state.
  • the recovery is executed by the operation of controlling each unit so that the arm unit 12 is raised.
  • FIG. 17 is a diagram illustrating a second example of a failure state transition including recovery regarding the task of “grabbing an object”.
  • the state becomes the state # 115 in which the arm unit 12 is moved, and when it is determined that the state is before the failure, the robot 1 moves the arm unit 12 to the position where the object is recognized.
  • the state is the state # 116.
  • the robot 1 controls each unit to move the arm unit 12 to a position immediately before losing an object.
  • the object tracking parameter is a parameter for tracking an object based on an image captured by the camera 41.
  • the object tracking parameter includes information such as the moving speed of the arm 12.
  • the robot 1 updates the object tracking parameters by lowering the moving speed of the arm unit 12 so as not to lose sight of the object. Thereafter, the state of the robot 1 returns to the state # 112, and the same state transition is continued. In the example of FIG. 17, the recovery is executed by the operation of moving the arm unit 12 to a position immediately before losing the object and updating the object tracking parameter.
  • FIG. 18 is a diagram illustrating a first example of a failure state transition including recovery relating to the task of “handing an object to a person”.
  • the state is the state # 125 in which the force of the hand unit 13 gripping the object is relaxed, and if it is determined that the state is before the failure, the state of the robot 1 returns to the state # 121 again.
  • the robot 1 controls each unit including the hand unit 13 so as to hold the object. I do.
  • the recovery is executed by the operation of controlling each unit including the hand unit 13 so as to hold the object.
  • FIG. 19 is a diagram illustrating a second example of the failure state transition including recovery regarding the task of “handing an object to a person”.
  • the state is a state # 135 in which the force of the hand unit 13 gripping the object is relaxed, and if it is determined that the state is before failure, the state of the robot 1 is a state in which the object is gripped again. It becomes # 136.
  • the robot 1 controls each unit including the hand unit 13 so as to grasp the object again.
  • the state of the robot 1 is the state # 137 in which the user is warned to look at the object and to hold it with care. After giving such a warning by outputting a sound from the speaker 43 or the like, the robot 1 determines whether or not the person is looking at the object, and repeats the same state transition.
  • recovery is executed by an operation of controlling each unit including the hand unit 13 so as to grasp the object again and giving a warning to the user.
  • the failure state transition including the recovery is managed in the robot 1, and the recovery is executed when the robot 1 reaches the pre-failure state. Thereby, the robot 1 can prevent the task from failing and guide the task to success.
  • the recovery may be performed after the warning is issued.
  • FIG. 20 is a block diagram illustrating another functional configuration example of the control unit 31.
  • FIG. 20 The configuration shown in FIG. 20 is basically the same as the configuration shown in FIG. 5 except that a recovery control unit 108 is added. Duplicate descriptions will be omitted as appropriate.
  • the recovery control unit 108 determines that the state before the failure has been reached, the recovery control unit 108 controls the drive control unit 106 to execute the recovery. Whether the state has reached the pre-failure state is determined based on the information supplied from the failed state transition determination unit 103 or the information supplied from the drive control unit 106.
  • FIG. 21 is a block diagram showing a configuration example of the recovery control unit 108.
  • the recovery control unit 108 includes a failure information acquisition unit 151, a recovery determination unit 152, a recovery execution unit 153, a recovery criterion information storage unit 154, and a recovery state transition information storage unit 155.
  • the failure information acquisition unit 151 acquires information on task failure based on information output from the failure state transition determination unit 103 or the drive control unit 106.
  • the failure information acquisition unit 151 specifies, for example, the number of times the state has reached the pre-failure state, and outputs information indicating the specified number of times to the recovery determination unit 152.
  • the recovery determination unit 152 determines whether or not to execute recovery based on the information supplied from the failure information acquisition unit 151.
  • the recovery criterion information storage unit 154 stores recovery criterion information as a criterion for determining whether or not to execute recovery for each task.
  • Whether or not to execute recovery is determined, for example, by comparing the number of times the pre-failure state has been reached with the number of times of the threshold represented by the recovery criterion information. When the number of times the predetermined task has reached the pre-failure state exceeds the threshold, the recovery determination unit 152 determines that recovery is to be performed, and outputs information indicating that to the recovery execution unit 153.
  • the recovery execution unit 153 executes recovery based on the information stored in the recovery state transition information storage unit 155.
  • the recovery state transition information storage unit 155 stores information on a failed state transition including a recovery state.
  • the failure information acquisition unit 151 acquires the information on the failure of the task output from the failure state transition determination unit 103. For example, the failure information acquisition unit 151 acquires, as information relating to the failure, the number of times the state has reached the pre-failure state, the content of the failure, and the severity of the failure.
  • step S32 the recovery determining unit 152 determines whether to execute recovery.
  • the threshold number if the number of times that the state has reached the pre-failure state is equal to or greater than the threshold number, it is determined that recovery is to be performed. When a failure whose severity is lower than the threshold value occurs, it is determined that recovery is to be performed.
  • step S33 the recovery execution unit 153 performs the recovery.
  • step S34 the recovery execution unit 153 controls the drive control unit 106 to execute a predetermined action.
  • the robot 1 can prevent the task from failing by executing the recovery before the task fails.
  • the failure state transition may not be generated by the robot 1 itself, but may be generated by the robot 1 in response to an operation by the user. Further, failure state transition information generated in response to an operation by a user in an external device such as a PC may be provided to the robot 1 and used in the above-described processing.
  • Failure state transition information may be generated based on the failure state transition generated in the test stage of the operation of the robot 1 and provided to the robot 1. Information on what state transition is a failed state transition is specified by, for example, a user.
  • the user may set a state to be prevented from occurring, and the failure state transition information may be generated based on the state.
  • the operation of the robot 1 based on the failure state transition may be performed by an external device such as a server on the Internet.
  • FIG. 23 is a diagram showing a configuration example of a control system.
  • the control system in FIG. 23 is configured by connecting the robot 1 and the control server 201 via a network 202 such as the Internet.
  • the robot 1 and the control server 201 communicate via a network 202.
  • the state of the robot 1 is specified by the control server 201 based on information transmitted from the robot 1.
  • Information indicating the state of each device of the robot 1 is sequentially transmitted from the robot 1 to the control server 201.
  • the control server 201 controls the robot 1 to execute an action according to the state such as a warning action, an action at the time of task failure, and the like. .
  • control server 201 functions as a control device that monitors the state of the robot 1 and controls the operation of the robot 1 according to the state.
  • each functional unit of FIG. 5, FIG. 14, or FIG. 20 is realized by executing a predetermined program.
  • FIG. 24 is a block diagram illustrating a configuration example of hardware of a computer that executes the series of processes described above by a program.
  • the control server 201 in FIG. 23 has a configuration similar to the configuration shown in FIG.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • the input / output interface 1005 is further connected to the bus 1004.
  • the input / output interface 1005 is connected to an input unit 1006 including a keyboard and a mouse, and an output unit 1007 including a display and a speaker.
  • a storage unit 1008 such as a hard disk or a non-volatile memory
  • a communication unit 1009 such as a network interface
  • a drive 1010 for driving the removable medium 1011 are connected to the input / output interface 1005.
  • the CPU 1001 loads a program stored in the storage unit 1008 into the RAM 1003 via the input / output interface 1005 and the bus 1004 and executes the program, for example, to execute the above-described series of processing. Is performed.
  • the program executed by the CPU 1001 is recorded on the removable medium 1011 or provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital broadcasting, and is installed in the storage unit 1008.
  • a wired or wireless transmission medium such as a local area network, the Internet, or digital broadcasting
  • the program executed by the computer may be a program in which processing is performed in chronological order in the order described in this specification, or may be performed in parallel or at a necessary timing such as when a call is made. It may be a program that performs processing.
  • a system means a set of a plurality of components (devices, modules (parts), etc.), and it does not matter whether all components are in the same housing. Therefore, a plurality of devices housed in separate housings and connected via a network and one device housing a plurality of modules in one housing are all systems. .
  • the present technology can adopt a configuration of cloud computing in which one function is shared by a plurality of devices via a network, and processing is performed jointly.
  • each step described in the above-described flowchart can be executed by one device, or can be executed by being shared by a plurality of devices.
  • one step includes a plurality of processes
  • the plurality of processes included in the one step can be executed by one device or can be shared and executed by a plurality of devices.
  • the present technology can also have the following configurations.
  • a control device comprising a state transition determining unit that controls an operation of the robot.
  • the predetermined process is a warning to a user and an emergency stop of an operation of the robot.
  • the state transition determination unit after issuing a warning to the user as the predetermined processing, if the state transition of the robot follows the failed state transition, urgently stops the operation of the robot (2).
  • the control device according to item 1.
  • the control device according to any one of (1) to (3), further including an update unit that updates the failed state transition when the state transition of the robot follows the failed state transition.
  • the update unit updates the failed state transition when the number of times the failed state transition is followed exceeds a threshold number of times or according to the content of the state transition of the robot that has followed the failed state transition.
  • the control device according to (4).
  • (6) The control device according to (4) or (5), wherein the update unit updates the failed state transition so that the state transition of the robot easily follows the failed state transition.
  • the control device according to any one of (1) to (6), further including a recovery control unit that controls the robot so as to execute recovery when the state transition of the robot follows the failure state transition.
  • the control device (8) The control device according to (7), wherein the recovery control unit causes the recovery to be performed after the predetermined processing is performed. (9) The control device according to any one of (1) to (8), further including a storage unit that stores information indicating the failed state transition. (10) The control device is When the transition of the state of the robot at the time of execution of the task follows a failure state transition set in advance as a state transition leading to the failure of the task, a predetermined process is performed before the failure of the task occurs. A control method for controlling the operation of the robot. (11) On the computer, When the transition of the state of the robot at the time of execution of the task follows a failure state transition set in advance as a state transition leading to the failure of the task, a predetermined process is performed before the failure of the task occurs. A program for executing processing for controlling the operation of the robot.

Landscapes

  • Engineering & Computer Science (AREA)
  • Robotics (AREA)
  • Mechanical Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Manipulator (AREA)

Abstract

本技術は、ロボットの動作の失敗を未然に防ぐことができるようにする制御装置、制御方法、およびプログラムに関する。 本技術の一側面の制御装置は、タスクの実行時のロボットの状態の遷移が、タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、タスクの失敗に至る前に、所定の処理を行うようにロボットの動作を制御する状態遷移判断部を備える。本技術は、自律的に動作することが可能なロボットに適用することができる。

Description

制御装置、制御方法、およびプログラム
　本技術は、制御装置、制御方法、およびプログラムに関し、特に、ロボットの動作の失敗を未然に防ぐことができるようにした制御装置、制御方法、およびプログラムに関する。
　工場などの人がいる環境でロボットを扱う場合、安全性の観点などから、ロボットの誤動作を防ぐ必要がある。機械学習により得られたモデルや予め設定されたルールに基づいて動作する場合、動作の失敗をロボット自身が判断することは難しい。
　例えば特許文献１には、動作が成功した場合に予想されるセンサ出力データの時系列パターンと、作業中のセンサ出力データの時系列パターンに基づいて、動作の正否を判定する技術が開示されている。時系列パターンの各折線部を１つの状態として扱うとともに各節点を状態変化のためのイベントとして扱い、それぞれの状態とイベントに許容範囲を設定して状態遷移を監視するようになされている。
特開平１１－０６５６４９号公報 特開２００７－３０３８６６号公報 特開２０１２－７３７６９号公報
　上述した技術においては、それぞれの状態とイベントにユーザが許容範囲を設定する必要がある。また、動作が成功した場合に予想されるセンサ出力データの時系列パターンを自動的に更新したり、動作が失敗すると判断した場合にリカバリーを行ったりすることができない。
　動作が成功するか否かの判断の基準となるデータをロボットが自動的に更新したり、動作が失敗すると判断した場合にロボットが動作を自動的にやり直したりすることができれば便利である。
　本技術はこのような状況に鑑みてなされたものであり、ロボットの動作の失敗を未然に防ぐことができるようにするものである。
　本技術の一側面の制御装置は、タスクの実行時のロボットの状態の遷移が、前記タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、前記タスクの失敗に至る前に、所定の処理を行うように前記ロボットの動作を制御する状態遷移判断部を備える。
　本技術の一側面においては、タスクの実行時のロボットの状態の遷移が、タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、タスクの失敗に至る前に、所定の処理を行うようにロボットの動作が制御される。
　本技術によれば、ロボットの動作の失敗を未然に防ぐことができる。
　なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術の一実施形態に係るロボットの外観の例を示す図である。 失敗状態遷移の例を示す図である。 失敗状態遷移の他の例を示す図である。 ロボットのハードウェア構成例を示すブロック図である。 制御部の機能構成例を示すブロック図である。 失敗状態遷移生成処理について説明するフローチャートである。 制御処理について説明するフローチャートである。 「物体を掴む」のタスクに関する失敗状態遷移の更新の第１の例を示す図である。 「物体を掴む」のタスクに関する失敗状態遷移の更新の第２の例を示す図である。 「物体を人に渡す」のタスクに関する失敗状態遷移の更新の第１の例を示す図である。 「物体を人に渡す」のタスクに関する失敗状態遷移の更新の第２の例を示す図である。 「物体を掴む」のタスクに関する失敗状態遷移の更新の他の例を示す図である。 制御部の他の機能構成例を示すブロック図である。 失敗状態遷移更新部の構成例を示すブロック図である。 失敗状態遷移更新処理について説明するフローチャートである。 「物体を掴む」のタスクに関する、リカバリーを含む失敗状態遷移の第１の例を示す図である。 「物体を掴む」のタスクに関する、リカバリーを含む失敗状態遷移の第２の例を示す図である。 「物体を人に渡す」のタスクに関する、リカバリーを含む失敗状態遷移の第１の例を示す図である。 「物体を人に渡す」のタスクに関する、リカバリーを含む失敗状態遷移の第２の例を示す図である。 制御部の他の機能構成例を示すブロック図である。 リカバリー制御部の構成例を示すブロック図である。 リカバリー実行処理について説明するフローチャートである。 制御システムの構成例を示す図である。 コンピュータの構成例を示すブロック図である。
　以下、本技術を実施するための形態について説明する。説明は以下の順序で行う。
　１．失敗状態遷移
　２．ロボットの構成例
　３．ロボットの動作
　４．失敗状態遷移を更新する例
　５．リカバリーの例
　６．変形例
＜失敗状態遷移＞
　図１は、本技術の一実施形態に係るロボットの外観の例を示す図である。
　図１のＡに示すロボット１は、アーム型のロボットである。ロボット１は、ベース部１１、ベース部１１から延びるアーム部１２、およびアーム部１２の先端に取り付けられたハンド部１３から構成される。ロボット１は、工場などに設けられ、物を掴んで移動させるなどの所定のタスクを実行する。
　ロボット１に代えて、図１のＢに示すような、二足歩行が可能な人型のロボットであるロボット２が用いられるようにしてもよい。ロボット２もアーム部などを有しており、物を掴んで移動させることができる。
　図１に示すロボット１、ロボット２は、内蔵するコンピュータによって所定のプログラムを実行し、各部位を駆動させることによって自律的な行動をとる。
　以下、適宜、アーム型のロボットであるロボット１において行われる処理について説明する。ロボット１において行われる処理と同様の処理が、ロボット２や、四足歩行が可能なロボットなどの他の形状のロボットにおいて行われる。
　ロボット１は、物を掴んで移動させるなどのタスクを実行する場合、各タイミングの自身の状態を監視する。ロボット１は、自身の状態の遷移が、タスクの失敗に至る状態の遷移である失敗状態遷移と同じ遷移を辿っている場合、失敗の状態に辿り着く前に、ユーザに警告するなどの所定のアクションを実行する。
　ロボット１は、タスク毎の失敗状態遷移を表す情報である失敗状態遷移情報を有している。失敗状態遷移情報は、所定のタイミングで予め生成され、ロボット１に用意される。
　ここで、状態には、動作とイベントが含まれる。動作は、ロボット１が能動的に行う事象を表す。「アームを動かす」、「認識する」などの事象が動作に含まれる。また、イベントは、ロボット１において検出される受動的な事象を表す。「見失う」などの事象がイベントに含まれる。ここでは、各状態を値によって表すのではなく、ロボット１の状態が各状態に該当するか否かが判断される。
　なお、状態には、画像の認識結果、異音検知結果、匂い検知結果などの認識結果が含まれる。また、状態には、物体を把持することによって特定される、物体の形状、滑りやすさ、柔らかさなどの認識結果も含まれる。
　図２は、失敗状態遷移の例を示す図である。
　図２に示す失敗状態遷移は、「物体を掴む」のタスクの失敗に至る状態遷移を表す。「物体を掴む」のタスクは、例えば、ロボット１の近傍に置かれた物体を認識し、把持して持ち上げるタスクである。
　「物体を掴む」のタスクの実行時、ロボット１の状態は、はじめに、アーム部１２が上がった状態である状態＃１となり、次に、把持対象となる物体が認識された状態である状態＃２となる。把持対象となる物体は、例えば、カメラにより撮影された画像やセンサにより検出されたセンサデータに基づいて認識される。
　把持対象となる物体を認識した状態である状態＃２になった後、アーム部１２を動かすか否かが判定される。
　アーム部１２を動かすと判定された場合、ロボット１の状態は、アーム部１２を動かす状態である状態＃３となる。ロボット１は、状態＃３になった場合、各部を駆動してアーム部１２を動かす。アーム部１２を動かさない場合は、タスクの失敗に至ることがないものとして扱われる。
　アーム部１２を動かす状態である状態＃３になった後、把持対象となる物体を見失ったか否かが判定される。
　把持対象となる物体を見失ったと判定された場合、ロボット１の状態は、把持対象となる物体を見失った状態である状態＃４となる。
　状態＃４になった場合、矢印Ａ１の先に示すように、警告のアクションが実行される。ロボット１は、スピーカなどを駆動させ、把持対象となる物体を見失った状態になったことを音声によってユーザに警告する。把持対象となる物体を見失っていない場合は、タスクの失敗に至ることがないものとして扱われる。
　把持対象となる物体を見失った状態である状態＃４となり、警告のアクションが実行された後、アーム部１２をさらに動かすか否かが判定される。
　アーム部１２をさらに動かすと判定された場合、ロボット１の状態は、アーム部１２を動かす状態である状態＃５となる。
　状態＃５になった場合、タスクが失敗に至る前の状態である失敗前状態であると判断され、矢印Ａ２の先に示すように、緊急停止のアクションが実行される。ロボット１は、各部の駆動を停止して、アーム部１２を動かさない。アーム部１２を動かさないことにより、タスクの失敗に至ることはない。
　このように、状態＃１乃至＃５からなる状態遷移が、「物体を掴む」のタスクを実行する場合の失敗状態遷移として設定される。ロボット１の状態の遷移が失敗状態遷移と同じ遷移を辿っている場合、警告や緊急停止のアクションが実行される。
　把持対象となる物体を見失って警告を行った後においても失敗状態遷移を辿り、アーム部１２を動かそうとする場合、失敗前状態となって動作を緊急停止させることにより、ロボット１は、タスクの失敗を防ぎ、周りにある物にアーム部１２などがぶつかってしまうことを防ぐことが可能となる。
　図３は、失敗状態遷移の他の例を示す図である。
　図３に示す失敗状態遷移は、「物体を人に渡す」のタスクの失敗に至る状態遷移を表す。「物体を人に渡す」のタスクは、例えば、ロボット１の近傍に置かれた物体を把持したまま、近くにいる人の前方に差し出し、把持を解除することによって人に渡すタスクである。
　「物体を人に渡す」のタスクの実行時、ロボット１の状態は、はじめに、物体をハンド部１３により持った状態である状態＃１１となり、次に、ハンド部１３を人の前に差し出す状態である状態＃１２となる。物体を持つ動作は、対象の物体をカメラなどのセンサの出力に基づいて認識し、アーム部１２とハンド部１３を駆動させることによって実現される。
　物体を把持したハンド部１３を人の前に差し出す状態である状態＃１２になった後、人の手が物体に触れていないか否かが判定される。人の手が物体に触れたことは、例えば、カメラにより撮影された画像やセンサにより検出されたセンサデータに基づいて認識される。
　人の手が物体に触れていないと判定された場合、ロボット１の状態は、人の手が物体に触れていない状態である状態＃１３となる。
　状態＃１３になった場合、矢印Ａ１１の先に示すように、警告のアクションが実行される。ロボット１は、スピーカなどを駆動させ、手が物体に触れていないことを音声によってユーザに警告する。人の手が物体に触れている場合は、タスクの失敗に至ることがないものとして扱われる。
　人の手が物体に触れていない状態である状態＃１３となり、警告のアクションが実行された後、ハンド部１３により差し出している物体を人が見ていないか否かが判定される。物体を見ているか否かは、例えば、カメラにより撮影された画像を解析することによって特定される、人の視線の方向に基づいて判定される。
　人が物体を見ていないと判定された場合、ロボット１の状態は、人が物体を見ていない状態である状態＃１４となる。
　状態＃１４になった場合、矢印Ａ１２の先に示すように、警告のアクションが実行される。ロボット１は、スピーカなどを駆動させ、物体を見ることに集中することを音声によってユーザに警告する。人が物体を見ている場合は、タスクの失敗に至ることがないものとして扱われる。
　人が物体を見ていない状態である状態＃１４となり、警告のアクションが実行された後、物体を握るハンド部１３の力を緩めるか否かが判定される。
　物体を握るハンド部１３の力を緩めると判定された場合、ロボット１の状態は、物体を握るハンド部１３の力を緩める状態である状態＃１５となる。物体を握るハンド部１３の力を緩めない場合は、タスクの失敗に至ることがないものとして扱われる。
　状態＃１５になった場合、失敗前状態であると判断され、矢印Ａ１３の先に示すように、握り直しのアクションが実行される。ロボット１は、ハンド部１３の力を加えて物体を再度握るように各部を駆動する。
　このように、状態＃１１乃至＃１５からなる状態遷移が、「物体を人に渡す」のタスクを実行する場合の失敗状態遷移として設定される。ロボット１の状態の遷移が失敗状態遷移と同じ遷移を辿っている場合、警告や緊急停止のアクションが実行される。
　物体を見るように警告を行った後においても失敗状態遷移を辿り、ハンド部１３の力を緩めようとする場合、失敗前状態となって物体を握り直すための動作を行うことにより、ロボット１は、タスクの失敗を防ぎ、持ち上げている物体を落としてしまうことを防ぐことが可能となる。
　このように、失敗状態遷移がタスク毎に設定され、そのような遷移を表す情報がロボット１に用意される。
　ロボット１は、自身の状態の遷移が失敗状態遷移と同じ遷移を辿っている場合にタスクが失敗するものと判断し、実際に失敗に至る前に、タスクに応じた最適な動作を行うことにより、失敗を防ぐことが可能となる。
　以上のようにして失敗を防ぐロボット１の処理についてはフローチャートを参照して後述する。
＜ロボットの構成例＞
　図４は、ロボット１のハードウェア構成例を示すブロック図である。
　図４に示すように、ロボット１は、制御部３１に対して、入出力部３２、駆動部３３、無線通信部３４、および電源部３５が接続されることによって構成される。
　制御部３１は、CPU(Central Processing Unit)，ROM(Read Only Memory)，RAM(Random Access Memory)、フラッシュメモリなどを有するコンピュータにより構成される。制御部３１は、CPUにより所定のプログラムを実行し、ロボット１の全体の動作を制御する。制御部３１を構成するコンピュータは、ロボット１の動作を制御する制御装置として機能する。
　例えば、制御部３１は、入出力部３２から供給された情報、および、駆動部３３の各駆動ユニットから供給された情報に基づいて、自身の状態を監視する。
　また、制御部３１は、所定のタスクを実行する場合、そのタスクの失敗状態遷移情報に基づいて、自身の状態の遷移が、失敗状態遷移と同じ遷移を辿っているか否かを判断する。自身の状態の遷移が失敗状態遷移と同じ遷移を辿っているとして判断した場合、制御部３１は、実際に失敗に至る前に、所定のアクションを実行する。
　入出力部３２は、カメラ４１、マイク（マイクロフォン）４２、スピーカ４３、タッチセンサ４４、およびLED(Light Emitting Diode)４５により構成される。
　カメラ４１は、周囲の環境を順次撮影する。カメラ４１は、撮影によって得られた静止画像または動画像である撮影画像のデータを制御部３１に出力する。
　マイク４２は、環境音を検出する。マイク４２は、環境音のデータを制御部３１に出力する。
　スピーカ４３は、発話音声、BGMなどの所定の音を出力する。
　タッチセンサ４４は、ベース部１１などの所定の部位に設けられる。タッチセンサ４４は、ユーザが触れたことを検出し、ユーザによる操作の内容を表す情報を制御部３１に出力する。
　LED４５は、制御部３１による制御に従って発光し、ユーザに情報を提示する。LED４５に代えて、LCD、有機ELディスプレイなどの小型のディスプレイが設けられるようにしてもよい。
　入出力部３２には、周囲にある物体までの距離を測定する測距センサ、GPS(Global Positioning System)などの測位センサなどの各種のモジュールが設けられる。
　駆動部３３は、制御部３１による制御に従って駆動し、ロボット１の行動を実現する。駆動部３３は、ロール、ピッチ、ヨーなどの関節軸毎に設けられた複数の駆動ユニットにより構成される。
　各駆動ユニットは、例えばロボット１のそれぞれの関節に設けられる。各駆動ユニットは、軸回りの回転動作を行うモータ、モータの回転位置を検出するエンコーダ、および、エンコーダの出力に基づいてモータの回転位置や回転速度を適応的に制御するドライバの組み合わせによって構成される。駆動ユニットの数、駆動ユニットの位置などによって、ロボット１のハードウェア構成が定まる。
　図４の例においては、駆動ユニットとして、駆動ユニット５１－１乃至５１－ｎが設けられる。例えば駆動ユニット５１－１は、モータ６１－１、エンコーダ６２－１、ドライバ６３－１により構成される。駆動ユニット５１－２乃至５１－ｎも、駆動ユニット５１－１と同様の構成を有する。
　無線通信部３４は、無線LANモジュール、LTE(Long Term Evolution)に対応した携帯通信モジュールなどの無線通信モジュールである。無線通信部３４は、インターネット上のサーバなどの外部の装置との間で通信を行う。無線通信部３４は、制御部３１から供給されたデータを外部の装置に送信し、外部の装置から送信されてきたデータを受信する。
　電源部３５は、ロボット１内の各部に対して給電を行う。電源部３５は、充電バッテリ７１と、充電バッテリ７１の充放電状態を管理する充放電制御部７２により構成される。
　図５は、制御部３１の機能構成例を示すブロック図である。
　図５に示すように、制御部３１は、動作出力部１０１、動作取得部１０２、失敗状態遷移判断部１０３、失敗状態遷移記憶部１０４、失敗状態遷移生成部１０５、および駆動制御部１０６から構成される。図５に示す機能部のうちの少なくとも一部は、制御部３１を構成するCPUにより所定のプログラムが実行されることにより実現される。
　動作出力部１０１は、駆動部３３の各駆動ユニットから供給された情報を受信し、動作取得部１０２に出力する。
　動作取得部１０２は、動作出力部１０１から供給された情報に基づいて、ロボット１の動作の内容を検出する。動作取得部１０２は、動作の内容を表す情報を失敗状態遷移判断部１０３に出力する。
　失敗状態遷移判断部１０３は、所定のタスクを実行する場合、実行するタスクの失敗状態遷移を表す情報を失敗状態遷移記憶部１０４から読み出して取得する。
　失敗状態遷移判断部１０３は、動作取得部１０２から供給された情報により表される動作に基づいてロボット１の状態を特定し、自身の状態の遷移が、失敗状態遷移と同じ遷移を辿っているか否かを判断する。
　失敗状態遷移判断部１０３は、状態遷移の判断結果に基づいて駆動制御部１０６を制御する。例えば、失敗状態遷移判断部１０３は、自身の状態遷移が失敗状態遷移と同じ遷移を辿っていないと判断した場合、タスクの成功までの各動作を行わせる。また、失敗状態遷移判断部１０３は、自身の状態遷移が失敗状態遷移と同じ遷移を辿っていると判断した場合、予め設定されたアクションを実行させる。
　失敗状態遷移記憶部１０４は、各タスクの失敗状態遷移情報を記憶する。
　失敗状態遷移生成部１０５は、各タスクの失敗状態遷移を設定し、失敗状態遷移情報を生成する。失敗状態遷移生成部１０５は、失敗状態遷移情報を失敗状態遷移記憶部１０４に出力し、記憶させる。
　駆動制御部１０６は、失敗状態遷移判断部１０３から供給された情報に基づいて、駆動部３３の各駆動ユニットを制御し、所定の動作を行わせる。
＜ロボットの動作＞
　ここで、以上のような構成を有するロボット１の動作について説明する。
　はじめに、図６のフローチャートを参照して、ロボット１の失敗状態遷移生成処理について説明する。
　ステップＳ１において、失敗状態遷移生成部１０５は、所定のタスクの失敗状態遷移を設定する。失敗状態遷移の設定が、例えばロボット１の管理者の操作に応じて行われるようにしてもよい。
　ステップＳ２において、失敗状態遷移生成部１０５は、失敗状態遷移情報を失敗状態遷移記憶部１０４に出力し、記憶させる。
　以上の処理が、各タスクを対象として行われる。失敗状態遷移記憶部１０４には、タスク毎の失敗状態遷移情報が記憶される。
　次に、図７のフローチャートを参照して、ロボット１の制御処理について説明する。
　ステップＳ１１において、失敗状態遷移判断部１０３は、動作取得部１０２から供給された情報により表される動作に基づいてロボット１の状態を特定する。動作取得部１０２からは、ロボット１がどのように動いているか（アーム部１２を上に動かす、前に進むなど）、ロボット１がどのような情報を得たか（画像/音声認識結果、その他センサ情報など）などを表す情報が、動作の内容を表す情報として供給される。
　ステップＳ１２において、失敗状態遷移判断部１０３は、ロボット１の状態を失敗状態遷移に当てはめる。
　ステップＳ１３において、失敗状態遷移判断部１０３は、ロボット１の状態の遷移が、失敗状態遷移と同じ遷移を辿っており、アクションを実行すべき遷移が生じたか否かを判定する。
　アクションを実行すべき遷移が生じていないとステップＳ１３において判定した場合、失敗状態遷移判断部１０３は、ステップＳ１１に戻り、上述した処理を繰り返す。
　アクションを実行すべき遷移が生じたとステップＳ１３において判定した場合、ステップＳ１４において、失敗状態遷移判断部１０３は、所定のアクションを実行するように駆動制御部１０６を制御する。上述したように、ロボット１の状態に応じて、ユーザに対する警告、動作の緊急停止、握り直しなどのアクションが実行される。
　アクションが実行された後、処理は終了となる。以上の処理が、タスクの実行中、繰り返し行われる。
　以上のように、ロボット１は、タスクが失敗する前に最適な動作を行うことにより、タスクの失敗を防ぐことができる。
＜失敗状態遷移を更新する例＞
　失敗状態遷移がロボット１により自動的に更新されるようにしてもよい。失敗状態遷移の更新は、例えば、失敗前状態に至った回数が多い場合に行われる。
・更新の例１
　図８は、「物体を掴む」のタスクに関する失敗状態遷移の更新の第１の例を示す図である。
　図８の状態＃２１乃至＃２３は、図２の状態＃１乃至＃３と同様である。アーム部１２を動かす状態である状態＃２３になった後、把持対象となる物体を見失ったか否かが判定される。
　把持対象となる物体を見失ったと判定された場合、ロボット１の状態は、把持対象となる物体を見失った状態である状態＃２４となる。
　状態＃２４になった場合、矢印Ａ２１の先に示すように、緊急停止のアクションが実行される。ロボット１は、各部の駆動を停止して、アーム部１２を動かさない。
　すなわち、図８の失敗状態遷移においては、破線で囲んで示すように、把持対象となる物体を見失った状態である状態＃２４になった場合に失敗前状態に至ったものと判断され、ユーザに対する警告なしに、緊急停止のアクションが実行される。言い換えると、失敗前状態に至りやすくなるように、失敗状態遷移が更新されることになる。
　失敗前状態に至ったものと早い段階で判断するように失敗状態遷移が更新されることにより、より確実に、タスクの失敗を防ぐことが可能となる。
・更新の例２
　図９は、「物体を掴む」のタスクに関する失敗状態遷移の更新の第２の例を示す図である。
　図９の状態＃３１乃至＃３３は、図２の状態＃１乃至＃３と同様である。アーム部１２を動かす状態である状態＃３３になった後、把持対象となる物体の半分以上が画角から外れたか否かが判定される。
　把持対象となる物体の半分以上が画角から外れたと判定された場合、ロボット１の状態は、把持対象となる物体の半分以上が画角から外れた状態である状態＃３４となる。
　状態＃３４になった場合、矢印Ａ３１の先に示すように、警告のアクションが実行される。ロボット１は、スピーカなどを駆動させ、把持対象となる物体の半分以上が画角から外れたことを音声によってユーザに警告する。
　すなわち、図９の失敗状態遷移においては、破線で囲んで示すように、図２の遷移における基準より厳しい基準に基づいて警告のアクションが実行されることになる。
　図２の失敗状態遷移においては、把持対象となる物体の例えば全体が画角から外れ、物体を見失ったと判定された場合に警告のアクションが実行される。把持対象となる物体の半分が画角から外れる状態は、物体の全体が画角から外れる状態と比べて生じやすい状態であるから、図９の失敗状態遷移の方が、警告のアクションを実行する基準が厳しい基準であるといえる。言い換えると、失敗状態遷移を辿りやすくなるように、失敗状態遷移が更新されることになる。
　図９の失敗状態遷移において、警告のアクションが実行された後の遷移は、図２を参照して説明した遷移と同様である。
　アクションを実行する基準がより厳しい基準となるように失敗状態遷移が更新されることにより、より確実に、タスクの失敗を防ぐことが可能となる。
・更新の例３
　図１０は、「物体を人に渡す」のタスクに関する失敗状態遷移の更新の第１の例を示す図である。
　図１０の状態＃４１乃至＃４３は、図３の状態＃１１乃至＃１３と同様である。人の手が物体に触れていない状態である状態＃４３になった場合、矢印Ａ４１の先に示すように、警告のアクションが実行される。
　人の手が物体に触れていない状態である状態＃４３となり、警告のアクションが実行された後、人の顔が物体の方向を向いていないか否かが判定される。
　人の顔が物体の方向を向いていないと判定された場合、ロボット１の状態は、人の顔が物体の方向を向いていない状態である状態＃４４となる。状態＃４４になった場合、矢印Ａ４２の先に示すように、警告のアクションが実行される。
　すなわち、図１０の失敗状態遷移においては、破線で囲んで示すように、図３の遷移における基準より厳しい基準に基づいて警告のアクションが実行されることになる。
　図３の失敗状態遷移においては、人が物体を見ていないと判定された場合に警告のアクションが実行される。言い換えると、顔の向きに関わらず、視線を物体に向けてさえいれば警告のアクションが実行されないことになる。
　視線だけでなく顔の向きについても意識させるという点で人の注意をより要求する基準が用いられているから、図１０の失敗状態遷移の方が、警告のアクションを実行する基準としてより厳しい基準を用いた遷移であるといえる。
　図１０の失敗状態遷移において、警告のアクションが実行された後の遷移は、図３を参照して説明した遷移と同様である。
・更新の例４
　図１１は、「物体を人に渡す」のタスクに関する失敗状態遷移の更新の第２の例を示す図である。
　図１１の状態＃５１，＃５２は、図３の状態＃１１，＃１２と同様である。物体を把持したハンド部１３を人の前に差し出す状態である状態＃１２になった後、人の手が物体を握っていないか否かが判定される。
　人の手が物体を握っていないと判定された場合、ロボット１の状態は、人の手が物体を握っていない状態である状態＃５３となる。状態＃５３になった場合、矢印Ａ５１の先に示すように、警告のアクションが実行される。
　すなわち、図１１の失敗状態遷移においては、破線で囲んで示すように、図３の遷移における基準より厳しい基準に基づいて警告のアクションが実行されることになる。
　図３の失敗状態遷移においては、人の手が物体に触れていないと判定された場合に警告のアクションが実行される。言い換えると、物体を握らないでも、手が触れてさえいれば警告のアクションが実行されないことになる。
　物体に触れるだけでなく実際に握らせるという点で人の注意をより要求する基準であるから、図１０の失敗状態遷移の方が、警告のアクションを実行する基準としてより厳しい基準を用いた遷移であるといえる。
　図１１の失敗状態遷移において、警告のアクションが実行された後の遷移は、図３を参照して説明した遷移と同様である。
・更新の例５
　図１２は、「物体を掴む」のタスクに関する失敗状態遷移の更新の他の例を示す図である。
　図１２に示す失敗状態遷移は、警告のアクションを実行することになる状態が追加されている点で、図２の失敗状態遷移と異なる。
　図１２の状態＃６１，＃６２は、図２の状態＃１，＃２と同様である。アーム部１２を動かす状態である状態＃６３になった後、把持対象となる物体の半分以上が画角から外れたか否かが判定される。
　把持対象となる物体の半分以上が画角から外れたと判定された場合、ロボット１の状態は、把持対象となる物体の半分以上が画角から外れた状態である状態＃６４となる。
　状態＃６４になった場合、矢印Ａ６１の先に示すように、警告のアクションが実行される。
　すなわち、図１２の失敗状態遷移においては、破線で囲んで示すように、警告のアクションを実行すべき状態になったか否かの判定が追加され、図９の遷移と比べて、警告のアクションが実行されやすくなる。
　警告のアクションが実行された後の遷移は、図２の状態＃３以降の遷移と同様である。
　このように、警告のアクションを実行することになる状態を増やすように失敗状態遷移が更新されることによっても、より確実に、タスクの失敗を防ぐことが可能となる。
・失敗状態遷移更新部の構成例
　図１３は、制御部３１の他の機能構成例を示すブロック図である。
　図１３に示す構成は、基本的に、失敗状態遷移更新部１０７が追加されている点を除いて、図５に示す構成と同じである。重複する説明については適宜省略する。
　失敗状態遷移更新部１０７は、失敗状態遷移を更新するタイミングになったと判断した場合、失敗状態遷移を上述したようにして更新する。失敗状態遷移を更新するタイミングになったか否かは、失敗状態遷移判断部１０３から供給された情報に基づいて判断される。
　失敗状態遷移更新部１０７は、更新後の失敗状態遷移を表す失敗状態遷移情報を失敗状態遷移記憶部１０４に出力し、記憶させる。
　図１４は、失敗状態遷移更新部１０７の構成例を示すブロック図である。
　図１４に示すように、失敗状態遷移更新部１０７は、失敗情報取得部１３１、更新判断部１３２、更新部１３３、更新判断基準情報記憶部１３４、および更新遷移情報記憶部１３５から構成される。
　失敗情報取得部１３１は、失敗状態遷移判断部１０３（図１３）から出力された情報に基づいて、タスクの失敗に関する情報を取得する。失敗情報取得部１３１は、例えば、失敗前状態に至った回数を特定し、特定した回数を表す情報を更新判断部１３２に出力する。
　更新判断部１３２は、失敗情報取得部１３１から供給された情報に基づいて、失敗状態遷移を更新するか否かを判断する。更新判断基準情報記憶部１３４には、各タスクについての、更新の判断の基準となる更新判断基準情報が記憶されている。
　失敗状態遷移を更新するか否かは、例えば、失敗前状態に至った回数と、更新判断基準情報により表される閾値の回数とを比較することによって行われる。更新判断部１３２は、所定のタスクの失敗前状態に至った回数が閾値の回数を超えた場合、そのタスクの失敗状態遷移を更新すると判断し、そのことを表す情報を更新部１３３に出力する。
　更新部１３３は、更新すると判断された失敗状態遷移を、更新遷移情報記憶部１３５に記憶されている情報に基づいて更新する。更新遷移情報記憶部１３５には、失敗状態遷移の更新の仕方に関する情報が記憶されている。更新部１３３は、更新後の失敗状態遷移を表す失敗状態遷移情報を失敗状態遷移記憶部１０４に出力し、記憶させる。
・失敗状態遷移更新処理
　図１５のフローチャートを参照して、失敗状態遷移を更新するロボット１の処理について説明する。
　ステップＳ２１において、失敗情報取得部１３１は、失敗状態遷移判断部１０３から出力された情報に基づいて、タスクの失敗に関する情報を取得する。
　例えば、失敗情報取得部１３１は、失敗に関する情報として、失敗前状態に至った回数、失敗の内容、失敗の深刻度を取得する。
　失敗の内容は、上述したアクションの原因である。例えば、物体を見失う、人の手が物体に触れていない、人が物体を見ていない、物体の半分が画角から外れる、人の顔が物体の方向を向いていない、人の手が物体を握っていない、などが、失敗の内容として取得される。
　また、失敗の深刻度は、失敗前状態に至ったことの深刻度である。例えば、ぶつかったか否か、物体を落としたか否か、物体や壁などを壊したか否か、駆動領域のリミットまで動いたか否か、人が近くにいたか否か、などの、失敗前状態に応じた深刻度が取得される。
　ステップＳ２２において、更新判断部１３２は、失敗状態遷移の更新の条件を満たしたか否かを判定する。
　ここでは、例えば、失敗前状態に至った回数が閾値の回数以上となった場合、更新の条件を満たしたものとして判定される。
　また、同じ内容の失敗が閾値の回数以上繰り返された場合、または、深刻度が閾値の度合いより高い失敗が起きた場合にも、更新の条件を満たしたものとして判定される。
　更新の条件を満たしていないとステップＳ２２において判定された場合、ステップＳ２１に戻り、以上の処理が繰り返される。
　更新の条件を満たしたとステップＳ２２において判定された場合、ステップＳ２３において、更新部１３３は失敗状態遷移を更新する。失敗状態遷移の更新は、例えば以下の１～３のようにして行われる。
　１．事前の設定に従って、上述したように、失敗前状態に至ったものと早い段階で判断するように、あるいは、アクションを実行する基準がより厳しい基準となるように更新する。
　例えば、失敗前状態に至った回数が閾値の回数以上となった場合は、失敗前状態に至ったものと早い段階で判断するように更新される。また、同じ内容の失敗が閾値の回数以上繰り返された場合、または、深刻度が閾値の度合いより高い失敗が起きた場合は、アクションを実行する基準がより厳しい基準となるように更新される。
　２．使用する失敗状態遷移を状況に応じて変えるように更新する。
　例えば、把持対象となる物体の大きさが所定のサイズより小さい場合には図８の失敗状態遷移を使用し、所定のサイズより大きい場合には図９の失敗状態遷移を使用するといったように、使用する失敗状態遷移が把持対象となる物体の大きさに応じて切り替えられる。
　また、物体の渡し先となる人が子どもである場合には図１０の失敗状態遷移を使用し、大人である場合には図１１の失敗状態遷移を使用するといったように、使用する失敗状態遷移が物体の渡し先となる人の属性に応じて切り替えられる。
　３．ユーザによる設定に従って更新する。
　この場合、スピーカ４３から音声を出力するなどして、ユーザに対して条件を更新することが促される。
　ステップＳ２４において、更新部１３３は、更新後の失敗状態遷移を表す失敗状態遷移情報を失敗状態遷移記憶部１０４に記憶させ、処理を終了させる。
　このように、条件を満たした場合に失敗状態遷移を更新することにより、ロボット１は、タスクの失敗をより確実に防ぐことができる。
＜リカバリーの例＞
　失敗前状態に至った場合にリカバリーが実行されるようにしてもよい。リカバリーは、タスクの実行を再度試みる動作である。
・リカバリーの例１
　図１６は、「物体を掴む」のタスクに関する、リカバリーを含む失敗状態遷移の第１の例を示す図である。
　図１６の状態＃１０１乃至＃１０５は、それぞれ、図２の状態＃１乃至＃５と同様である。
　図１６の例においては、アーム部１２を動かす状態である状態＃１０５となり、失敗前状態であると判断された場合、ロボット１の状態は、再度、状態＃１０１に戻る。
　すなわち、物体を見失った状態でアーム部１２を動かす場合、ロボット１は、アーム部１２を上げた状態となるように各部を制御する。図１６の例においては、アーム部１２を上げた状態となるように各部を制御する動作によって、リカバリーが実行される。
・リカバリーの例２
　図１７は、「物体を掴む」のタスクに関する、リカバリーを含む失敗状態遷移の第２の例を示す図である。
　図１７の状態＃１１１乃至＃１１５は、それぞれ、図２の状態＃１乃至＃５と同様である。
　図１７の例においては、アーム部１２を動かす状態である状態＃１１５となり、失敗前状態であると判断された場合、ロボット１の状態は、物体を認識していた位置までアーム部１２を動かす状態である状態＃１１６となる。ロボット１は、物体を見失う直前の位置までアーム部１２を動かすように各部を制御する。
　物体を認識していた位置までアーム部１２を動かす状態である状態＃１１６になった後、ロボット１の状態は、物体追跡パラメータを更新する状態である状態＃１１７となる。
　物体追跡パラメータは、カメラ４１により撮影された画像に基づいて物体を追跡するためのパラメータである。カメラ４１がアーム部１２の先端近傍に設けられている場合、物体追跡パラメータには、アーム部１２の移動速度などの情報が含まれる。
　ロボット１は、物体を見失わないように、アーム部１２の移動速度を下げるなどして物体追跡パラメータを更新する。その後、ロボット１の状態は状態＃１１２に戻り、同様の状態遷移が続けられる。図１７の例においては、物体を見失う直前の位置までアーム部１２を動かし、物体追跡パラメータを更新する動作によって、リカバリーが実行される。
・リカバリーの例３
　図１８は、「物体を人に渡す」のタスクに関する、リカバリーを含む失敗状態遷移の第１の例を示す図である。
　図１８の状態＃１２１乃至＃１２５は、それぞれ、図３の状態＃１１乃至＃１５と同様である。
　図１８の例においては、物体を握るハンド部１３の力を緩める状態である状態＃１２５となり、失敗前状態であると判断された場合、ロボット１の状態は、再度、状態＃１２１に戻る。
　すなわち、物体の渡し先となる人が物体を見ていない状態でハンド部１３の力を緩めようとする場合、ロボット１は、物体を持つ状態となるように、ハンド部１３を含む各部を制御する。図１８の例においては、物体を持つ状態となるようにハンド部１３を含む各部を制御する動作によって、リカバリーが実行される。
・リカバリーの例４
　図１９は、「物体を人に渡す」のタスクに関する、リカバリーを含む失敗状態遷移の第２の例を示す図である。
　図１９の状態＃１３１乃至＃１３５は、それぞれ、図３の状態＃１１乃至＃１５と同様である。
　図１９の例においては、物体を握るハンド部１３の力を緩める状態である状態＃１３５となり、失敗前状態であると判断された場合、ロボット１の状態は、物体を握り直す状態である状態＃１３６となる。物体の渡し先となる人が物体を見ていない状態でハンド部１３の力を緩めようとする場合、ロボット１は、物体を握り直すようにハンド部１３を含む各部を制御する。
　ハンド部１３によって物体を握り直す状態である状態＃１３６になった後、ロボット１の状態は、物体を見て、注意しながら持つようにユーザに警告を行う状態である状態＃１３７となる。ロボット１は、スピーカ４３から音声を出力するなどしてそのような警告を行った後、人が物体を見ていないか否かを判定し、同様の状態遷移を繰り返す。
　図１９の例においては、物体を握り直すようにハンド部１３を含む各部を制御し、ユーザに対して警告を行う動作によって、リカバリーが実行される。
　以上のように、リカバリーを含む失敗状態遷移がロボット１において管理され、失敗前状態に至った場合にリカバリーが実行される。これにより、ロボット１は、タスクの失敗を防ぐとともに、タスクを成功に導くことができる。警告が行われた後にリカバリーが行われるようにしてもよい。
・リカバリー制御部の構成例
　図２０は、制御部３１の他の機能構成例を示すブロック図である。
　図２０に示す構成は、基本的に、リカバリー制御部１０８が追加されている点を除いて、図５に示す構成と同じである。重複する説明については適宜省略する。
　リカバリー制御部１０８は、失敗前状態に至ったと判断した場合、リカバリーを実行するように駆動制御部１０６を制御する。失敗前状態に至ったか否かは、失敗状態遷移判断部１０３から供給された情報、または、駆動制御部１０６から供給された情報に基づいて判断される。
　図２１は、リカバリー制御部１０８の構成例を示すブロック図である。
　図２１に示すように、リカバリー制御部１０８は、失敗情報取得部１５１、リカバリー判断部１５２、リカバリー実行部１５３、リカバリー判断基準情報記憶部１５４、およびリカバリー状態遷移情報記憶部１５５から構成される。
　失敗情報取得部１５１は、失敗状態遷移判断部１０３または駆動制御部１０６から出力された情報に基づいて、タスクの失敗に関する情報を取得する。失敗情報取得部１５１は、例えば、失敗前状態に至った回数を特定し、特定した回数を表す情報をリカバリー判断部１５２に出力する。
　リカバリー判断部１５２は、失敗情報取得部１５１から供給された情報に基づいて、リカバリーを実行するか否かを判断する。リカバリー判断基準情報記憶部１５４には、各タスクについての、リカバリーを実行するか否かの判断の基準となるリカバリー判断基準情報が記憶されている。
　リカバリーを実行するか否かは、例えば、失敗前状態に至った回数と、リカバリー判断基準情報により表される閾値の回数とを比較することによって判断される。リカバリー判断部１５２は、所定のタスクの失敗前状態に至った回数が閾値の回数を超えた場合、リカバリーを実行すると判断し、そのことを表す情報をリカバリー実行部１５３に出力する。
　リカバリー実行部１５３は、リカバリー状態遷移情報記憶部１５５に記憶されている情報に基づいてリカバリーを実行する。リカバリー状態遷移情報記憶部１５５には、リカバリーの状態を含む失敗状態遷移に関する情報が記憶されている。
・リカバリー実行処理
　図２２のフローチャートを参照して、リカバリーを実行するロボット１の処理について説明する。
　ステップＳ３１において、失敗情報取得部１５１は、失敗状態遷移判断部１０３から出力されたタスクの失敗に関する情報を取得する。例えば、失敗情報取得部１５１は、失敗に関する情報として、失敗前状態に至った回数、失敗の内容、失敗の深刻度を取得する。
　ステップＳ３２において、リカバリー判断部１５２は、リカバリーを実行するか否かを判定する。
　ここでは、例えば、失敗前状態に至った回数が閾値の回数以上となった場合、リカバリーを実行するものとして判定される。また、深刻度が閾値の度合いより低い失敗が起きた場合、リカバリーを実行するものとして判定される。
　リカバリーを実行するとステップＳ３２において判定された場合、ステップＳ３３において、リカバリー実行部１５３はリカバリーを実行する。
　一方、リカバリーを実行しないとステップＳ３２において判定された場合、ステップＳ３４において、リカバリー実行部１５３は、所定のアクションを実行するように駆動制御部１０６を制御する。
　以上のように、ロボット１は、タスクが失敗する前にリカバリーを実行することにより、タスクの失敗を防ぐことができる。
＜変形例＞
　失敗状態遷移をロボット１自身が生成するのではなく、ユーザによる操作に応じてロボット１において生成されるようにしてもよい。また、PCなどの外部の装置においてユーザによる操作に応じて生成された失敗状態遷移情報がロボット１に提供され、上述したような処理に用いられるようにしてもよい。
　ロボット１の動作のテスト段階で生じた失敗状態遷移に基づいて失敗状態遷移情報が生成され、ロボット１に提供されるようにしてもよい。どのような状態遷移が失敗状態遷移であるのかに関する情報は、例えばユーザにより指定される。
　また、発生を回避したい状態をユーザが設定し、それに基づいて失敗状態遷移情報が生成されるようにしてもよい。
　以上においては、「物体を掴む」と「物体を人に渡す」のタスクを実行する場合の処理について説明したが、他のタスクを実行する場合にも同様の処理が行われる。他のタスクの実行中においても、ロボット１の状態の遷移が失敗状態遷移と同じ遷移を辿っている場合、失敗が生じる前に緊急停止等のアクションが実行される。
・制御システムの例
　失敗状態遷移に基づくロボット１の動作が、インターネット上のサーバなどの外部の装置により行われるようにしてもよい。
　図２３は、制御システムの構成例を示す図である。
　図２３の制御システムは、ロボット１と制御サーバ２０１がインターネットなどのネットワーク２０２を介して接続されることによって構成される。ロボット１と制御サーバ２０１は、ネットワーク２０２を介して通信を行う。
　図２３の制御システムにおいては、ロボット１の状態が、ロボット１から送信されてくる情報に基づいて制御サーバ２０１により特定される。ロボット１から制御サーバ２０１に対しては、ロボット１の各デバイスの状態を表す情報が順次送信される。
　ロボット１の状態の遷移が失敗状態遷移を辿っていることを検出した場合、制御サーバ２０１は、ロボット１を制御し、警告のアクション、タスク失敗時のアクションなどの状態に応じたアクションを実行させる。
　このように、制御サーバ２０１は、ロボット１の状態を監視するとともに、ロボット１の動作を状態に応じて制御する制御装置として機能する。制御サーバ２０１においては、所定のプログラムが実行されることにより、図５、図１４、または図２０の各機能部が実現される。
・コンピュータの構成例
　上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
　図２４は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。図２３の制御サーバ２０１は、図２４に示す構成と同様の構成を有する。
　CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。
　バス１００４には、さらに、入出力インタフェース１００５が接続されている。入出力インタフェース１００５には、キーボード、マウスなどよりなる入力部１００６、ディスプレイ、スピーカなどよりなる出力部１００７が接続される。また、入出力インタフェース１００５には、ハードディスクや不揮発性のメモリなどよりなる記憶部１００８、ネットワークインタフェースなどよりなる通信部１００９、リムーバブルメディア１０１１を駆動するドライブ１０１０が接続される。
　以上のように構成されるコンピュータでは、CPU１００１が、例えば、記憶部１００８に記憶されているプログラムを入出力インタフェース１００５及びバス１００４を介してRAM１００３にロードして実行することにより、上述した一連の処理が行われる。
　CPU１００１が実行するプログラムは、例えばリムーバブルメディア１０１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル放送といった、有線または無線の伝送媒体を介して提供され、記憶部１００８にインストールされる。
　なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
　本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
　本明細書に記載された効果はあくまで例示であって限定されるものでは無く、また他の効果があってもよい。
　本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
　例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
　また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
　さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
・構成の組み合わせ例
　本技術は、以下のような構成をとることもできる。
（１）
　タスクの実行時のロボットの状態の遷移が、前記タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、前記タスクの失敗に至る前に、所定の処理を行うように前記ロボットの動作を制御する状態遷移判断部を備える
　制御装置。
（２）
　前記所定の処理は、ユーザに対する警告、前記ロボットの動作の緊急停止である
　前記（１）に記載の制御装置。
（３）
　前記状態遷移判断部は、前記所定の処理としてのユーザに対する警告を行った後に、前記ロボットの状態の遷移が前記失敗状態遷移を辿っている場合、前記ロボットの動作を緊急停止させる
　前記（２）に記載の制御装置。
（４）
　前記ロボットの状態の遷移が前記失敗状態遷移を辿った場合、前記失敗状態遷移を更新する更新部をさらに備える
　前記（１）乃至（３）のいずれかに記載の制御装置。
（５）
　前記更新部は、前記失敗状態遷移を辿った回数が閾値の回数を超えた場合、または、前記失敗状態遷移を辿った前記ロボットの状態の遷移の内容に応じて、前記失敗状態遷移を更新する
　前記（４）に記載の制御装置。
（６）
　前記更新部は、前記ロボットの状態の遷移が前記失敗状態遷移を辿りやすくなるように前記失敗状態遷移を更新する
　前記（４）または（５）に記載の制御装置。
（７）
　前記ロボットの状態の遷移が前記失敗状態遷移を辿った場合、リカバリーを実行するように前記ロボットを制御するリカバリー制御部をさらに備える
　前記（１）乃至（６）のいずれかに記載の制御装置。
（８）
　前記リカバリー制御部は、前記所定の処理が行われた後に、前記リカバリーを実行させる
　前記（７）に記載の制御装置。
（９）
　前記失敗状態遷移を表す情報を記憶する記憶部をさらに備える
　前記（１）乃至（８）のいずれかに記載の制御装置。
（１０）
　制御装置が、
　タスクの実行時のロボットの状態の遷移が、前記タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、前記タスクの失敗に至る前に、所定の処理を行うように前記ロボットの動作を制御する
　制御方法。
（１１）
　コンピュータに、
　タスクの実行時のロボットの状態の遷移が、前記タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、前記タスクの失敗に至る前に、所定の処理を行うように前記ロボットの動作を制御する
　処理を実行させるためのプログラム。
　１，２　ロボット，　１１　ベース部，　１２　アーム部，　１３　ハンド部，　３１　制御部，　３３　駆動部，　４１　カメラ，　１０１　動作出力部，　１０２　動作取得部，　１０３　失敗状態遷移判断部，　１０４　失敗状態遷移記憶部，　１０５　失敗状態遷移生成部，　１０６　駆動制御部，　１０７　失敗状態遷移更新部，　１０８　リカバリー制御部，　１３１　失敗情報取得部，　１３２　更新判断部，　１３３　更新部，　１３４　更新判断基準情報記憶部，　１３５　更新遷移情報記憶部，　１５１　失敗情報取得部，　１５２　リカバリー判断部，　１５３　リカバリー実行部，　１５４　リカバリー判断基準情報記憶部，　１５５　リカバリー状態遷移情報記憶部，　２０１　制御サーバ，　２０２　ネットワーク

Claims (11)

  1. 　タスクの実行時のロボットの状態の遷移が、前記タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、前記タスクの失敗に至る前に、所定の処理を行うように前記ロボットの動作を制御する状態遷移判断部を備える
    　制御装置。
  2. 　前記所定の処理は、ユーザに対する警告、前記ロボットの動作の緊急停止である
    　請求項１に記載の制御装置。
  3. 　前記状態遷移判断部は、前記所定の処理としてのユーザに対する警告を行った後に、前記ロボットの状態の遷移が前記失敗状態遷移を辿っている場合、前記ロボットの動作を緊急停止させる
    　請求項２に記載の制御装置。
  4. 　前記ロボットの状態の遷移が前記失敗状態遷移を辿った場合、前記失敗状態遷移を更新する更新部をさらに備える
    　請求項１に記載の制御装置。
  5. 　前記更新部は、前記失敗状態遷移を辿った回数が閾値の回数を超えた場合、または、前記失敗状態遷移を辿った前記ロボットの状態の遷移の内容に応じて、前記失敗状態遷移を更新する
    　請求項４に記載の制御装置。
  6. 　前記更新部は、前記ロボットの状態の遷移が前記失敗状態遷移を辿りやすくなるように前記失敗状態遷移を更新する
    　請求項４に記載の制御装置。
  7. 　前記ロボットの状態の遷移が前記失敗状態遷移を辿った場合、リカバリーを実行するように前記ロボットを制御するリカバリー制御部をさらに備える
    　請求項１に記載の制御装置。
  8. 　前記リカバリー制御部は、前記所定の処理が行われた後に、前記リカバリーを実行させる
    　請求項７に記載の制御装置。
  9. 　前記失敗状態遷移を表す情報を記憶する記憶部をさらに備える
    　請求項１に記載の制御装置。
  10. 　制御装置が、
    　タスクの実行時のロボットの状態の遷移が、前記タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、前記タスクの失敗に至る前に、所定の処理を行うように前記ロボットの動作を制御する
    　制御方法。
  11. 　コンピュータに、
    　タスクの実行時のロボットの状態の遷移が、前記タスクの失敗に至る状態遷移として予め設定された失敗状態遷移を辿っている場合、前記タスクの失敗に至る前に、所定の処理を行うように前記ロボットの動作を制御する
    　処理を実行させるためのプログラム。
PCT/JP2019/029181 2018-08-08 2019-07-25 制御装置、制御方法、およびプログラム Ceased WO2020031718A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US17/263,854 US12233556B2 (en) 2018-08-08 2019-07-25 Control device, control method, and program
CN201980051303.7A CN112512763B (zh) 2018-08-08 2019-07-25 控制装置、控制方法和程序
JP2020536453A JP7310820B2 (ja) 2018-08-08 2019-07-25 制御装置、制御方法、およびプログラム
EP19846081.8A EP3835008A4 (en) 2018-08-08 2019-07-25 CONTROL DEVICE, CONTROL METHOD AND PROGRAM

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018149106 2018-08-08
JP2018-149106 2018-08-08

Publications (1)

Publication Number Publication Date
WO2020031718A1 true WO2020031718A1 (ja) 2020-02-13

Family

ID=69414110

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/029181 Ceased WO2020031718A1 (ja) 2018-08-08 2019-07-25 制御装置、制御方法、およびプログラム

Country Status (5)

Country Link
US (1) US12233556B2 (ja)
EP (1) EP3835008A4 (ja)
JP (1) JP7310820B2 (ja)
CN (1) CN112512763B (ja)
WO (1) WO2020031718A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116880293A (zh) * 2023-07-20 2023-10-13 济南大学 一种基于显式模型预测控制的四足机器人控制方法及控制终端
EP4144489A4 (en) * 2020-04-28 2023-10-18 Sony Group Corporation Control device, control method, and computer program

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7388352B2 (ja) * 2018-07-13 2023-11-29 ソニーグループ株式会社 制御装置、制御方法、およびプログラム
EP4114622A1 (en) 2020-03-06 2023-01-11 Embodied Intelligence Inc. Imaging process for detecting failure modes
US20250001597A1 (en) * 2023-06-29 2025-01-02 Intel Corporation Collaborative human-robot error correction and facilitation

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19625637A1 (de) * 1996-06-26 1998-01-02 Brink Carsten Dipl Ing Ten Kollisionsvermeidung und Trajektorienplanung beim Mehrroboterbetrieb mit Hilfe von Kollisionsbereichen
JPH1165649A (ja) 1997-08-20 1999-03-09 Yaskawa Electric Corp センサデータのモニタリング方法
JPH11188680A (ja) * 1997-12-22 1999-07-13 Matsushita Electric Works Ltd 部品組付装置
JP2003291083A (ja) * 2002-03-28 2003-10-14 Toshiba Corp ロボット装置、ロボット制御方法及びロボット配送システム
JP2007303866A (ja) 2006-05-09 2007-11-22 Sanki Eng Co Ltd 工場、プラント等における生産設備機器等の運転状態監視システム
JP2012073769A (ja) 2010-09-28 2012-04-12 Kawai Musical Instr Mfg Co Ltd 楽譜認識装置及びコンピュータプログラム
JP2015231640A (ja) * 2014-06-09 2015-12-24 キヤノン株式会社 ロボット動作経路チェック装置、ロボットシステム、ロボット動作経路チェック方法、プログラム及び記録媒体
JP2016155212A (ja) * 2015-02-26 2016-09-01 キヤノン株式会社 ロボット装置
WO2018012446A1 (ja) * 2016-07-11 2018-01-18 Ｇｒｏｏｖｅ Ｘ株式会社 活動量をコントロールされる自律行動型ロボット

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003260685A (ja) * 2002-03-04 2003-09-16 Seiko Epson Corp ロボット制御方法、ロボット制御装置及び制御プログラム
DE112010000775B4 (de) * 2009-02-12 2016-03-17 Kyoto University Industrierobotersystem
US8818556B2 (en) 2011-01-13 2014-08-26 Microsoft Corporation Multi-state model for robot and user interaction
JP2012232363A (ja) * 2011-04-28 2012-11-29 Seiko Epson Corp ロボット制御システム、ロボットシステム及びプログラム
US9561590B1 (en) * 2013-06-24 2017-02-07 Redwood Robotics, Inc. Distributed system for management and analytics of robotics devices
FR3012425B1 (fr) * 2013-10-24 2017-03-24 European Aeronautic Defence & Space Co Eads France Robot collaboratif d'inspection visuelle d'un aeronef
JP6459227B2 (ja) * 2014-06-02 2019-01-30 セイコーエプソン株式会社 ロボットシステム
US20160255969A1 (en) * 2015-03-06 2016-09-08 Wal-Mart Stores, Inc. Shopping facility assistance systems, devices and methods pertaining to movement of a mobile retail product display
JP6219890B2 (ja) * 2015-07-17 2017-10-25 ファナック株式会社 ロボットによる自動組立システム
WO2017163251A2 (en) 2016-03-24 2017-09-28 Polygon T.R Ltd. Systems and methods for human and robot collaboration
DE102016125408A1 (de) * 2016-12-22 2018-06-28 RobArt GmbH Autonomer mobiler roboter und verfahren zum steuern eines autonomen mobilen roboters
JP6889631B2 (ja) * 2017-08-04 2021-06-18 川崎重工業株式会社 状態監視システム及び状態監視方法
EP3785866B1 (en) * 2018-04-26 2023-12-20 Panasonic Holdings Corporation Actuator device, method for removing target object using actuator device, and target object removal system

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19625637A1 (de) * 1996-06-26 1998-01-02 Brink Carsten Dipl Ing Ten Kollisionsvermeidung und Trajektorienplanung beim Mehrroboterbetrieb mit Hilfe von Kollisionsbereichen
JPH1165649A (ja) 1997-08-20 1999-03-09 Yaskawa Electric Corp センサデータのモニタリング方法
JPH11188680A (ja) * 1997-12-22 1999-07-13 Matsushita Electric Works Ltd 部品組付装置
JP2003291083A (ja) * 2002-03-28 2003-10-14 Toshiba Corp ロボット装置、ロボット制御方法及びロボット配送システム
JP2007303866A (ja) 2006-05-09 2007-11-22 Sanki Eng Co Ltd 工場、プラント等における生産設備機器等の運転状態監視システム
JP2012073769A (ja) 2010-09-28 2012-04-12 Kawai Musical Instr Mfg Co Ltd 楽譜認識装置及びコンピュータプログラム
JP2015231640A (ja) * 2014-06-09 2015-12-24 キヤノン株式会社 ロボット動作経路チェック装置、ロボットシステム、ロボット動作経路チェック方法、プログラム及び記録媒体
JP2016155212A (ja) * 2015-02-26 2016-09-01 キヤノン株式会社 ロボット装置
WO2018012446A1 (ja) * 2016-07-11 2018-01-18 Ｇｒｏｏｖｅ Ｘ株式会社 活動量をコントロールされる自律行動型ロボット

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3835008A4

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4144489A4 (en) * 2020-04-28 2023-10-18 Sony Group Corporation Control device, control method, and computer program
CN116880293A (zh) * 2023-07-20 2023-10-13 济南大学 一种基于显式模型预测控制的四足机器人控制方法及控制终端
CN116880293B (zh) * 2023-07-20 2023-12-26 济南大学 一种基于显式模型预测控制的四足机器人控制方法及控制终端

Also Published As

Publication number Publication date
CN112512763B (zh) 2024-11-29
EP3835008A4 (en) 2022-04-13
JP7310820B2 (ja) 2023-07-19
CN112512763A (zh) 2021-03-16
EP3835008A1 (en) 2021-06-16
JPWO2020031718A1 (ja) 2021-08-10
US20210229284A1 (en) 2021-07-29
US12233556B2 (en) 2025-02-25

Similar Documents

Publication Publication Date Title
WO2020031718A1 (ja) 制御装置、制御方法、およびプログラム
JP6462008B2 (ja) 衝突検出
CA2953246C (en) Standby mode of a humanoid robot
JP7156397B2 (ja) 制御装置
JP2015507263A5 (ja)
CN108284434B (zh) 机器学习装置、示教装置的冲击抑制系统及机器学习方法
JP7633404B2 (ja) ロボットの動作プログラムを管理する管理装置、ネットワークシステム、及び方法
JP2024114146A (ja) 情報処理装置、情報処理方法およびプログラム
JP7822401B2 (ja) 作業管理システム、学習装置、推論装置、制御方法及びプログラム
JP7388562B2 (ja) 制御装置、制御方法及びプログラム
CN121870749A (zh) 机器人的异常确定方法、装置和非易失性存储介质
WO2025182029A1 (ja) シミュレーション装置及びプログラム
TH2001006755A (th) ระบบควบคุม ตัวควบคุมและวิธีการควบคุม
Poletti Teleoperation of an underactuated bionic hand: comparison between wearable and vision-based motion tracking methods
Suzuki et al. A multi-layered hierarchical architecture for a humanoid robot
HK1236890A1 (zh) 碰撞检测

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19846081

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020536453

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019846081

Country of ref document: EP

Effective date: 20210309

WWG Wipo information: grant in national office

Ref document number: 17263854

Country of ref document: US