Update of local features model based on correction to robot action

#A robot that has been purchased and put into use may be able to perform a variety of actions. However, in some situations the robot may still perform some actions incorrectly and/or be unable to perform some actions. Such occurrences may be due to a variety of factors such as lack of accuracy and/or robustness of model(s) utilized by the robot in performing actions, varied and/or dynamic environments in which the robot operates, etc. Moreover, for many occurrences of incorrect performance of an action, the robot itself may be unable to recognize the incorrect performance. For example, control processes of the robot may deem an action as correctly performed, despite the performance being incorrect in actuality.

#The present disclosure is directed to methods, apparatus, and computer-readable media (transitory and non-transitory) for determining and utilizing human corrections to robot actions. Some of those implementations are directed to updating a features model of a robot in response to determining a human correction of an action performed by the robot. The features model can be a “local” features model, in that it is utilized by only the robot and/or in that it is stored locally at the robot. The features model is used to determine, based on an embedding generated over a corresponding neural network model, one or more features that are most similar to the generated embedding. For example, the features model may include stored mappings between features and corresponding feature embeddings. A feature can be determined to be most similar to the generated embedding based on the feature being mapped, in the features model, to a feature embedding that is most similar to the generated embedding.

#In such an example, the robot action can be performed based on the feature, and the human correction can indicate that the feature is incorrect and/or that an additional feature is instead correct (or is also correct). In response to the human correction, the features model can be updated. For example, an additional feature embedding that is mapped to the additional feature can be adjusted (i.e., to make it more similar to the generated embedding) and/or the feature embedding that is mapped to the feature in the model can be adjusted (i.e., to make it less similar to the generated embedding). As another example, if the additional feature is not included in the model, the additional feature can be included and assigned a feature embedding that is based on (e.g., the same as) the generated embedding. The features model can be updated in response to human corrections, and can be updated without requiring retraining of the corresponding neural network model.

#FIG. 1 illustrates an example environment in which implementations disclosed herein may be implemented.

#FIGS. 2A, 2B, 2C, and 2D illustrate examples of providing corrections to robot actions.

#FIG. 3 is a flowchart illustrating an example method according to implementations disclosed herein.

#FIG. 1 illustrates an example environment in which implementations disclosed herein may be implemented. The example environment includes a robot 190. Although a particular robot 190 is illustrated in FIG. 1, additional and/or alternative robots may be utilized, including stationary “robot arms”, robots having a humanoid form, robots having an animal form, other robots that move via one or more wheels (e.g., other self-balancing robots, non-self-balancing robots), an unmanned aerial vehicle (“UAV”), and so forth.

#The robot 190 includes robot arms 194a and 194b with corresponding grasping end effectors 196a and 196b, that each take the form of a gripper with two opposing actuable members. The robot 190 also includes a base 193 with wheels 197a and 197b provided on opposed sides thereof for locomotion of the robot 190. The base 193 may include, for example, one or more motors for driving corresponding wheels 197a and 197b to achieve a desired direction, velocity, and/or acceleration of movement for the robot 190.

#The robot 190 also includes a vision sensor 199. The vision sensor 199 may be, for example, a stereographic camera, a monographic camera, or a 3D laser scanner. In some implementations, a stereographic camera includes two or more sensors (e.g., charge-coupled devices (CCDs)), each at a different vantage point. Based on sensor data generated by the two sensors at a given instance, vision sensor data that is three-dimensional (“3D”) point cloud data may be generated for the given instance, where each of the 3D points of the 3D point cloud defines a 3D coordinate of a surface of a corresponding object. In some other implementations, a stereographic camera may include only a single sensor and one or more mirrors utilized to effectively capture sensor data from two different vantage points. A monographic camera can include a single sensor and captures two-dimensional (“2D”) vision sensor data. A 3D laser scanner includes one or more lasers that emit light and one or more sensors that generate vision sensor data related to reflections of the emitted light. The generated vision sensor data from a 3D laser scanner may be 3D point cloud data. A 3D laser scanner may be, for example, a time-of-flight 3D laser scanner or a triangulation based 3D laser scanner and may include a position sensitive detector (PSD) or other optical position sensor.