MOTOMAN NEXT looks to redefine how traditional robotics processes complex Tasks by compartmentalizing tasks and jobs into individual Skills. Rather than writing one massive, linear program to handle every aspect of a robot's behavior, MOTOMAN NEXT utilizes a modular architecture made up of two core components: Services and Skills.
Understanding the relationship between these two is the key to developing intelligent robotic applications.
¶ What is a Service?
A Service is a permanent, background process running on the Autonomous Control Unit (ACU) that provides specific, high-level functional capabilities. You can think of services as the "utilities" of the robot. These services are always available and perform the heavy lifting for complex technical tasks.
¶ Standard Services
YASKAWA provides a suite of pre-installed Standard Services that expose control over robotic operations and external sensor feedback processing. Interaction with these services can take multiple forms, from web-interfaces, gRPC API calls, or direct INFORM activation. These services provide the core foundation in which autonomous application programming can begin. Whether through direct control in INFORM jobs or custom developed User Applications, these services empower users to begin processing a more vast and complex world of automation.
¶ User Applications as Services
While YASKAWA provides the core infrastructure, developers can also create their own User Applications that function as additional services. By packaging your custom logic into a Docker container, your application can run alongside other services. These custom applications can then contribute to the suite of services by exposing their own unique gRPC or INFORM endpoints, allowing other parts of the system to benefit from your specialized code.
¶ What is a Skill?
When describing autonomous robotic actions you may often hear the word Skills. This word helps describe the fundamental actions or building blocks that make up a larger Task that a robot may perform. These Skills are derived from the capabilities of the component services that make up the functional aspects of the ACU. A skill can be provided by a standalone ACU service or by coordinating one or more other services to perform some meaningful action.
¶ Skills vs. Tasks
Another commonly used phrasing is that of "Skills and Tasks". These words help us describe the actions a robot takes in more simple language. This allows us to better understand the individual component structure that forms one or more autonomous functions of the robot.
To understand the relationship between these terms better, consider the structure of a sentence:
-
Tasks are the complete sentence or goal.
-
Skills are the verbs in that sentence.
Example:
"Pick up the yellow bracket and place it in the bin."
A Task is the overall objective composed of one or more skills. A Skill can be the autonomous "action" that handles a specific segment of that task independently.
¶ Integration of Skills
Developing a skill on the ACU is only the first half of the process; the second half involves integrating that skill into the broader robotic workflow. Because the MOTOMAN NEXT is designed as an open and flexible platform, there are multiple ways to trigger and manage these skills depending on the requirements of your specific application.
¶ INFORM Instructions
For most industrial applications, the primary method of integration is through INFORM instructions. This allows traditional robot operators to call complex autonomous skills directly from a standard robot job on the Tablet Pendant. By mapping specific Digital Outputs (I/O) or robot variables to skill triggers, an INFORM job can activate dedicated ACU skills. This creates a seamless hand-off between deterministic INFORM actions and any potential autonomous motion or perception actions.
Example Skill Job:
/JOB
//NAME MY_ACU_SKILL
//POS
///NPOS 0,0,0,0,0,0
//INST
///DATE 2026/01/01 12:00
///CREATE 2026/01/01 12:00
///COMM
///ATTR SC,RW,RJ,UI
////FRAME BASE
///GROUP1 RB1
///LVARS 0,0,0,0,0,0,0,0
NOP
' Ensure completion flag is reset
SET B099 0
' Set to activate ACU Skill
SET B098 1
' Wait for ACU Skill to complete
WAIT B099=1
' Reset the flags
SET B099 0
SET B099 0
END
Note:
B-Variables 099 and 098 are chosen as simple examples. Any Digital I/O or robot variables can be utilized for this purpose.
¶ gRPC APIs
For more dynamic or software-heavy integrations, skills can be exposed and activated via gRPC APIs . Since the ACU services and user applications communicate over a high-speed internal network, a "Client" application (which could be another service or an external PC) can send a remote procedure call to start or stop a specific skill. This method provides the highest level of data granularity. Allowing the caller to pass complex parameters, such as sensor data or positional offsets, directly into the skill at the moment of activation.
¶ Other Forms of Activation
Beyond standard robot programming and direct API calls, the ACU's containerized solution allows for highly customized activation methods. Some common examples of this include:
-
Custom Logic:
A skill can be "self-triggering" based on internal logic. For example, a monitoring skill might stay active in the background and only trigger a corrective motion skill if the Machine Vision Service detects a specific anomaly on the production line. -
ROS2 Integration:
For developers coming from the research or advanced robotics sectors, the ACU can host ROS2 (Robot Operating System 2) nodes within its Docker containers. In this setup, skills can be triggered via ROS2 topics, services, or actions, allowing the YNX1000 to participate in a wider ROS2-managed ecosystem.
| ⬅️ Previous |
|---|
| What is gRPC? |