Service Robot Task Planning for Flexible Scenario Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Service robots face challenges in adapting to changing scenarios and environments due to high interdependence between scenario implementing units and functional units, limiting their application range and flexibility.
Innovation Solution
A software architecture that includes a task planner, behavior manager, and action arbiter, allowing for easy scenario changes by providing an editing function, determining appropriate tasks, and performing corresponding actions through interaction among these components, along with a controller that uses sensor information to control the robot.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the scenario implementing unit and functional unit are deeply interdependent, then the robot operates reliably according to predefined scenarios, but the application range and flexibility are significantly limited
Solution Approach 1:
The patent segments the robot control system into distinct modules: scenario implementing unit, functional unit, behavior manager, and action arbiter. Each module has specific responsibilities and communicates through standardized interfaces, allowing independent modification of scenarios without affecting core functional units. This modular architecture enables both reliable operation through structured control and adaptability through easy scenario replacement.
Solution Approach 2:
The patent creates a universal scenario implementing unit that can execute multiple different scenarios through standardized behavior and action definitions. The behavior manager and action arbiter serve as universal controllers that work with any scenario type, enabling the same hardware platform to adapt to various applications (home service, welfare, education, medical care, defense) without redesigning core components.
2Stability of the object's composition
If the software architecture has high interdependence between scenario implementing unit and functional unit, then the robot maintains stable operation, but scenario changes become difficult
Solution Approach 1:
The software is segmented into independent layers: scenario definition layer, behavior management layer, and action execution layer. Scenarios are defined as separate configuration files or code modules that can be modified without touching the stable core architecture. The behavior manager handles scenario interpretation while the action arbiter manages execution, creating stable interfaces that isolate changes to specific modules only.
Solution Approach 2:
The behavior manager acts as an intermediary between scenario definitions and functional units, translating high-level scenario descriptions into actionable commands. The action arbiter serves as another intermediary layer that coordinates actions across different functional units. These mediator layers buffer changes, allowing scenario modifications without directly impacting the stability of underlying functional units.
3Adaptability or versatility
If scenarios are frequently changed to expand application range, then the robot becomes more versatile, but operational stability may be compromised
Solution Approach 1:
The system dynamically loads and unloads scenario configurations based on operational needs. The behavior manager can switch between different scenario implementations without restarting the robot, and the action arbiter dynamically adjusts action priorities and parameters. This dynamic capability allows frequent scenario changes while maintaining operational stability through continuous monitoring and controlled transitions.
Solution Approach 2:
The system incorporates feedback mechanisms where the action arbiter monitors execution results and reports back to the behavior manager, which can adjust scenario parameters or trigger error handling protocols. This feedback loop ensures that even when scenarios are frequently changed, operational stability is maintained through real-time validation and corrective actions.
Data Source
AI summary
An embodiment device for controlling a service robot includes a communication device configured to communicate with the service robot and a controller configured to detect a present situation of the service robot by using various pieces of sensor information acquired from the service robot, determine a task appropriate to the present situation of the service robot, wherein the task includes one or more behaviors, and control the service robot based on an action set for each of the one or more behaviors of the task.