PROBABILISTIC AUTOMATIC EXECUTION SYSTEM FOR ROBOT PROGRAMMING

Abstract

Various aspects of techniques, systems, and use cases can be employed for the probabilistic automatic determination of an action for a robotic device. A technique might involve identifying a current context for the robotic device, determining a set of actions executable by the robotic device according to the at least one object from that current context (where the set of actions includes one or more affordances generated from a basic capability library for the robotic device), and automatically selecting an action from the set of actions based on an acyclic graph describing action paths. The technique might also include issuing control signals which, when executed, cause the robotic device to perform the action to interact with the at least one object.

Description

BACKGROUNDRobots and other autonomous agents may be programmed to perform complex tasks in the real world. Robotics has developed the field of using artificial intelligence (AI) technologies to perform tasks in industrial environments, among numerous other environments. For example, robotics extends over a wide range of industrial applications such as smart manufacturing production lines, multi-robot automotive component assembly, computer and consumer electronics manufacturing, smart retail and warehouse logistics, robotic data centers, etc. Often, robots interact with humans to accomplish tasks.BRIEF DESCRIPTION OF THE DRAWINGSIn the drawings, which are not necessarily to scale, like reference numerals may describe similar components in different views. Like reference numerals having different letter endings may represent different examples of similar components. The drawings illustrate generally, by way of example, but not limitation, various embodiments discussed in the present document. FIG. 1 illustrates teleoperation and autocompleted (autocompleted) system building blocks for use with a robotic device (robotic device) according to an example. FIG. 2 illustrates a diagram showing example basic capabilities (skil) representations, according to an example. FIG. 3 illustrates example actions taken (requested) by a screw including a relative pose (pose) of an end effector for each of the affordances, according to an example. FIG. 4 shows an example acyclic affordance graph for a task, according to an example. FIG. 5 illustrates an augmented reality (AR) control interface including proposed actions for a robotic device according to an example. FIGS. 6A and 6B show flowcharts illustrating techniques for probabilistically automatically determining an action for a robotic device according to an example. FIG. 7A provides an overview of example components for computing deployed at a compute node. FIG. 7B provides another overview of example components within a computing device.DETAILED DESCRIPTIONThe systems and techniques described herein provide probabilistic auto-execution robotic tasks with a robotic device. An auto-completion robot task automatically completed robot task may include a affordance, such as one generated from a set of basic capabilities for the robot device. The affordance may be selected, such as based on a human-executed augmented reality (AR) gesture, a human-executed virtual reality (VR) gesture, a joystick (e.g., a 6D joystick) input, a game control input, a marker-based body tracking motion (VR), a markerless body tracking motion, or the like. The affordance may be selected from one or more affordances of an affordance acyclic graph, such as a graph generated for a particular task (e.g., attaching a component to a circuit board).Robotic telematics systems typically focus on fine control of the robotic joints or end effector. A human may control the fine grain movement of the end effector or a gripper to demonstrate or perform a manipulation task. This type of robot control has the advantage of fine control of the end effector, but has disadvantages in productivity. Fine-grained teleoperation tends to be slow and when high precision is required, the tasks of humans are performed carefully, resulting in examples that are much slower than average human performance. The systems and techniques described herein provide a technical improvement by utilizing already performed task demonstrations to train a model that learns possible actions that an object enables, possible actions that a task enables, or the manner in which movements are performed. Using a vocabulary of affordances and movements, the systems and techniques described herein can be used to assist a teleoperator in rapidly defining new tasks not previously seen. In some examples, such as during runtime, a prediction of a human collaboration intention may be issued to improve task flow.If there is a task that uses a new capability, or an operator determines that a capability can be improved (e.g., fine tuned to be faster, requiring less processing, etc.), a system may provide an option to manipulate a single action or generate a new action. The operator may take control of, such as disabling a snap-fit option to provide fine-grained corrections. Depending on the accuracy of the auto-completion suggestions, the level of difficulty of the task, and the sparsity of the actions, tasks may be programmed in a few seconds, rather than minutes or even hours.The systems and techniques described herein may identify a probabilistic task and use an affordance and action-sharing inference mechanism to suggest a top ranking or set of fine-grained actions in real-time or near real-time, such as while demonstrating the task. A teleoperation interface can be used to allow the user to seamlessly accept action suggestions from a multiple-choice list or to continue with the fine-grained demonstration.FIG. 1 illustrates teleoperation and auto-completion system building blocks for use with a robotic device according to an example. A system 100 shown in FIG. 1 shows a user 102 and a robotic device 108 (e.g., a robotic arm, a robot, an autonomous device, etc.). The user 102 may use a control interface 104 to issue commands to the robotic device 108. The control interface 104 may detect (e.g., via a camera or other sensor) a gesture, motion, or other command (e.g., motion) of the user 102. The movement of the user 102 may be interpreted by the control interface 104, for example, to auto-complete a command that may be issued for display, such as selection or confirmation by the user 102, or may be used to automatically control the robotic device 108 (e.g., using the controller gate (controller gate) 106). After selection or confirmation, the control gate 106 may be used to control the robotic device 108. The control interface 104 may include an AR control interface, a VR control interface, a controller, a joystick, or a combination thereof.The control interface 104 may detect motion of the user 102 and use a common task affordance action inference 112 along with captured or input scene and robot sensor information 110 to determine a context and available affordance for controlling the robotic device 108. An action auto-completion generation component 114 may be used to identify a command from the motion, for example, using a trajectory of the motion. An AR auto-completion overlay interface display component 116 may output one or more particular prompts (e.g., based on the context and the command) for display. The user 102 may select or confirm an affordance output by the component 114, and the robotic device 108 may be controlled using the affordance to generate a control signal at the control gate 106.In some examples, an output affordance may include predictions as a probability function. The predictions may extend over various actions, affordances, or trajectories that are potentially performed (e.g., in the motion of the user 102 and in the context of the user 102 or the robotic device 108). A set of predictions, e.g., likely ordered, may be presented to the user 102 when an action the user performs is in a list (e.g., stored in a list of actions). The user 102 may accept a suggestion, proceed to the next step, and avoid completion of the demonstration. In some examples, the system 100 is used to improve collaboration. User 102 intent predictions may be used to improve task flow. In some examples, multiple actions may be detected or identified, for example, with a prediction horizon that is longer than a short motion.FIG. 2 illustrates a diagram showing example basic capabilities representations, according to an example. FIG. 2 includes a basic capability representation example. The straight arrows represent a global-based 206 task frame and an object-based 208 task frame. An "X" may represent a key point associated with an end effector of a robotic device 202 or object 204. The arrows from the robotic device 202 to the object 204 represent trajectories for the robotic device 202 that may be generated with a minimum jerk, a dynamic movement primitive (DMP), or according to any other motion characteristic.A system using the robotic device 202 may be trained, for example, at a location where the system is deployed or as part of the development of the system at a pre-training stage. The system may be configured to learn basic action building blocks that may depend on the embodiment. In particular, the modules can be dependent on any specific robot kinematics and dynamics.Basic ski learning (BSL) may be performed with the robot device 202. There are several types of capability representations that can be used in teleoperation, such as DMP, probabilistic movement primitives (ProMP), neural networks, etc. A variety of capabilities, such as different motion styles, to accomplish a running task can be used with the robotic device 202. For example, a library may be created that is parameterized by context, key points, task requirements, etc., such as by using multiple existing representations.Training data, if available, may be used, or zero shot representations, such as minimum jerk, may be used in some examples. To compile trajectories generated from different representations, a zero-space projection method may be used.FIG. 3 illustrates example actions taken by a screw 302 including a relative posture of an end effector for each of the affordances, according to an example. The example affordances in FIG. 3 include receiving the screw 302, inserting the screw 302 (e.g., into a screw hole), and threading or unscrewing the screw 302. In various contexts, other actions may be provided (e.g., releasing the screw 302). The actions may be based on an orientation of an end effector of a robotic device. For example, the arrows shown in FIG. 3 may represent a trajectory of the end effector. The example affordances shown are representative and may not be actually shown (e.g., only affordances that are near the trajectory may be shown, while others of the example affordances may not be shown). FIG. 3 shows example actions taken by a screw based on a relative posture of the end effector valid for each of the affordances. In some examples, such as "take" (pick), one permitted action may be taken from multiple relative end effector postures, while other permitted actions, such as threading, unthreading, or insertion, may be limited to only one or a limited range of relative postures.Object requirements may be defined as a possibility of action on an object. A screw, for example, allows to be screwed in (or received or placed or inserted, etc.). When a robotic system uses the affordance concept, the manner of executing the enabled action may be based on specific motor commands (e.g., capabilities (capabilities) of a robotic device). An affordance may include, for example, a definition of force required to perform an action (e.g., a range, a value, etc.), a relationship between the robot end effector and the object to properly perform the action, a trajectory, etc. Each object affordance may be satisfied with multiple configurations, for example. A screw may enable one or more of: take, place, insert, screw in, unscrew out, drop, or the like. FIG. 3 illustrates various relative end effector positions that may be used to perform the various actions allowed (e.g., the arrows of FIG. 3 ). Affordances are object-specific and can be gripper-specific (e.g. specific for a specific handle of an end effector of a robot). The object requirements may be extracted depending on the object geometry, actions permitted by the object, a gripper used to perform the tasks, or the like. Object requirements can be automatically extracted from videos of a human or robot manipulating objects and performing tasks with them. To map the extracted object affordances to the specific robot gripper, affordances can be calculated using simulation techniques in combination with reach schedulers (grasp schedulers) that can determine whether object-gripper configurations yield stable manipulations. If objects are not known, the concept of affordances can be applied to specific geometric features of unknown objects.FIG. 4 illustrates an example acyclic affordance graph 400 for a task, according to an example. The example affordance graph includes learned graph edges and nodes for an example bolting task with a drill. The affordance graph may be built or modified over time, for example, by adding a new task, removing a task, adding a new connection, removing a connection, etc. The task affordance extraction and action chains may be generated and stored for use with a robotic device. The affordance graph 400 may be specific to a robot device, specific to context, or include task chains specific to a task, or the like.Affordances may be used as nodes of the affordance graph 400, with connections (e.g., edges) directed (directional) in some examples, and representing a next task in a particular set of affordances. The affordances may be generated from basic capabilities (e.g., as described above). The affordances may be represented at different granularities, such as from an entire task definition to a particular motion configuration trajectory with their radians positions and speeds. These affordances may be represented in acyclic affordance graph 400, possibly directed (directed), meaning that the connections between nodes may be in one direction. The nodes of the affordance graph 400 may include a specific task, and the vertices may include possible transitions of each of the tasks.Defining an affordance graph 400 in this form allows for easy introduction of new tasks, such as at execution time, by identifying a new task (e.g., a new node) and creating a properly directed vertex in the graph structure. Adding a new task, such as placing a CPU, may be represented, for example, by the nodes labeled "NEW" in the affordance graph 400. Adding the new nodes may also include adding the directional edges (Directional Edges). The transitions may be learned or specified manually, and an affordance may include a low-level trajectory that the robot is to execute (e.g., go home). Low-level affordance may coexist with higher-level tasks provided by vertex connectivity in the graph. In some examples, the affordance graph 400 may be used to arrange a computer.The affordance graph 400 may be used to obtain possible results (e.g., action chains or affordance paths) for a robotic device. An observation window may be defined, for example, by associating human actions with states (e.g., a node) and transitions (e.g., a vertex) from the affordance graph 400, along with the goals or results detected at the training stage. A K-best search graph algorithm can be used to provide a set of current state solutions to the reachable targets. The solutions may be used to indicate actions that a robotic device may do, for example, to a user to accept or select the task's completion.In some examples, the target prediction may improve with more task observations. The task affordance extraction may complete a path such as from "take screw A" to "drive in hole 1F", along a path from "take screw A" to "transport screw B" to "place screw 1C" to "take drill D" to "transport drill E" to "drive in hole 1F". In this example, the path formed may define a desired task of a user (e.g., threading a screw into a hole 1). As shown in the affordance graph 400, similar or similar affordance tasks may be separately identified from the robot perspective (e.g., placing a screw, bolting, etc.) in the affordance graph 400 for different locations or contexts (e.g., hole 1, hole 2, or placing screw 1, placing screw 2, placing screw 3). In these examples, the screws may not be considered independently (although for the taking of a screw, the particular screw may be specified by where the robotic device is), for example, in some examples, any screw may fit into any hole, while holes may be specified as they are at different end locations. Thus, the "take screw" step can be used as a starting requirement for the final driving of three different screws into three different holes.Using the observation window, the affordances can be stacked, such as "taking a screw", "transporting screw", and "placing screw 1". The last action can be used as a starting node and the possible finalization task as a target, such as "placing CPU", "taking screw", and "screwing in hole 1". The action chains may include a path for finding solutions from start to destination usable by a user to determine whether the robot can do the task. The next observed state may be named when a user does not select the first option, which may be used to reduce the possible task action termination and provide a more accurate path. Observed action strings may be stored in a dataset for further learning or updating to probabilistic relationships between the various objects and affordances. The probabilistic relationships may be stored with data relating to a state of the robot or environment, an object, the task being performed, previous actions, or the like.In one example, a user teleoperation movement may be received and a set of ordered actions or action chains may be outputted. The output may be displayed to the user (e.g., in AR) as auto-completion candidates. The user movement may be detected by a camera or other sensor. The user movement may be used to generate a probability distribution of possible affordance object-action pairs (e.g., from affordance graph 400). The intention of the user may be predicted and aligned with the possible actions that may be taken. Inference may be affected by the introduction of another context, such as hints that include information about a possible next action. For example, previous actions, the current task, object positions may be used to weight probabilities of the next actions. For example, object requirements may be used in a prediction pipeline. The trajectory that the user operator brings to the robot can be predicted, and an used affordance can be predicted. In some examples, based on the prediction, an action may snap (snap to) into a pre-generated relative end effector posture compatible with the predicted affordance. For example, the user need not accurately align with the affordance or action of the robot, but rather an affordance or action may be predicted (or a set of probabilities may be predicted) based on the user being within a threshold distance, angle, trajectory, or orientation. The threshold may be used to determine a probability (e.g., 75% may be closer to gesture A than indicating to gesture B for a probability of 90% that affordance A corresponding to gesture A is the correct affordance).In one example, an inference to determine a likely next affordance includes establishing a set of Zielerreichungshypothesen generating possible trajectories that reach the targets, and comparing the possible trajectories with sensor data (e.g., from a robotic device) to order the possible trajectories according to the probability. The likely trajectories may be ranked or filtered (e.g., by excluding those that are below a threshold probability). In one example, dimensionality of the inference space may be increased to include an affordance action label. In one example, the generated trajectories may be forced to "snap" into the end effector postures relative to the object for affordance. The number of hypotheses to evaluate can be greatly reduced using these two example adjustments, and inference can be expedited. An output may include a probability distribution over affordances for each object. For example, each pair of object affordance may be labeled with a probability of being the next action to be performed.Auto-completion action generation may be used, for example, by automatically generating action candidates by scanning from the task distribution. This may depend on the teleoperation trajectory being performed or a previously performed action. By scanning multiple times, a sequence of actions can be proposed as an auto-completion action chain that can be accepted or rejected by the operator.FIG. 5 illustrates an augmented reality (AR) control interface including proposed actions for a robotic device according to an example. An AR control interface may be used to control a robotic device 504. A user may control an end effector of the robotic device 504 to perform a take action on a cube, for example cube 508. A user's hand trajectory 506 may be determined to predict an affordance for the robotic device 504. A predicted intent may be used to generate one or more action chain suggestions. The one or more action chain suggestions may be displayed in a virtual display or on a physical display, such as at the user interface 502. The user interface 502 in the example of FIG. 5 shows three different take, transport, and place options with three different trajectories corresponding to trajectories A, B, and C illustrated with respect to the cube 508. The user may review the proposed auto-completion actions, such as overlaid on the AR display at user interface 502, and decide whether to accept a proposal and proceed to the next steps of the program.The augmented reality control interface may be used to superimpose a current state of the robotic device 504 or other information, such as a current estimated state of the environment, the candidate actions, or the like. The augmented reality control interface may capture a user command, for example, via a handheld controller or hand gesture (e.g., corresponding to hand trajectory 506), for teleoperation of the robotic device 504, such as by using fine-grained position control, or for searching or accepting suggested action authorities.The user may indicate that fine-grain control is being performed, for example, by maintaining activation of a "TELEOP" signal, for example, encoded as a hand gesture, or by pressing and holding a trigger on a handheld device. In TELEOP mode, actions may be suggested and their representations may be overlaid on top of the operator field of view (e.g., in user interface 502). The operator may trigger an "ACCEPT" signal through a controller or hand gesture to accept the first action proposed in order, for example. Another option may include stopping the "TELEOP" signal, searching the suggested actions, selecting an action, re-activating the "TELEOP" signal to continue fine grain robot control, or the like.FIGS. 6A-6B show flowcharts illustrating probabilistically automatically determining an action for a robotic device, according to an example. The techniques 600A- 600B may be performed by a computing device (e.g., including processing circuitry), a robotic device, etc. Technique 600A includes generating an acyclic affordance graph, and technique 600B shows use of the acyclic affordance graph. Techniques 600A and 600B may be used together or separately. For example, one entity may generate the acyclic affordance graph and another entity may use the acyclic affordance graph.The technique 600 includes an operation 602 for generating a basic capabilities library of primitives executable by a robotic device. The technique 600 includes an operation 604 for automatically extracting a set of affordances for one or more objects, for example extracted from video data of the one or more objects being manipulated (e.g., by a robotic device or human). The set of affordance may be specific to an orientation of the one or more objects.The technique 600 includes an operation 606 to identify a task to be accomplished by the robotic device, including at least one object involved in the task.The technique 600 includes an operation 608 to generate an acyclic affordance graph for the task based on the set of affordances for the at least one object. The acyclic affordance graph may include at least one action available only when at least one other action has been done. The acyclic affordance graph may include weights assigned to affordances of the acyclic affordance graph. The technique 600 includes an operation 610 for outputting (e.g., storing, displaying, transmitting, etc.) the acyclic affordance graph to generate a proposed action for the robotic device to complete the task.The technique 600 includes an operation 612 to identify a current context of a robotic device. The current context may include identifying at least one object present in a field of view. The current context may include identifying all objects that are in a field of view, a trajectory of the robotic device, a task to be accomplished, or the like.The technique 600 includes an operation 614 to determine from the current context a set of actions executable by the robotic device corresponding to the at least one object. The set of actions may include one or more affordances generated from a basic capabilities library for the robotic device. The set of actions may be generated by automatically extracting tasks from video or image data captured by the robotic device. The basic capabilities library may include one or more dynamic motion actions including at least one of grasping an object, moving an object, releasing an object, or the like.The technique 600 includes an operation 616 to automatically select an action from the set of actions based on an acyclic graph describing action paths. The action may be conditional, for example, based on an action previously performed by the robotic device. Operation 616 may include determining that two or more actions of the acyclic graph are selectable based on the current context, and selecting the action based on a probability for each of the two or more actions.The technique 600 includes an operation 618 of outputting control signals that, when executed, cause the robotic device to perform the action to interact with the at least one object. The robotic device may be controlled using a gesture via an augmented reality interface, a virtual reality interface, a joystick (e.g., a 6D joystick) input, a game control input, a marker-based body tracking motion, a markerless body tracking motion, or the like. The gesture may be displayed in the AR interface, the VR interface, on a display screen, or the like. The current context may include identifying the gesture or other input. The technique 600 may include receiving a user confirmation of the action prior to outputting the control signals.In further examples, any of the compute nodes or devices discussed with reference to the present edge computing systems and environments may be satisfied based on the components as shown in FIGS. 7A and 7B. Respective edge compute nodes may be embodied as a type of device, application, computer, or other "ping" capable of communicating with other edge, network, or endpoint components. An edge computing device may be embodied, for example, as a personal computer, a server, a smartphone, a mobile computing device, a smart application, an on-board computing system (e.g., a navigation system), a self-contained device including an outer housing, a shell, etc., or another device or system capable of performing the described functions.In the simplified example shown in FIG. 7A, an edge compute node 700 includes a compute engine (also referred to herein as "compute circuitry") 702, an input / output (I / O) subsystem 708, a data storage 710, a communication circuitry subsystem 712, and optionally one or more peripheral devices 714. In other examples, respective computing devices may include other or additional components, such as those commonly found in a computer (e.g., a display, peripheral devices, etc.). Additionally, in some examples, one or more of the representative components may be incorporated into or otherwise form a portion of another component.The compute node 700 may be embodied as any type of machine, device, or collection of devices capable of performing various computing functions. In some examples, the compute node 700 may be embodied as a single device, such as an integrated circuit, embedded system, field programmable gate array (FPGA), system-on-a-chip (SoC), or other integrated system or device. In the illustrative example, the compute node 700 includes or is embodied as a processor 704 and a memory (memory) 706. Processor 704 may be embodied as any type of processor capable of performing the functions described herein (e.g., executing an application). For example, processor 704 may be embodied as a multi-core processor(s), a microcontroller, a processing unit, a specialized or special purpose processing unit, or other processor or processing / control circuitry.In some examples, processor 704 may be embodied as, include, or be coupled to an FPGA, an application specific integrated circuit (ASIC), reconfigurable hardware or hardware circuitry, or other specialized hardware to enable performance of the functions described herein. In some examples, processor 704 may also be embodied as a specialized x-processing unit (xPU), also known as a data processing unit (DPU), infrastructure processing unit (IPU), or network processing unit (NPU). Such an xPU may be embodied as a stand-alone circuit or circuit package, integrated into an SOC, or integrated with network circuitry (e.g., in a SmartNIC or an enhanced SmartNIC), acceleration circuitry, storage devices, or AI hardware (e.g., GPUs or programmed FPGAs). Such an xPU may be designed to receive programming for processing one or more data streams and to perform specific tasks and actions for the data streams (such as hosting microservices, performing service management or orchestration, organizing or managing server or data center hardware, managing service networks, or collecting and distributing telemetry) external to the CPU or general purpose processing hardware. However, it should be appreciated that an xPU, SOC, CPU, and other variants of processor 704 may operate in coordination with one another to perform many types of operations and instructions within and on behalf of computing node 700.The memory 706 may be embodied as any type of volatile (e.g., dynamic random access memory (DRAM), etc.) or nonvolatile memory or data storage capable of performing the functions described herein. Volatile memory may be a storage medium that requires power to maintain the state of data stored by the medium. Non-limiting examples of volatile memory may include various types of random access memory (RAM), such as DRAM or static random access memory (SRAM). One particular type of DRAM that may be used in a memory module is synchronous dynamic random access memory (SDRAM).In one example, the memory device is a block addressable memory device, such as those based on NAND or NOR technologies. A storage device may also include a three-dimensional cross-point storage device (e.g., Intel® 3D XPoint™ memory), or other byte addressable write-in-place non-volatile storage devices. The storage device may refer to the die itself and / or to a packaged storage product. In some examples, 3D cross-point memory (e.g., Intel® 3D XPoint™ memory) may comprise a transistorless stackable cross-point (cross-point) architecture in which memory cells sit at the intersection of word lines and bit lines and are individually addressable, and in bit storage is based on a change in bulk resistance. In some examples, all or a portion of memory 706 may be integrated with processor 704. The memory 706 may store various software and data used during operation, such as one or more applications, data operated on by the application(s), libraries, and drivers.The computing circuitry 702 is communicatively coupled to other components of the computing node 700 via the I / O subsystem 708, which may be embodied as circuitry and / or components to facilitate input / output operations with the computing circuitry 702 (e.g., with the processor 704 or the main memory 706) and other components of the computing circuitry 702. For example, the I / O subsystem 708 may be embodied as, or otherwise include, memory controller hubs, input / output controller hubs, integrated sensor hubs, firmware devices, communication links (e.g., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and / or other components and subsystems to enable the input / output operations. In some examples, the I / O subsystem 708 may form a portion of a system-on-a-chip (SoC) and be incorporated into the computing circuitry 702 along with one or more of the processor 704, the memory 706, and other components of the computing circuitry 702.The one or more illustrative data storage devices 710 may be embodied as any type of device configured for short-term or long-term storage of data, such as storage devices and circuitry, memory cards, hard disk drives, solid-state drives, or other data storage devices. Individual data storage devices 710 may include a system partition that stores data and firmware code for the data storage device 710. Individual data storage devices 710 may also include one or more operating system partitions that store data files and executables for operating systems, e.g., depending on the type of computing node 700.Communication circuitry 712 may be embodied as any communication circuit, device, or collection thereof capable of enabling communications over a network between computing circuitry 702 and another computing device (e.g., a gateway of an implementation computing system). Communication circuitry 712 may be configured to use any one or more communication technologies (e.g., wired or wireless communication) and associated protocols (e.g., a cellular network protocol such as a 3GPP 4G or 5G standard, a wireless local area network protocol such as IEEE 802.11 / Wi-Fi® a wireless wide area network protocol, Ethernet, Bluetooth® Bluetooth Low Energy, an IoT protocol such as IEEE 802.15.4, or ZigBee®, Low-power wide area network (LPWAN) or low-power wide area (LPWAN) protocols, etc.) to effect such communication.The illustrative communication circuitry 712 includes a network interface controller (NIC) 720, which may also be referred to as a host fabric interface (HIF). The NIC 720 may be embodied as one or more add-in boards, daughter cards, network interface cards, controller chips, chipsets, or other devices that may be used by the compute node 700 to connect to another compute device (e.g., a gateway node). In some examples, the NIC 720 may be embodied as part of a system-on-a-chip (SoC) that includes one or more processors, or included on a multi-chip package that also includes one or more processors. In some examples, the NIC 720 may include a local processor (not shown) and / or local memory (not shown), both local to the NIC 720. In such examples, the local processor of the NIC 720 may be capable of performing one or more of the functions of the computing circuitry 702 described herein. Additionally or alternatively, in such examples, the local memory of the NIC 720 may be integrated into one or more components of the client computing node at the board level, socket level, chip level, or other levels.In some examples, a respective compute node 700 may additionally include one or more peripheral devices 714. Such peripheral devices 714 may include any type of peripheral device found in a computing device or server, such as audio input devices, a display, other input / output devices, interface devices, and / or other peripheral devices, depending on the particular type of computing node 700. In further examples, compute node 700 may be embodied by a respective compute node (whether a client, gateway, or aggregation node) in a computing system or similar forms of applications, computers, subsystems, circuitry, or other components.In a more detailed example, FIG. 7B shows a block diagram of an example of components that may be present in a compute node 750 to implement the techniques (e.g., operations, processes, methods, and methodologies) described herein. This compute node 750 provides a more detailed consideration of the respective components of node 700 when implemented as a computing device (e.g., a mobile device, base station, server, gateway, etc.) or as part of a same. The compute node 750 may include any combinations of the hardware or logic components recited herein and may include or couple to any device usable with a communication network or combination of such networks. The components may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices or other modules, instruction sets, programmable logic or algorithms, hardware, hardware accelerators, software, firmware, or a combination thereof, adapted in computing node 750, or as components otherwise incorporated within a housing of a larger system.Computing device 750 may include processing circuitry in the form of a processor 752, which may be a microprocessor, a multi-core processor, a multi-threaded processor, an ultra-low voltage processor, an embedded processor, an xPU / DPU / IPU / NPU, a special purpose processing unit, a specialized processing unit, or other known processing elements. The processor 752 may be part of a system-on-a-chip (SoC) where the processor 752 and other components are formed into a single integrated circuit, or into a single package, such as the Edison™ or Galileo™ SoC boards from Intel Corporation of Santa Clara, California. As an example, processor 752 may include a Intel® Architecture Core™ based CPU processor, such as a Quark™ a Atom™ an i3, an i5, an i7, an i9, or an MCU class processor, or other such processor available from Intel®. However, any number of other processors may be used, such as those available from Advanced Micro Devices, Inc. (AMD®) of Sunnyvale, California, a MIPS® based design from MIPS Technologies, Inc. of Sunnyvale, California, a ARM® based design licensed by ARM Holdings, Ltd. or a customer thereof or their licenseee or user. The processors may include units such as an A5-A13 processor from Apple® Inc., an Snapdragon™ processor from Qualcomm® Technologies, Inc., or an OMAP™ processor from Texas Instruments, Inc. Processor 752 and the accompanying circuitry may be provided in a single socket form factor, a multiple socket form factor, or in a variety of other formats, including in limited hardware configurations or configurations that include less than all of the elements illustrated in FIG. 7B.Processor 752 may communicate with system memory 754 via a connection 756 (e.g., a bus). Any number of memory devices may be used to provide a given amount of system memory. As examples, the memory 754 may be random access memory (RAM) according to a joint electron device engineering council (JEDEC) design such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In certain examples, a memory component may comply with a DRAM standard promulgated by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for low power DDR (LPDDR), JESD2000-2 for LPDDR2, JESD2000-3 for LPDDR3, and JESD2000-4 for LPDDR4. Such standards (and similar standards) may be referred to as DDR-based standards, and communication interfaces of the storage devices implementing such standards may be referred to as DDR-based interfaces. In various implementations, the individual memory devices may be made of any number of different package types, such as a single die package (SDP), a dual die package (DDP), or a quad die package (Q17P). In some examples, these devices may be soldered directly to a motherboard to provide a lower profile solution, while in other examples, the devices are configured as one or more memory modules that in turn couple to the motherboard through a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of various variants including, but not limited to, microDIMMs or MiniDIMMs.To enable persistent storage of information such as data, applications, operating systems, etc., storage 758 may also couple to processor 752 via connection 756. In an example, storage 758 may be implemented via a solid state disk drive (SSDD). Other devices that may be used for storage 758 include flash memory cards such as secure digital (SD) cards, microSD cards, eXtreme Digital (XD) video cards, and the like, as well as universal serial bus (USB) flash drives. In one example, the memory device may be or include memory devices including chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeRAM), anti-ferroelectric memory, magnetoresistive random access memory (MRAM) incorporating memristor technology, resistive memory including the metal oxide base, the oxygen vacancy base, and the conductive bridge random access memory (CB-RAM; The invention is directed to a device for using a conductive bridge random access memory), or spin transfer torque (STT) MRAM, a spintronic magnetic junction memory-based device, a magnetic tunneling junction (MTJ)-based device, a domain wall (DW) and spin orbit transfer (SOT)-based device, a thyristor-based memory device, or a combination of any of the above or another memory.In low-power implementations, the storage 758 may be on-die memories or registers associated with the processor 752. However, in some examples, storage 758 may be implemented using a hard disk drive (HDD). Further, in addition to or in place of the described technologies, any number of new technologies may be used for storage 758, such as, but not limited to, resistance change memory, phase change memory, holographic memory, or chemical memory.The components may communicate via the connection 756. The interconnect 756 may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The connection 756 may be, for example, a proprietary bus used in a SoC-based system. Other bus systems may be included, such as an inter-integrated circuit (I2C) interface, a serial peripheral interface (SPI) interface, point-to-point interfaces, and a power bus, among others.The link 756 may couple the processor 752 to a transceiver 766 for communication with the connected devices 762. The transceiver 766 may use any number of frequencies and protocols, e.g., 2.4 gigahertz (GHz) transmissions under the IEEE 802.15.4 standard, using the Bluetooth® Low Energy (BLE) standard as defined by the Bluetooth® Special Interest Group, or the ZigBee® standard, among others. Any number of radio devices configured for a particular wireless communication protocol may be used for connections to the connected devices 762. For example, a wireless local area network (WLAN) unit may be used to implement Wi-Fi® communication according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. Moreover, wireless wide area communication, e.g., according to a cellular or other wireless wide area protocol, may be via a wireless wide area network (WWAN) unit.The wireless network transceiver 766 (or multiple transceivers) may communicate using multiple standards or radios for communication in a different area. For example, the compute node 750 may communicate with devices in the vicinity, e.g., within about 10 meters, using a local transceiver based on Bluetooth Low Energy (BLE) or other low-power radio device to conserve power. More remote connected devices 762, e.g., within about 50 meters, may be reached via ZigBee® or other medium power radio. Both communication techniques may be via a single radio at different power levels or via separate transceivers, e.g., a local transceiver using BLE and a separate mesh transceiver using ZigBee®.A wireless network transceiver 766 (e.g., a radio transceiver) may be included for communication with devices or services in the cloud 795 via local or wide area network protocols. The wireless network transceiver 766 may be a low-power wide-area (LPWA) transceiver that complies with, among other things, the IEEE 802.15.4 or IEEE 802.15.4g standards. The compute node 750 may communicate over a wide range using LoRaWAN™ (long range wide area network) developed by Semtech and LoRa Alliance. The techniques described herein are not limited to these technologies, but may be used with any number of other cloud transceivers implementing long range, low bandwidth communication, such as Sigfox and other technologies. Further, other communication techniques such as time-slotted channel hopping described in the IEEE 802.15.4e specification may also be used.In addition to the systems mentioned for wireless network transceiver 766, any number of other radio communications and protocols may be used as described herein. The transceiver 766 may include, for example, a cellular transceiver that uses spread spectrum (SPA / SAS) communication to implement high speed communication. Further, any number of other protocols may be used, e.g., Wi-Fi® networks for medium speed communication and the provision of network communication. The transceiver 766 may include radio devices compatible with any number of third generation partnership project (3GPP) specifications, such as long term evolution (LTE) and 5thgeneration (5G) communication systems, discussed in more detail at the end of the present disclosure. A network interface controller (NIC) 768 may be included to provide wired communication with nodes of the cloud 795 or with other devices, such as the connected devices 762 (e.g., operating in a mesh). Wired communication may provide an Ethernet connection or may be based on other types of networks, such as controller area network (CAN), local interconnect network (LIN), deviceNet, controlNet, data highway+, PROFIBUS, or PROFINET, among many others. An additional NIC 768 may be included to enable connection to a second network, e.g., a first NIC 768 providing communication with the cloud over Ethernet and a second NIC 768 providing communication with other devices over a different network type.Given the plurality of types of applicable communications from the device to another component or network, the applicable communication circuitry used by the device may include or be embodied by one or more of components 764, 766, 768, or 770. Accordingly, in various examples, applicable means for communication (e.g., receiving, transmitting, etc.) may be implemented by such communication circuitry.Computing node 750 may include or be coupled to acceleration circuitry 764, which may be implemented by one or more artificial intelligence (AI) accelerators, a neural computer stick, neuromorphic hardware, an FPGA, an array of GPUs, an array of xPUs / DPUs / IPU / NPUs, one or more SoCs, one or more CPUs, one or more digital signal processors, dedicated ASICs, or other forms of specialized processors or circuitry designed to perform one or more specialized tasks. These tasks may include AI processing (including machine learning, training, interference, and classification operations), visual data processing, network data processing, object detection, rule analysis, or the like. These tasks may also include the specific computing tasks for service management and operations discussed elsewhere in this document.The connection 756 may couple the processor 752 to a sensor hub or external interface 770 used to connect additional devices or subsystems. The devices may include sensors 772, such as acceleration sensors, level (level) sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, global navigation system (e.g., GPS) sensors, pressure sensors, barometric pressure sensors, and the like. The hub or interface 770 may be further used to connect the computing node 750 to actuators 774, e.g., power switches, valve actuators, an audible sound generator, a visual warning device, and the like.In some optional examples, various input / output (I / O) devices may be present in or connected to compute node 750. For example, a display or other output device 784 for displaying information such as sensor readings or actuator position may be included. An input device 786, such as a touch screen or keypad, may be included to accept input. An output device 784 may include any number of forms of audio or visual display, including simple visual outputs such as binary status displays (e.g., light emitting diodes (LEDs)) and multi-character visual outputs or more complex outputs such as display screens (e.g., liquid crystal displays (LCDs)), wherein the output of characters, graphics, multimedia objects, and the like is generated or produced by the operation of the compute node 750. Display or console hardware may be used in connection with the present system to provide outputs of a computing system and receive inputs thereof, manage components or services of a computing system, identify a state of a computing component or service, or execute any other number of management or management functions or service application instances.A battery 776 may power the compute node 750, although in examples where the compute node 750 is fixed in a fixed location, it may have a power supply coupled to an electrical grid or the battery may be used as a backup or for temporary capabilities. The battery 776 may be a lithium ion battery or a metal air battery, such as a zinc air battery, an aluminum air battery, a lithium air battery, and the like.A battery monitor / charger 778 may be included in the compute node 750 to track the state of charge (SoCh) of the battery 776 if included. The battery monitor / charger 778 may be used to monitor other parameters of the battery 776 to provide fault predictions, such as the state of health (SoH) and the state of function (SoF) of the battery 776. The battery monitor / charger 778 may comprise a battery monitor integrated circuit such as LTC4020 or LTC2990 from Linear Technologies, ADT7488A from ON Semiconductor of Phoenix, Arizona, or IC from the UCD90197 family from Texas Instruments of Dallas, TX. The battery monitor / charger 778 may communicate the information about the battery 776 to the processor 752 via the connection 756. The battery monitor / charger 778 may also include an analog-to-digital (ADC) converter that enables the processor 752 to directly monitor the voltage of the battery 776 or the current flow from the battery 776. The battery parameters may be used to determine actions that the compute node 750 may perform, such as transmission frequency, mesh network operation, sensing frequency, and the like.A power block 780 or other power supply coupled to a grid may be coupled to the battery monitor / charger 778 to charge the battery 776. In some examples, the power block 780 may be replaced with a wireless power receiver to wirelessly receive the power, for example, a loop antenna in the compute node 750. A wireless battery charging circuit, such as, but not limited to, an LTC1640 chip from Linear Technologies of Milpitas, California, may be included in the battery monitor / charger 778. The specific charging circuits may be selected based on the size of the battery 776 and thus the required current. Charging may be performed using, among other things, the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Reference Charging standard promulgated by the Alliance for Wireless Power.The storage 758 may include instructions 782 in the form of software, firmware, or hardware instructions to implement the techniques described herein. Although such instructions 782 are shown as code blocks included in memory (memory) 754 and storage (storage) 758, it should be understood that any of the code blocks may be replaced with hardwired circuits incorporated into, for example, an application specific integrated circuit (ASIC).In an example, the instructions 782 provided via the memory 754, the storage 758, or the processor 752 may be embodied as a non-transitory (non-transitory) machine readable medium 760 comprising code to direct the processor 752 to perform electronic operations in the compute node 750. Processor 752 may access non-transitory machine readable medium 760 via connection 756. Non-transitory machine readable medium 760 may be embodied by, for example, devices described for storage 758, or may include specific storage units such as optical disks, flash drives, or any number of other hardware devices. The non-transitory machine readable medium 760 may include instructions to direct the processor 752 to execute a specific sequence or flow of actions, for example as described in relation to the flowchart(s) and block diagram(s) of the operations and functionality presented above. As used herein, the terms "machine-readable medium" and "computer-readable medium" are interchangeable.Also in a specific example, the instructions 782 on the processor 752 (separately or in combination with the instructions 782 of the machine readable medium 760) may configure execution or operation of a trusted execution environment (TEE) 790. In one example, the TEE 790 operates as a protected area accessible by the processor 752 for secure execution of instructions and secure access to data. Various implementations of the TEE 790 and associated secure area in the processor 752 or the memory 754 may be provided, for example, through the use of Intel® software guard extensions (SGX), or ARM® TrustZone® hardware security extensions, Intel® management engine (ME), or Intel® converged security management engine (CSME). Other aspects of security hardening, hardware roots of trust, and trusted or protected operations may be implemented by the TEE 790 and the processor 752 in the device 750.In further examples, a machine-readable medium also includes any tangible medium that is capable of storing, encoding, or carrying instructions for execution by a machine and that cause the machine to perform any one or more of the methodologies of the present disclosure, or that is capable of storing, encoding, or carrying data structures used by or associated with such instructions. A "machine readable medium" may thus include, but is not limited to, solid-state memories (solid-state memories) and optical and magnetic media. Specific examples of machine-readable media may include non-volatile memory including, but not limited to, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructions executed by a machine-readable medium may further be transmitted or received over a communication network using a transmission medium via a network interface device using any of a number of transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)).A machine readable medium may be provided by a storage device or other device capable of hosting data in a non-transitory format. In one example, the information stored or otherwise provided on a machine-readable medium may represent instructions, such as the instructions themselves or a format from which the instructions may be derived. This format from which the instructions may be derived may include source code, encrypted instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., divided into multiple packages), or the like. The information representing the instructions on the machine readable medium may be processed by processing circuitry to the instructions to implement any of the operations discussed herein. Deriving the instructions from the information (e.g., processing by the processing circuitry) may include, for example: compiling (e.g., from source code, object code, etc.), interpreting, loading, organizing (e.g., dynamically or statically linking), encoding, decoding, encrypting, decrypting, packaging, unpacking, or otherwise manipulating the information into the instructions.In an example, the derivation of the instructions may include arranging, compiling, or interpreting the information (e.g., by the processing circuitry) to produce the instructions from an intermediate or pre-processed format provided by the machine-readable medium. The information, if provided in multiple parts, may be combined, unpackaged, and modified to generate the instructions. The information may be, for example, in multiple compressed source code packages (or object code or binary executable code, etc.) on one or more remote servers. The source code packages may be encrypted when transmitted over a network and, if necessary, decrypted, decompressed, arranged (e.g., linked) and compiled or interpreted on a local machine (e.g., into a library, stand-alone executable, etc.) and executed by the local machine.It should be understood that the functional units or capabilities described in this specification may have been referred to or identified as components or modules to more particularly emphasize their implementation independence. Such components may be implemented by any number of software or hardware forms. A component or module may be implemented, for example, as a hardware circuit including custom very large scale integration (VLSI) circuits or gate arrays, commercially available semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for example, comprise one or more physical or logical blocks of computer instructions, which may, for example, be organized as an object, procedure, or function. However, the executables of an identified component or module need not be physically located at one location, but may comprise scheduled instructions stored at different locations that, when logically interconnected (e.g., comprising via a wire, via a network, using one or more platforms, wirelessly, via a software component, or the like), comprise the component or module and fulfil the purpose indicated for the component or module.A component or module of executable code may be a single instruction or multiple instructions, and may even be distributed across multiple different code segments, different programs, and multiple storage devices or processing systems. In particular, some aspects of the described process (such as code rewriting and code analysis) may take place on a different processing system (e.g., on a computer in a data center) than on the one on which the code is deployed (e.g., on a computer embedded in a sensor or robot). Similarly, operational data may be identified and illustrated herein within components or modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set or distributed across different locations, including across different storage devices, and may be at least partially only present as electronic signals in a system or network. The components or modules may be passive or active, including agents operative to perform the desired functions.Additional examples of the presently described embodiments of methods, systems, and devices include the following non-limiting implementations. Each of the following non-limiting examples may stand on its own, or may be combined in any permutation or combination with one or more of the other examples provided below or throughout the present disclosure.Each of these non-limiting examples may stand on its own, or may be combined with one or more of the other examples in various permutations or combinations.Example 1 is at least one machine readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to: identify a current context of a robotic device, the current context comprising the identification of at least one object present in a field of view; determine from the current context a set of actions executable by the robotic device corresponding to the at least one object, the set of actions comprising one or more affordances generated from a basic capabilities library for the robotic device; automatically select an action from the set of actions based on an acyclic graph describing action paths; and output control signals that cause the robotic device to perform the action for interacting with the at least one object.In Example 2, the subject matter of Example 1 includes, wherein the basic capabilities library comprises one or more dynamic motion actions comprising at least one of grasping an object, moving an object, or releasing an object.In Example 3, the subject matter of Examples 1-2 includes, wherein the current context includes identifying all objects that are in a field of view, a trajectory of the robotic device, and a task to be accomplished.In Example 4, the subject matter of Examples 1-3 includes, wherein the operations further include operations to receive a user confirmation of the action prior to outputting the control signals.In Example 5, the subject matter of Examples 1-4 includes, wherein the set of actions is generated by automatically extracting tasks from videos captured by the robotic device.In Example 6, the subject matter of Examples 1-5 includes, wherein the robotic device is controlled using a gesture via an augmented reality interface, and wherein the current context includes identifying the gesture.In Example 7, the subject matter of Examples 1-6 includes, wherein the operations to automatically select the action from the set of actions include operations to determine that two or more actions of the acyclic graph are selectable based on the current context, and to select the action based on a probability for each of the two or more actions.In Example 8, the subject matter of Examples 1-7 includes, wherein the action is a conditional action based on an action previously performed by the robotic device.Example 9 is at least one machine readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to: generate a basic capability library of primitives executable by a robotic device; automatically extract a set of affordances for at least one object from video data of the at least one object being manipulated; identify a task to be accomplished by the robotic device comprising the at least one object involved in the task; generate an acyclic affordance graph for the task based on the set of affordances for the at least one object; and output the acyclic affordance graph to generate a proposed action for the robotic device to accomplish the task.In Example 10, the subject matter of Example 9 includes, wherein the set of affordances is specific to a position or an orientation of the at least one object.In Example 11, the subject matter of Examples 9-10 includes, wherein the acyclic affordance graph includes at least one action available only after at least one other action is completed.In Example 12, the subject matter of Examples 9-11 includes, wherein the acyclic affordance graph comprises weights assigned to respective affordances of the acyclic affordance graph.Example 13 is an apparatus (apparatus) comprising: means for identifying a current context of a robotic device, the current context comprising identifying at least one object present in a field of view; means for determining, using processing circuitry, a set of actions executable by the robotic device corresponding to the at least one object from the current context, the set of actions comprising one or more prompts generated from a basic capabilities library for the robotic device; means for automatically selecting an action from the set of actions based on an acyclic graph describing action paths using the processing circuitry; and means for outputting control signals that cause the robotic device to perform the action for interacting with the at least one object.In Example 14, the subject matter of Example 13 includes, wherein the basic capabilities library comprises one or more dynamic motion actions associated with at least one of grasping the at least one object, moving the at least one object, or releasing the at least one object.In Example 15, the subject matter of Examples 13-14 includes, wherein the current context includes information corresponding to an identification of all objects that are in the field of view, a trajectory of the robotic device, and a task to be accomplished.In Example 16, the subject matter of Examples 13-15 includes, means for receiving a user confirmation of the action prior to outputting the control signals.In Example 17, the subject matter of Examples 13-16 includes, wherein the set of actions is generated by automatically extracting tasks from video or image data captured by the robotic device.In Example 18, the subject matter of Examples 13-17 includes, wherein the robotic device is controlled using a gesture via an augmented reality interface, and wherein the current context includes identifying the gesture.In Example 19, the subject matter of Examples 13-18 includes, wherein automatically selecting the action from the set of actions includes determining that two or more actions of the acyclic graph are selectable based on the current context, and selecting the action based on a probability for each of the two or more actions.In Example 20, the subject matter of Examples 13-19 includes, wherein the action is a conditional action based on an action previously performed by the robotic device.Example 21 is at least one machine readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-20.Example 22 is an apparatus comprising means to implement any of Examples 1-20.Example 23 is a system to implement any of Examples 1-20.Example 24 is a method to implement any of Examples 1-20.Although these implementations have been described with reference to specific example aspects, it will be apparent that various modifications and changes can be made to these aspects without departing from the broader scope of the present disclosure. Many of the arrangements and processes described herein may be used in combination or in parallel implementations to achieve greater bandwidth / throughput and to support the selection of edge services that may be provided to the served edge systems. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings, which form a part hereof, are by way of illustration and not limitation, specific aspects in which the subject matter may be practiced. The aspects depicted herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This detailed description is therefore not to be taken in a limiting sense, and the scope of various aspects is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.Such aspects of the inventive subject matter may be referred to herein, individually and / or together, for convenience only, and without the intention of deliberately limiting the scope of this application to any single aspect or inventive concept, in fact more than one should be disclosed. Although specific aspects have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be employed for the specific aspects shown. This disclosure is intended to cover any and all adaptations or variations of various aspects. Combinations of the above aspects and other aspects not expressly described herein will become apparent to those skilled in the art upon review of the above description.Example methods described herein may be at least partially machine- or computer-implemented. Some examples may include a computer readable medium or machine readable medium encoded with instructions operable to configure an electronic device to perform methods described in the preceding examples. An implementation of such methods may include code such as microcode, assembly language code, high-level language code, or the like. Such code may include computer readable instructions for carrying out various methods. The code can form portions of computer program products. In an example, the code may be further tangibly stored on one or more transitory, non-transitory (non-transitory) or non-transitory (non-volatile), tangible, computer readable media, e.g., during execution or at other times. Examples of these tangible computer readable media may include, but are not limited to, hard disks, removable magnetic disks, removable optical disks (e.g., compact disks (CDs), memory cards or pins, random access memories (RAMs), read only memories (ROMs), and the like.

Claims

At least one machine readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to: identify a current context of a robotic device, the current context comprising identifying at least one object present in a field of view; determine from the current context a set of actions executable by the robotic device corresponding to the at least one object, the set of actions comprising one or more affordances generated from a basic capabilities library for the robotic device; automatically select an action from the set of actions based on an acyclic graph describing action paths; and output control signals that cause the robotic device to perform the action for interacting with the at least one object.The at least one machine readable medium of claim 1, wherein the basic capabilities library comprises one or more dynamic motion actions comprising at least one of grasping an object, moving an object, or releasing an object.The at least one machine readable medium of any of claims 1-2, wherein the current context comprises identifying all objects that are in a field of view, a trajectory of the robotic device, and a task to be accomplished.The at least one machine readable medium of any of claims 1-3, wherein the operations further comprise operations to receive a user confirmation of the action prior to outputting the control signals.The at least one machine readable medium of any of claims 1-4, wherein the set of actions is generated by automatically extracting tasks from videos captured by the robotic device.The at least one machine readable medium of any of claims 1-5, wherein the robotic device is controlled using a gesture via an augmented reality interface, and wherein the current context comprises identifying the gesture.The at least one machine readable medium of any of claims 1-6, wherein the operations for automatically selecting the action from the set of actions comprise operations for determining that two or more actions of the acyclic graph are selectable based on the current context, and for selecting the action based on a probability for each of the two or more actions.The at least one machine readable medium of any of claims 1-7, wherein the action is a conditional action based on an action previously performed by the robotic device.At least one machine readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to: generate a basic capability library of primitives executable by a robotic device; automatically extract a set of affordances for at least one object from video data of the at least one object being manipulated; identify a task to be accomplished by the robotic device comprising the at least one object involved in the task; generate an acyclic affordance graph for the task based on the set of affordances for the at least one object; and output the acyclic affordance graph to generate a proposed action for the robotic device to accomplish the task.The at least one machine readable medium of claim 9, wherein the set of affordances is specific to a position or orientation of the at least one object.The at least one machine readable medium of claim 9 or 10, wherein the acyclic affordance graph comprises at least one action available only after at least one other action has been taken.The at least one machine readable medium of any of claims 9-11, wherein the acyclic affordance graph comprises weights assigned to respective affordances of the acyclic affordance graph.An apparatus, comprising: means for identifying a current context of a robotic device, the current context comprising identifying at least one object present in a field of view; means for determining, using processing circuitry, a set of actions executable by the robotic device corresponding to the at least one object from the current context, the set of actions comprising one or more affordances generated from a basic capability library for the robotic device; means for automatically selecting an action from the set of actions based on an acyclic graph describing action paths using the processing circuitry; and means for outputting control signals that cause the robotic device to perform the action for interacting with the at least one object.The apparatus of claim 13, wherein the basic capabilities library comprises one or more dynamic motion actions associated with at least one of grasping the at least one object, moving the at least one object, or releasing the at least one object.The apparatus of any of claims 13-14, wherein the current context comprises information corresponding to an identification of all objects that are in the field of view, a trajectory of the robotic device and a task to be accomplished.The apparatus of any of claims 13-15 further comprising means for receiving a user confirmation of the action prior to outputting the control signals.The apparatus of any of claims 13-16, wherein the set of actions is generated by automatically extracting tasks from video or image data captured by the robotic device.The apparatus of any of claims 13-17, wherein the robotic device is controlled using a gesture via an augmented reality interface, and wherein the current context comprises identifying the gesture.The apparatus of any of claims 13-18, wherein automatically selecting the action from the set of actions comprises determining that two or more actions of the acyclic graph are selectable based on the current context, and selecting the action based on a probability for each of the two or more actions.The apparatus of any of claims 13-19, wherein the action is a conditional action based on an action previously performed by the robotic device.

Images