System, method, program

Abstract

Efficiently generate high-performance robot hardware configurations based on user requirements. [Solution] The system for generating robots includes: a requirements receiving unit that receives requests for robots from users in a format including natural language; an interpretation unit that defines physical or engineering constraints and an objective function for evaluating the robot's performance based on the requests; a design generation unit that generates proposed hardware configurations for the robot based on the constraints; a simulation execution unit that performs physical calculations in a virtual space using the proposed hardware configurations and evaluates the robot's performance based on the objective function; an optimization execution unit that iteratively performs processing to optimize the proposed hardware configurations using the design generation unit and the simulation execution unit so as to improve the degree of achievement of the objective function based on the evaluation results from the simulation execution unit; and a result output unit that outputs optimized hardware configuration data obtained through the iterative processing by the optimization execution unit.

Description

Technical Field

[0001] The present disclosure relates to a system, a method, and a program.

Background Art

[0002] In recent years, the utilization of robots (including unmanned aerial vehicles such as drones) has been rapidly advancing in diverse fields such as the manufacturing industry, logistics, construction, disaster response, defense, and space exploration. To meet these demands, there is a need for technologies that enable rapid and efficient development of robots specialized for specific tasks and operational environments.

[0003] In the robot development process, there is a technology for verifying the motion and performance of a robot using physical simulation in a virtual space (digital twin environment). This makes it possible to evaluate the validity of a design before prototyping an actual machine.

[0004] Furthermore, attempts have been made to automate or streamline the robot design itself. For example, in CAD (Computer Aided Design) tools, there is generative design technology that optimizes the shape of components under specified constraints. In addition, a technology for automatically configuring a robot by combining pre-prepared modules (components) according to a task (see, for example, Japanese Patent Publication No. 2024-518578) and a self-development technology for automatically generating and mounting missing components when an existing robot cannot perform a task (see, for example, Japanese Patent Publication No. 2025-529956) have also been proposed.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Patent Document 2

Summary of Invention

Problems to be Solved by the Invention

[0006] However, challenges still remained in the conventional robot development process.

[0007] The design process and the simulation-based verification process were disconnected, resulting in low development efficiency. If a hardware configuration proposed by a designer was evaluated through simulation and found not to meet the required dynamic performance (e.g., flight stability, energy efficiency, durability), the designer had to manually modify the design and run the simulation again. This iterative process required a significant amount of time and effort, contributing to prolonged development periods and increased costs.

[0008] Therefore, in light of the challenges of conventional technologies described above, there is a need for a system that can quickly and efficiently generate robot hardware configurations optimized for specific tasks. [Means for solving the problem]

[0009] According to one embodiment shown in this disclosure, a system for generating a robot is provided. The system comprises: a requirements receiving unit that receives requests for a robot from a user in a form including natural language; an interpretation unit that defines physical or engineering constraints and an objective function for evaluating the robot's performance based on the requests; a design generation unit that generates a proposed hardware configuration for the robot based on the constraints; a simulation execution unit that performs physical calculations in a virtual space using the proposed hardware configuration and evaluates the robot's performance based on the objective function; an optimization execution unit that iteratively performs processing to optimize the proposed hardware configuration using the design generation unit and the simulation execution unit so as to improve the degree of achievement of the objective function based on the evaluation results from the simulation execution unit; and a result output unit that outputs optimized hardware configuration data obtained through the iterative processing by the optimization execution unit. [Effects of the Invention]

[0010] According to this disclosure, constraints and an objective function are defined based on a request received from a user, and a hardware configuration proposal is generated. Then, physical calculations are performed in a virtual space using the generated hardware configuration proposal to evaluate its performance, and based on the evaluation results, processes are iteratively executed to optimize the hardware configuration proposal so that the degree to which the objective function is achieved is improved.

[0011] This integrates the design and physical performance verification processes into an automated feedback loop, eliminating the need for iterative manual correction work that designers traditionally performed. This dramatically shortens robot development time and reduces costs. [Brief explanation of the drawing]

[0012] [Figure 1] Figure 1 shows the configuration of System 1. [Figure 2] Figure 2 shows the configuration of server 20. [Figure 3] Figure 3 shows the configuration of terminal 10. [Figure 4] Figure 4 shows a conceptual diagram of the Co-Design loop, illustrating the details of the simultaneous optimization loop for hardware configuration and control policy, and a conceptual diagram showing its application to a robotic system. [Figure 5] Figure 5 shows the data structure of the requirements and constraints database 211. [Figure 6] Figure 6 shows the data structure of the component database 212. [Figure 7] Figure 7 shows the data structure of the robot configuration database 213. [Figure 8] Figure 8 shows the overall processing flow of the robot generation process. [Figure 9] Figure 9 shows a detailed diagram of the simultaneous optimization process flow. [Figure 10] Figure 10 shows the workflow for accepting requirements definitions interactively. [Figure 11]Figure 11 is a diagram showing a flow of processing for group control optimization. [Figure 12] Figure 12 is a screen example of a requirement input and interaction screen. [Figure 13] Figure 13 is a screen example of a screen displaying the status of simulation and optimization. [Figure 14] Figure 14 is a screen example of a design result confirmation and output screen. [Mode for Carrying Out the Invention]

[0013] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same components are denoted by the same reference numerals. Their names and functions are also identical. Therefore, detailed descriptions thereof will not be repeated.

[0014] <Overview of Embodiment> First, an outline of the information processing system according to the present embodiment will be described.

[0015] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0016] In conventional robot development processes, a sequential approach is common, in which a designer designs a hardware configuration and then verifies its performance in a simulation environment. In this approach, if the simulation results reveal that the required physical and dynamic performance is not satisfied, it is necessary to return to the design process to perform manual corrections, which requires significant time and cost. In particular, there has been a demand for an integrated mechanism that automatically optimizes the design itself while ensuring physical performance.

[0017] It was difficult to automatically design an entire robot system from abstract requirements. Conventional generative design was limited to optimizing the shape of individual components, and the aforementioned prior art focused on combining existing modules or making partial modifications to existing robots. Therefore, it was difficult to automatically generate the optimal hardware configuration from scratch based on abstract requirements in natural language, such as "we want a robot that can perform a specific task in a specific environment."

[0018] Furthermore, designing robots requires advanced expertise, making it difficult for non-robotics experts to quickly obtain task-optimized robot designs using an intuitive interface.

[0019] To solve this problem, the robot generation system according to this embodiment constructs an automated closed-loop pipeline that integrates the processes of robot design generation, verification by physical simulation, and optimization.

[0020] Specifically, this system first receives abstract requests from users, including those in natural language (for example, "a drone capable of carrying a specific weight in a specific environment"), and converts them into physical and engineering "constraints" necessary for robot development and an "objective function" that serves as a criterion for performance evaluation. Next, it uses AI (artificial intelligence) technology (for example, generative models such as diffusion models and graph neural networks (GNNs)) to automatically generate proposed hardware configurations for robots that satisfy these conditions.

[0021] The generated configuration is then deployed to a digital twin environment (virtual space), and its performance is evaluated by running high-fidelity physical simulations. The core of this system lies in its ability to automatically feed these evaluation results back into the design generation process, iteratively updating and optimizing the hardware configuration to improve the achievement of the objective function. Furthermore, in an advanced form, it is possible to simultaneously optimize (co-design) not only the hardware configuration but also the control policies (software) that govern its operation.

[0022] This automated feedback loop ensures that the robot design is physically feasible and optimized for the given task. This dramatically shortens development time compared to traditional development processes, and enables users without robotics expertise to quickly develop and deploy high-performance custom robots. In other words, it allows for the deriving of a truly task-optimized hardware configuration with dynamic performance guaranteed through physical simulation. Furthermore, the ability to input requirements in natural language makes it easy for users without advanced robotics expertise to develop custom robots.

[0023] The specific configuration and processing of this system will be explained below using diagrams.

[0024] <1.1 System Configuration Diagram> Figure 1 shows the configuration of System 1.

[0025] System 1, shown in Figure 1, includes a server 20, user terminals 10 and 10A, and a server 95 for artificial intelligence (large-scale language model) services (hereinafter sometimes referred to as "server 95 for large-scale language model services"). These devices communicate with each other via a network 80.

[0026] Server 20 provides a service for generating robots.

[0027] Terminal 10 is a terminal used by a user of the services provided by Server 20. In the illustrated example, terminals 10, terminal 10A, etc., are shown as terminals used by users of the services provided by Server 20, but each user operates their own terminal.

[0028] Server 95 of the Large-Scale Language Model Service is a server that executes language processing tasks using language models built through learning processes that include artificial intelligence (AI). An LLM (Large Language Model) is a model that has been pre-trained on large amounts of data (such as text data), for example, a large amount of web content on the internet, or a large amount of data stored in a designated database, and can perform various language processing tasks by being given a task.

[0029] The server 95 of the large-scale language model service accepts prompt input in the form of text, images, audio, etc., and generates responses to those prompts. Examples of LLMs include GPT (e.g., GPT5) developed by OpenAI and Gemini developed by Google.

[0030] The configuration of each device is described below.

[0031] The server 20 includes a communication interface 22, an input / output interface 23, memory 25, storage 26, and a processor 29.

[0032] Communication IF22 is an interface for inputting and outputting signals so that the server 20 can communicate with external devices.

[0033] Input / Output IF23 functions as an interface between an input device for receiving user input operations and an output device for presenting information to the user.

[0034] Memory 25 is for temporarily storing programs and data processed by programs, etc., and is a volatile memory such as DRAM (Dynamic Random Access Memory).

[0035] Storage 26 is for storing data, and can be, for example, flash memory or an HDD (Hard Disk Drive).

[0036] The processor 29 is hardware for executing the instruction set described in the program, and consists of an arithmetic unit, registers, peripheral circuits, etc.

[0037] Terminal 10 can be implemented, for example, as follows: • Handheld mobile devices such as smartphones and tablets • Stationary PCs (Personal Computers), Laptop PCs • Wearable devices worn by the user (watch-type, glasses-type, etc.) Terminal 10 includes a communication interface (IF) 12, an input device 13, an output device 14, memory 15, storage 16, and a processor 19.

[0038] The communication interface 12 is an interface for inputting and outputting signals so that terminal 10 can communicate with an external device.

[0039] The input device 13 is a device for receiving input operations from the user (for example, a touch panel, touchpad, pointing device such as a mouse, keyboard, etc.).

[0040] The output device 14 is a device (such as a display or speaker) for presenting information to the user.

[0041] Memory 15 is for temporarily storing programs and data processed by programs, etc., and is a volatile memory such as DRAM (Dynamic Random Access Memory).

[0042] Storage 16 is for storing data, and can be, for example, flash memory or an HDD (Hard Disk Drive).

[0043] The processor 19 is hardware for executing the instruction set described in the program, and consists of an arithmetic unit, registers, peripheral circuits, etc.

[0044] <1.2 Functional Configuration of Server 20> Figure 2 shows the configuration of server 20. As shown in Figure 2, server 20 functions as a communication unit 201, a storage unit 202, and a control unit 203.

[0045] The communications unit 201 performs processing to enable the server 20 to communicate with external devices.

[0046] The memory unit 202 stores various databases, such as the requirements and constraints database 211, the component database 212, and the robot configuration database 213.

[0047] The requirements and constraints database 211 interprets natural language input from the user and stores data structured as constraints (physical constraints, environmental conditions, costs, etc.) and objective functions (performance metrics, weights, etc.) defined within the system.

[0048] The component database 212 is a database that manages the specifications of available existing components (parts), including component ID, type, physical properties, performance, cost, and links to 3D model data.

[0049] The robot configuration database 213 stores data for the robot that is generated and optimized, showing how hardware configuration data (part configuration, connection relationships, geometry) and control policy data (trained models, parameters) are related.

[0050] The control unit 203 is realized when the processor 29 reads a program stored in the memory unit 202 and executes instructions contained in the program. By operating according to the program, the control unit 203 performs the functions shown as various modules as illustrated.

[0051] The communication control unit 2033 is a module that controls data communication between user terminals (client PCs, etc.) and external systems, and is responsible for receiving API requests, sending responses, and authentication and management related to system usage.

[0052] The Request Reception / Dialogue Unit 2034 is a module that receives requests related to the robot (natural language text, parameter specifications, reference materials, etc.) via a user interface, has an interactive interface function, and manages a dialogue process to resolve ambiguity in requests and gradually concretize and quantify them.

[0053] The constraint interpretation unit 2035 is a module that analyzes the requirements received by the requirements reception unit, defines and structures the physical and engineering "constraints" (e.g., size, weight, environmental resistance, cost) necessary for robot design, and the "objective functions" (e.g., speed, efficiency, mission achievement) that serve as criteria for performance evaluation, while also interpreting the intent of the requirements using natural language processing technology (large-scale language models, etc.).

[0054] For example, if the user's request is vague, such as "a drone that can fly stably in strong winds," the constraint interpretation unit 2035 refers to the engineering knowledge and past design examples held by the knowledge base / model management unit 2040 to estimate a specific wind speed range that "strong winds" refer to (e.g., 15 m / s to 25 m / s) and a candidate objective function for evaluating "stability" (e.g., suppression of attitude angle fluctuations under specific disturbances). Then, through the interactive interface of the request reception / dialogue unit 2034, it presents the user with a specific question such as "Is it alright to assume a maximum wind speed of 20 m / s?" (see Figure 10), and by obtaining an answer, the constraint conditions and objective function are gradually made more concrete and quantifiable.

[0055] The design and control generation unit 2036 generates a proposed robot hardware configuration using a generated model, based on the constraints defined by the constraint interpretation unit 2035. For example, the design and control generation unit 2036 selects the necessary components (e.g., motors, batteries) from the component database 212 to meet the required performance (e.g., payload, range) and generates a topology (structure) and shape that arranges them within the physical constraints (e.g., maximum size). In this case, the robot hardware configuration can be represented by various data structures. For example, it may be represented as a "graph structure" that shows components (nodes) and their connection relationships (edges). In this case, a graph neural network (GNN) is used to generate the optimal graph structure (topology) that satisfies the constraints and simultaneously optimize the parameters of the components corresponding to each node (e.g., link length, motor type).

[0056] Alternatively, the design and control generation unit 2036 may convert natural language requirements and constraints into vectors in latent space and generate 3D shape data of the entire robot and graph structures showing the connection relationships between parts from scratch using generative AI models such as a diffusion model or a variational autoencoder (VAE). The 3D shape data may be generated as, for example, a "set of voxels (3D pixels)", "point cloud data", or "neural implicit representation". In these generation processes, to ensure physical and engineering feasibility, the generation model itself may be equipped with a mechanism to incorporate knowledge of physical laws (e.g., use of a neural network based on physical information: PINNs), or to incorporate a simple physical feasibility check during the generation process (e.g., stress evaluation by structural analysis, calculation of the center of gravity).

[0057] The generative models referred to here can include a variety of known or future machine learning models, such as 3D-CNN-based models for generating robot structural topology, variational autoencoders (VAEs), generative adversarial networks (GANs), graph neural networks (GNNs) that output component configuration relationships as a graph structure, or diffusion models.

[0058] The simulation execution unit 2037 automatically deploys the hardware configuration proposals (and control policies) generated by the design and control generation unit 2036 into a virtual space (digital twin environment) and executes a high-fidelity physics simulation. This physics simulation calculates dynamic behavior (e.g., drone flight stability, robot arm trajectory) considering physical laws such as gravity, air resistance, friction, and collision, based on physical parameters such as the mass, moment of inertia, range of motion of joints, motor torque, and sensor characteristics of the generated hardware configuration proposal. This module evaluates the robot's dynamic behavior and task performance capabilities and calculates a performance score (e.g., task completion time, energy consumption) based on an objective function, and also includes a function for generating synthetic sensor data for recognition AI learning.

[0059] Based on the evaluation results (performance score) from the simulation execution unit 2037, the optimization execution unit 2038 uses an optimization algorithm to update the parameters and the generation model used by the design and control generation unit 2036 so that the value of the objective function improves (e.g., is maximized or minimized) in order to improve the degree of achievement of the objective function. The virtual space parameters referred to here include various physical and environmental parameters that affect the fidelity of the simulation, such as the friction coefficient of the floor surface, the moment of inertia of the members, air resistance, the response delay of the actuator, the noise model of the sensor (e.g., camera, LiDAR), and lighting conditions. As for the optimization algorithm, for example, if the design parameters are differentiable, the gradient method (e.g., stochastic gradient descent) can be applied. For example, if the simulation execution unit 2037 supports differentiable physical simulation, the optimization execution unit 2038 calculates the gradient of each design parameter (e.g., arm length, motor output, neural network weights of the control policy) with respect to the performance score (objective function) by automatic differentiation.

[0060] Differentiable physical simulations can include not only rigid-body simulations but also simulations that consider the effects of flexible materials and fluids (e.g., air resistance, lift) using methods such as the mass point method (MPM) or finite element method (FEM). Specifically, a physical simulation is first performed using the current parameters as a forward pass to calculate a performance score. Next, since the entire time evolution of the simulation is differentiable, the gradient (sensitivity) of each parameter to the performance score is efficiently calculated using a backward pass (backpropagation through time).

[0061] The design parameters referred to here include parameters that define the shape and topology. For example, if the robot's structure is represented by voxels, the material density of each voxel becomes a design parameter. Based on the calculated gradient information, the optimization execution unit 2038 identifies an update direction, such as "to improve energy efficiency, the density of the central part of the fuselage should be reduced (lightened)."

[0062] Then, based on the calculated gradient information, the design and control generation unit 2036 is fed back to update each design parameter directly in a direction that improves the performance score, using algorithms such as gradient descent.

[0063] Furthermore, when parameters are discrete or the search space is complex, Bayesian optimization, genetic algorithms (GA), particle swarm optimization (PSO), or reinforcement learning in conjunction with a simulation environment (e.g., PPO, SAC) can be used. Thus, the optimization execution unit 2038 is a module that controls the entire iterative process (optimization loop) of simultaneously optimizing hardware and software (co-design) by providing feedback to the design and control generation unit 2036 to instruct it to update the design proposal (and control policy), and executes optimization algorithms such as differentiable physical simulation and reinforcement learning.

[0064] The result output unit 2039 is a module that converts the final design results (optimized hardware configuration data, control policy) obtained through iterative processing by the optimization execution unit 2038 into usable formats (CAD data, software packages, manufacturing instruction data such as BOM, performance reports) and outputs them.

[0065] The Knowledge Base / Model Management Unit 2040 is a module (various databases) that manages and stores various data and AI models used throughout the entire system, and includes the following databases, etc.

[0066] • Component Database: Specifications, performance, cost, and 3D model data of available existing parts. • Environment Model Database: Digital twin data and physical properties of various environments used in simulations. • AI Model Repository: Pre-trained models such as design generative models and natural language processing models. The real-world feedback unit 2041 is a module that collects and analyzes data obtained from actual equipment operation, and updates (fine-tunes) the parameters of the simulation environment and the model of the design generation unit to reduce the gap between simulation and reality (Sim-to-Real Gap) and continuously improve generation accuracy.

[0067] <1.3 Configuration of Terminal 10> Figure 3 shows the configuration of terminal 10.

[0068] As shown in Figure 3, terminal 10 includes multiple antennas (antenna 111, antenna 112), communication units corresponding to each antenna (first communication unit 120, second communication unit 121), an input device 130 (including a touch-sensitive device 131), a display 132, an audio processing unit 140, a microphone 141, a speaker 142, a position information sensor 150, a camera 160, a motion sensor 170, a storage unit 180, and a control unit 190. Terminal 10 also has functions and configurations not specifically shown in Figure 3 (for example, a battery for maintaining power, a power supply circuit for controlling the supply of power from the battery to each circuit, etc.). As shown in Figure 3, each block included in terminal 10 is electrically connected by a bus or the like.

[0069] Antenna 111 radiates signals emitted by terminal 10 as radio waves. Antenna 111 also receives radio waves from space and provides the received signals to first communication unit 120.

[0070] Antenna 112 radiates signals emitted by terminal 10 as radio waves. Antenna 112 also receives radio waves from space and provides the received signals to the second communication unit 121.

[0071] The first communication unit 120 performs modulation and demodulation processing, etc., for the terminal 10 to transmit and receive signals via the antenna 111 in order to communicate with other wireless devices. The second communication unit 121 also performs modulation and demodulation processing, etc., for the terminal 10 to transmit and receive signals via the antenna 112 in order to communicate with other wireless devices. The first communication unit 120 and the second communication unit 121 are a communication module that includes a tuner, an RSSI (Received Signal Strength Indicator) calculation circuit, a CRC (Cyclic Redundancy Check) calculation circuit, a high-frequency circuit, etc. The first communication unit 120 and the second communication unit 121 perform modulation and demodulation, frequency conversion, etc., of the wireless signals transmitted and received by the terminal 10, and provide the received signal to the control unit 190.

[0072] The input device 130 has a mechanism for receiving user input operations. Specifically, the input device 130 is configured as a touchscreen and includes a touch-sensitive device 131. The touch-sensitive device 131 receives user input operations of the terminal 10. The touch-sensitive device 131 detects the user's contact position with the touch panel, for example, by using a capacitive touch panel. The touch-sensitive device 131 outputs a signal indicating the user's contact position detected by the touch panel to the control unit 190 as an input operation.

[0073] The display 132 displays data such as images, videos, and text in accordance with the control of the control unit 190. The display 132 is implemented by, for example, an LCD or an organic EL display.

[0074] The audio processing unit 140 modulates and demodulates the audio signal. The audio processing unit 140 modulates the signal received from the microphone 141 and provides the modulated signal to the control unit 190. The audio processing unit 140 also provides the audio signal to the speaker 142. The audio processing unit 140 is implemented, for example, by an audio processing processor. The microphone 141 receives an audio input and provides the audio signal corresponding to that audio input to the audio processing unit 140. The speaker 142 converts the audio signal received from the audio processing unit 140 into sound and outputs the sound to the outside of the terminal 10.

[0075] The location information sensor 150 is a sensor that detects the location of the terminal 10, and is, for example, a GPS (Global Positioning System) module. A GPS module is a receiving device used in a satellite positioning system. In a satellite positioning system, signals are received from at least three or four satellites, and the current location of the terminal 10, which is equipped with a GPS module, is detected based on the received signals.

[0076] Camera 160 is a device that receives light using a photodetector and outputs it as an image. Camera 160 is, for example, a depth camera that can detect the distance from camera 160 to the object being photographed.

[0077] The motion sensor 170 includes an acceleration sensor, an angular velocity sensor, etc., and detects the movement of the terminal 10.

[0078] The storage unit 180 is composed of, for example, flash memory and stores data and programs used by the terminal 10. The various types of information stored in the storage unit 180 will be described later.

[0079] The control unit 190 controls the operation of the terminal 10 by reading the program stored in the memory unit 180 and executing the instructions contained in the program. The control unit 190 is, for example, an application processor. By operating according to the program, the control unit 190 performs the functions of an operation reception unit 191, a transmission / reception unit 192, a data processing unit 193, a notification control unit 194, and a memory control unit 195.

[0080] The operation reception unit 191 processes input operations from the user to an input device such as a touch-sensitive device 131. Based on the coordinate information of the touch-sensitive device 131 where the user's finger or the like has made contact, the operation reception unit 191 determines the type of operation, such as whether the user's operation is a flick operation, a tap operation, or a drag (swipe) operation.

[0081] The transmitting / receiving unit 192 performs processing to enable the terminal 10 to send and receive data with an external device such as a server 20 in accordance with a communication protocol.

[0082] The data processing unit 193 performs calculations on the data received as input by the terminal 10 according to the program and outputs the calculation results to memory or other locations.

[0083] The notification control unit 194 performs the following processes: displaying the display image on the display 132, outputting sound to the speaker 142, and generating vibrations.

[0084] The memory control unit 195 controls the storage of data to the memory unit 180.

[0085] The various types of information stored by the memory unit 180 will now be explained. In a given situation, the memory unit 180 stores various types of information, such as user information 181.

[0086] User information 181 is information about a user who uses the services of server 20.

[0087] Figure 4 shows a conceptual diagram of the Co-Design loop, illustrating the details of the simultaneous optimization loop for hardware configuration and control policy, and a conceptual diagram showing its application to a swarm robot system.

[0088] Figure 4 shows a conceptual diagram of a Co-Design loop 300 according to one embodiment of the present invention. Unlike developing the physical configuration (hardware) of a robot and the software (control policy) that controls its operation separately, the system of this embodiment can handle both integrally and optimize them simultaneously.

[0089] The simultaneous optimization loop 300 is an iterative process mainly consisting of a design and control generation unit 310, a simulation execution unit 320, a performance evaluation unit 330 (shown as a performance evaluation step in the figure), and an optimization execution unit 340.

[0090] First, the design and control generation unit 310 generates proposed hardware configurations 312 for the robot (e.g., 3D model, component configuration, physical structure) and corresponding proposed control policies 314 (e.g., neural network weights, control algorithm parameters) based on the given constraints. These proposals are generated as initial designs in the first iteration and updated in subsequent iterations based on feedback from the optimization execution unit 340.

[0091] Next, the generated hardware configuration proposal 312 and control policy proposal 314 are deployed to the simulation execution unit 320. The simulation execution unit 320 has a digital twin environment (virtual space) capable of high-fidelity physics calculations, and simulates the robot's movements and task execution status within this environment.

[0092] The simulation results are analyzed in step 330 of the performance evaluation. Here, the performance of the current design is calculated as a quantitative score based on predefined objective functions (e.g., energy efficiency, travel speed, task completion rate).

[0093] The optimization execution unit 340 takes the calculated performance score as input and executes an optimization algorithm (e.g., reinforcement learning, evolutionary algorithm, gradient method) to improve the degree of achievement of the objective function (to maximize or minimize the score).

[0094] The optimization execution unit 340 calculates feedback information 342 (for example, gradient information when differentiable physical simulation is used, and parameter update values) for updating the hardware configuration and control policy, and returns it to the design and control generation unit 310.

[0095] Based on this feedback information 342, the design and control generation unit 310 generates a proposed next-generation hardware configuration 312 and a proposed control policy 314. By iteratively executing this series of processes (generation, simulation, evaluation, and feedback), the hardware and software are mutually optimized, and an overall optimized robot system for the given task is derived. For example, in drone airframe design, weight reduction (hardware) improves energy efficiency, but the reduced inertia of the airframe necessitates advanced attitude control (software) to maintain flight stability against disturbances, creating a trade-off. In the simultaneous optimization loop of this embodiment, the shape and mass distribution of the airframe and the parameters of the control policy are explored simultaneously, making it possible to derive an overall optimal solution that was difficult to achieve with conventional sequential development, such as "combining an unstable but high-performance hardware configuration with an advanced control policy that can handle it."

[0096] Figure 4 shows an example of the application of a swarm robot system 400 generated by the system of the present invention. The present invention can be applied not only to individual robots but also to the generation and optimization of swarms in which multiple robots operate in coordination.

[0097] In the example shown in Figure 4, a heterogeneous group of robots 410 is deployed in a specific mission area 420. The mission area 420 is envisioned as, for example, a large-scale disaster site or an environment where external positioning information (GPS signals) is unavailable or limited (GPS-denied environment).

[0098] The robot group 410, optimized by the system of the present invention with the overall mission achievement as the objective function, consists of multiple types of robots with different roles and functions. Specifically, it includes multiple work machines (Type A) 412 that perform primary tasks (e.g., observation, work, transport) and energy replenishment machines (Type B) 414 that provide support to extend the mission duration of the group as a whole. The design, composition ratio, and division of roles of these robots are also subject to optimization.

[0099] Furthermore, the control policy for the robot group 410 is optimized for advanced coordinated operation.

[0100] For example, the operation of the automatic return and replenishment 430 is shown. The work machine 412 monitors its own energy level and, if necessary, autonomously returns to the energy replenishment machine 414 to receive energy exchange or replenishment. The control policy for this sequence and the hardware configuration for the replenishment mechanism are optimized to maximize the operational efficiency of the entire group.

[0101] The operation of the cooperative self-localization / communication relay 440 is also demonstrated. When the mission area 420 is a GPS-denied environment, each robot communicates with each other and exchanges relative position information to cooperatively estimate its own position as a group and maintain navigation without relying on external information. It also relays communication between individuals to ensure the communication range of the entire group. The control policy that realizes these cooperative operations, as well as the configuration of the necessary sensors and communication modules, are also optimized by the system of the present invention.

[0102] <2 Data Structure> Figure 5 shows the data structure of the requirements and constraints database 211. The requirements and constraints database 211 includes the following items: "Requirement ID", "Date and Time Received", "Natural Language Input Text", "Interpretation Status", "Robot Type (Definition)", "Mission Overview (Definition)", "Physical Constraint: Maximum Size", "Physical Constraint: Maximum Weight", "Physical Constraint: Payload", "Environmental Condition: Operating Temperature Range", "Environmental Condition: Maximum Wind Speed", "Environmental Condition: Topography / Spatial Characteristics", "Objective Function 1: Indicator", "Objective Function 1: Target Value", "Objective Function 1: Weighting Coefficient", "Objective Function 2: Indicator", "Objective Function 2: Target Value", and "Objective Function 2: Weighting Coefficient". The "Request ID" field is an ID that uniquely identifies the request.

[0103] The item "Reception Date and Time" is the date and time the request was received.

[0104] The item "Natural Language Input Original Text" is the original text entered by the user.

[0105] The item "Interpretation Status" indicates the progress (or state) of the interpretation and definition of the requirements.

[0106] The item "Robot Type (Definition)" is the basic type (or attribute) of the robot defined from the requirements.

[0107] The item "Mission Overview (Definition)" is the main task defined from the requirements.

[0108] The item "Physical constraints: Maximum size" refers to the maximum allowable dimensions (width x depth x height) of the robot.

[0109] The item "Physical Constraints: Maximum Weight" is the maximum allowable total weight of the robot body.

[0110] The item "Physical constraints: Load capacity" refers to the weight of the cargo that the robot must carry.

[0111] The item "Environmental Conditions: Operating Temperature Range" refers to the temperature range in which the robot is guaranteed to operate.

[0112] The item "Environmental Conditions: Maximum Wind Speed" is the maximum wind speed at which the robot must maintain its operation (flight).

[0113] The item "Environmental Conditions: Terrain / Spatial Characteristics" specifies the characteristics of the expected operating environment and the environment model to be used. Specifically, it includes links to 3D map data of the environment to be used in the simulation (e.g., point cloud, mesh, GIS data, CAD data), physical property parameters such as gravity, atmospheric density, and surface friction coefficient, or identifiers that specify a particular environment model (e.g., "Urban Area Model A", "Lunar Environment Model B").

[0114] The item "Objective Function 1: Metric" is the primary evaluation metric for optimization. This is either an identifier for a standard quantitative metric defined within the system (e.g., "Maximum Speed ​​(m / s)", "Energy Efficiency (Wh / km)", "Task Completion Time (seconds)"), or a script or formula definition data for calculating a score from the simulation results (e.g., definition of the reward function in reinforcement learning).

[0115] The item "Objective Function 1: Target Value" is the target value (or specification of minimization / maximization) that Objective Function 1 aims to achieve.

[0116] The item "Objective Function 1: Weighting Coefficient" represents the priority of Objective Function 1 in the optimization calculation.

[0117] The item "Objective Function 2: Metrics" is a secondary evaluation metric for optimization.

[0118] The item "Objective Function 2: Target Value" is the target value that you aim to achieve with Objective Function 2.

[0119] The item "Objective Function 2: Weighting Coefficient" represents the priority of Objective Function 2 in the optimization calculation.

[0120] Figure 6 shows the data structure of the component database 212. The component database 212 includes the following items: "Component ID", "Component Name", "Major Category", "Minor Category", "Manufacturer", "Physical Properties: Dimensions", "Physical Properties: Mass", "Physical Properties: Material", "Performance Specifications: Key Values", "Performance Specifications: Rated Voltage", "Performance Specifications: Power Consumption (Average)", "Interface Specifications", "Environmental Resistance: Operating Temperature Range", "Cost Information", "3D Model File Path", "Simulation Parameters", and "Recommended Flag". The "Component ID" field is an ID that uniquely identifies the component.

[0121] The "Component Name" field is the name or model number of the component.

[0122] The item "Category Classification" is the main classification (or attribute) of the component.

[0123] The item "Category Subcategory" is a detailed classification (or attribute) of the component.

[0124] The "Manufacturer" field is the name of the component's manufacturer.

[0125] The item "Physical Properties: Dimensions" refers to the external dimensions (width x depth x height) of the component.

[0126] The item "Physical Properties: Mass" is the mass of the component.

[0127] The item "Physical Properties: Material" refers to the main constituent materials.

[0128] The item "Performance Specifications: Key Values" refers to the key performance values ​​of the component (e.g., maximum torque, battery capacity).

[0129] The item "Performance Specifications: Rated Voltage" is the rated operating voltage of the component.

[0130] The item "Performance Specifications: Power Consumption (Average)" represents the average power consumption during standard operation.

[0131] The "Interface Specifications" item refers to the connection methods and communication protocols with other components. This includes information on physical interfaces (e.g., flange shape, screw hole standard (M5) and arrangement, connector shape), electrical interfaces (e.g., power requirements (voltage and current), pin assignments), and logical interfaces (e.g., communication protocols (CAN, Ethernet), API specifications, corresponding ROS message types).

[0132] The item "Environmental Resistance: Operating Temperature Range" refers to the temperature range over which the component is guaranteed to operate.

[0133] The item "Cost Information" is the unit price of the component.

[0134] The item "3D Model File Path" is the location (or file path) where the component's 3D model data (CAD, USD, etc.) is saved.

[0135] The "Simulation Parameters" item contains detailed parameters used in physical simulations (such as moment of inertia and friction coefficient). It also includes information that defines the dynamic characteristics of the component. For example, for a motor, this would include the "torque curve (relationship between rotational speed and torque)" and the response delay model, while for a battery, it would include the "discharge characteristics (relationship between remaining capacity and output voltage)." These can be stored in the form of lookup tables or approximation functions.

[0136] The "Recommended Flag" item indicates whether or not the system recommends using a component as a priority.

[0137] Figure 7 shows the data structure of the robot configuration database 213. The robot configuration database 213 includes the following items: "Configuration ID", "Request ID (Reference)", "Parent Configuration ID", "Generation Date and Time", "List of Components Used", "Assembly Structure Definition", "Predicted Physical Characteristics: Total Mass", "Predicted Physical Characteristics: Center of Gravity Position", "Overall 3D Model File Path", "Control Policy Type", "Control Policy Parameters", "Trained Model File Path", "Simulation Score (Overall)", "Evaluation Index 1: Achieved Value", "Evaluation Index 2: Achieved Value", "Physical Practicality Flag", and "Recommended Flag".

[0138] The item "Configuration ID" is an ID that uniquely identifies this robot configuration (design proposal).

[0139] The item "Request ID (Reference)" is the Request ID (reference to the Request / Constraint data) targeted by this configuration.

[0140] The "Parent Configuration ID" field is the ID of the configuration immediately preceding the current configuration in the optimization loop.

[0141] The item "Generation Date and Time" is the date and time this configuration was created.

[0142] The item "List of Components Used" is a list of component IDs and quantities used in this configuration.

[0143] The "Assembly Structure Definition" item is data (e.g., URDF / SDF format) that defines the connection relationships between components, relative positions, joint structures, etc. This definition is used to construct the kinematics and dynamics model of the robot. In addition to data for existing parts, this definition also includes references to new shape data (e.g., voxel data, mesh data (STL format, etc.), or neural implicit representation) automatically generated by the design and control generation unit 2036, as well as physical properties (e.g., mass distribution, inertia tensor) calculated from that shape data.

[0144] The item "Predicted Physical Properties: Total Mass" is the total mass of the robot calculated from the proposed configuration.

[0145] The item "Predicted Physical Characteristics: Center of Gravity Position" is the center of gravity position (X, Y, Z) of the robot calculated from the proposed configuration.

[0146] The item "Overall 3D Model File Path" is the location (or file path) where the 3D model data for the entire robot that has been generated is saved.

[0147] The item "Control Policy Type" indicates the type (or attribute) of the control algorithm being used.

[0148] The "Control Policy Parameters" field contains the set of parameters (NN weights, PID gains, etc.) that define the control policy. When the control policy is implemented using a neural network, this field includes not only the trained weight parameters but also information defining the network architecture (layer structure, number of nodes, activation function, etc.). For example, the computation graph and parameters may be stored in an integrated format, such as the ONNX (Open Neural Network Exchange) format.

[0149] The item "Trained Model File Path" is the location (or file path) where the trained (optimized) control model file is saved.

[0150] The item "Simulation Score (Overall)" is the overall evaluation score calculated based on the objective function.

[0151] The item "Evaluation Index 1: Achieved Value" is the achieved value of objective function 1 (e.g., cruising range) obtained from the simulation.

[0152] The item "Evaluation Indicator 2: Achieved Value" is the achieved value of objective function 2 (e.g., manufacturing cost) obtained from the simulation.

[0153] The "Physically Valid Flag" item is a flag that indicates whether the simulation was physically valid (e.g., does not tip over, is capable of flight).

[0154] <3 operations> Figure 8 shows the overall processing flow of the robot generation process. In Figure 8, the main processing flow of the entire system is shown, consisting of a series of steps from requirements reception to interpretation, initial design generation, execution of the optimization loop, and output of the final result.

[0155] In step S811, terminal 10 receives an operation from the user and displays a request input screen for robot generation.

[0156] In step S812, terminal 10 receives the request (natural language text, parameters, etc.) entered by the user and sends it to the server device.

[0157] In step S821, the server 20 receives a request from the terminal (request reception processing).

[0158] In step S822, the server 20 analyzes the received request (interpretation process). If the request is ambiguous, it proceeds to the interactive requirements definition process shown in Figure 10.

[0159] In step S823, the server 20 defines physical and engineering constraints and an objective function based on the analysis results.

[0160] In step S824, the server 20 generates an initial hardware configuration (and control policy) for the robot based on the defined constraints (design generation process). For example, to generate the initial configuration, one method is to select a standard template (template) according to the requested robot type (e.g., drone) and make initial adjustments to the parameters (e.g., arm length) to match the constraints. Alternatively, one may search for past design examples to use as initial values, or use a trained generative model to directly generate an initial configuration that is likely to satisfy the constraints.

[0161] In step S825, server 20 starts the optimization loop process. For details, please refer to the flowchart in Figure 9 or Figure 11.

[0162] In step S826, the server 20 iteratively performs simulation-based evaluation and updates of the design proposal as part of the optimization loop process.

[0163] In step S827, the server 20 terminates the optimization loop process if it meets the termination conditions (e.g., achieving the target performance, reaching the maximum number of iterations).

[0164] In step S828, the server 20 generates the final optimized hardware configuration data (CAD data, etc.) and control policy (software package, etc.) (result output processing).

[0165] In step S829, the server 20 sends the generated final result data to the terminal.

[0166] In step S813, terminal 10 receives the final result data from the server device and displays a design result confirmation screen (3D model, performance report, etc.).

[0167] Figure 9 shows a detailed processing flow of the simultaneous optimization process. In Figure 9, the detailed processing flow within the optimization loop shows the iterative process of generating hardware configuration proposals and control policies, evaluation by simulation, and parameter updates (application of optimization algorithms) based on the evaluation results.

[0168] In step S921, the server 20 obtains the current hardware configuration proposal and control policy proposal (or parameters to generate them) (optimization loop start).

[0169] In step S922, server 20 deploys (places and configures) the proposed hardware configuration and control policy in the virtual space (digital twin environment). Specifically, it analyzes the assembly structure definition of the proposed hardware configuration (see Figure 7) and converts it into a format that the simulation engine can interpret (e.g., URDF, USD). Then, it sets the 3D model and physical parameters of each component to build a physical model of the robot in the virtual space and loads the proposed control policy into the virtual controller on the robot model.

[0170] In step S923, the server 20 executes a physics simulation under the specified task and environment. The task to be executed is automatically set based on the objective function. For example, when evaluating flight range, a task is set to follow a specified waypoint sequence in a virtual space. When evaluating flight stability, a task is set to maintain hovering (a stationary aircraft) while intentionally generating disturbances (e.g., gusts of wind) in the virtual space.

[0171] In step S924, the server 20 collects the results of the physical calculations (robot motion logs, sensor data, etc.).

[0172] In step S925, the server 20 evaluates the collected results based on the objective function and calculates a performance score.

[0173] In step S926, server 20 determines whether the termination condition is met. If it is, it terminates the loop and returns to the overall flow (Figure 8).

[0174] In step S927, the server 20 calculates updated values ​​for the design parameters and control parameters using an optimization algorithm (e.g., gradient method, reinforcement learning) based on the performance score (if the termination condition is not met).

[0175] In step S928, the server 20 updates the proposed hardware configuration and control policy based on the calculated updated values ​​and generates a next-generation proposal. The tasks to be executed are automatically set based on the objective function. For example, when evaluating range, a task is set to follow a specified waypoint sequence in virtual space. When evaluating flight stability, a task is set to maintain hovering (a stationary aircraft) while intentionally generating disturbances (e.g., gusts of wind) in virtual space. The update of the proposed hardware configuration differs depending on the representation format of the design variables. If the design variables are continuous parameters (e.g., arm length), the parameter values ​​are fine-tuned based on the updated values ​​(e.g., gradient information). If the shape or topology is represented by voxels, the structure is modified by updating the density distribution of each voxel based on the updated values. When using evolutionary algorithms, the connection relationships of components are changed, or new components are added or removed.

[0176] In step S929, the server 20 returns to step S922 in order to continue processing using the updated configuration (S928).

[0177] Figure 10 shows the workflow for receiving requirements definitions interactively. As an example of the interactive processing in the requirements reception unit, Figure 10 shows the steps in which the system generates questions in response to ambiguous user input, and gradually concretizes and quantifies the requirements.

[0178] In step S1011, terminal 10 receives a request in natural language entered by the user and sends it to the server device.

[0179] In step S1021, the server 20 receives the request and analyzes the request content using a natural language processing model (LLM, etc.).

[0180] In step S1022, the server 20 determines, based on the analysis results, whether there is insufficient information to define the constraints and objective function, or whether the request contains ambiguity.

[0181] In step S1023, the server 20 generates questions (e.g., "What is the specific wind speed for 'strong winds'?") to clarify the missing information or ambiguities (if there is insufficient or ambiguous information).

[0182] In step S1024, the server 20 sends the generated question to the terminal 10. This question generation is performed, for example, using an LLM (Large-Scale Language Model). The LLM compares the current requirements with the parameter definition template required for the design and identifies any missing parameters. If the user's requirements are in a trade-off relationship with other constraints, the server may also generate a question that explicitly states the trade-off, such as, "If we increase the speed by 20%, the range may decrease by 15%. Is this acceptable?"

[0183] In step S1012, terminal 10 receives a question from the server device and displays it on the dialogue interface.

[0184] In step S1013, terminal 10 receives the user's input and supplementary information and sends it to the server device.

[0185] In step S1025, the server 20 receives the response and analyzes and evaluates the request again. (The process from question generation to response reception is repeated until sufficient information is available.) In step S1026, the server 20 defines the constraints and objective function based on the information finally obtained (assuming sufficient information and no ambiguity).

[0186] In step S1027, the server 20 generates a summary of the defined content and sends it to the terminal for user confirmation.

[0187] In step S1014, terminal 10 receives a summary of the definition content, presents it to the user, and requests final confirmation (approval or modification instructions). If approved, the process proceeds to the design generation process of the overall flow (Figure 8).

[0188] Figure 11 shows the process flow for optimizing group control. In Figure 11, the objective function is the overall mission achievement level of the robot group, and the process flow for optimizing the group's configuration and cooperative actions (e.g., energy replenishment plan, communication maintenance protocol) is shown.

[0189] In step S1121, the server 20 sets the objective function (optimization loop start) as "mission achievement level of the entire group" and obtains the current proposed configuration of the entire robot group (composition of each individual, heterogeneity ratio, division of roles) and proposed control policy (cooperative algorithm). The proposed configuration of the entire group is expressed as a parameter set that defines the number of robots of each type (heterogeneity ratio), for example, "5 observation robots (type A), 1 supply robot (type B)". The division of roles is defined by the control policies assigned to each type (e.g., observation policy, supply policy).

[0190] In step S1122, server 20 deploys the entire group of robots into the virtual space.

[0191] In step S1123, server 20 executes a multi-agent physics simulation aimed at achieving the mission for the entire group.

[0192] In step S1124, the server 20 generates events that simulate specific scenarios (e.g., energy depletion, communication failure (GPS rejection), device failure) as needed.

[0193] In step S1125, the server 20 collects operation logs for the entire group (e.g., energy consumption trends, communication maintenance status, accuracy of cooperative self-localization, mission completion rate).

[0194] In step S1126, the server 20 evaluates the collected results based on the objective function for the entire group and calculates a performance score.

[0195] In step S1127, server 20 determines whether the termination condition is met. If it is, it terminates the loop and returns to the overall flow (Figure 8).

[0196] In step S1128, the server 20 calculates an updated value based on the performance score using a group-wide optimization algorithm (if the termination condition is not met). Examples of group-wide optimization algorithms that can be used include multi-agent reinforcement learning (MARL) methods (e.g., MAPPO (Multi-Agent Proximal Policy Optimization)) and cooperative coevolutionary algorithms.

[0197] In step S1129, the server 20 updates the group configuration (e.g., changing the ratio of supply aircraft) and control policies related to coordinated operation (e.g., adjusting the energy supply plan) based on the calculated updated values.

[0198] In step S1130, the server 20 returns to step S1122 to continue processing using the updated group configuration plan and control policy (S1129).

[0199] <4 Screen Examples> Figure 12 shows an example of a requirements input / interaction screen.

[0200] The request input / interaction screen 1200 is a screen where the user inputs requests regarding the robot and clarifies those requirements while interacting with the system.

[0201] The dialogue history display area 1202 is an area that displays the history of system questions, user input, and the results of interpreting requests in chronological order (chat format).

[0202] The current requirements summary display area 1204 is an area that structures and displays the current confirmed constraints (physical constraints, environmental conditions) and objective function (performance target) defined through interaction.

[0203] The parameter setting auxiliary display area 1206 is an area that displays candidate parameters (e.g., maximum size, target cost) and input guides for which the user can specify specific numerical values.

[0204] The system status display area 1208 is an area (or indicator) that displays the current state of the system (e.g., input analysis in progress, question generation in progress, waiting).

[0205] The natural language input unit 1210 is an operating component that accepts instructions from the user to input requests regarding the robot or answers to questions from the system in free text.

[0206] The parameter input unit 1212 is an operating component that accepts user inputs and specifications of specific constraints and target values ​​using numerical values ​​or selection options.

[0207] The transmission operation unit 1214 is an operation component that accepts operations for transmitting the content entered in the natural language input field to the system (server device).

[0208] The optimization start operation unit 1216 is an operating member that receives an operation to instruct the robot generation and optimization process to start based on defined requirements.

[0209] The new project creation operation unit 1218 is an operation component that accepts operations to start a new robot generation project and reset the requirements input.

[0210] The reference material upload operation unit 1220 is an operation component that accepts operations for uploading reference materials related to the request (e.g., photos of the operating environment, specifications of existing equipment).

[0211] Figure 13 shows an example of a screen displaying the simulation and optimization status.

[0212] The Simulation / Optimization Status Display Screen 1300 is a dashboard screen that visualizes the progress of the optimization process (Co-Design loop).

[0213] The digital twin simulation display area 1302 is a 3D viewer (or area for displaying the 3D viewer) that renders in real time how the robot of the current design is performing a task in a virtual space (digital twin environment).

[0214] The hardware design proposal display area 1304 is a static 3D viewer (or area for displaying a 3D viewer) for checking the shape and structure of the hardware configuration proposal currently under evaluation.

[0215] The performance evaluation graph display area 1306 is an area that displays the progress of the performance score (degree of achievement of the objective function) for each optimization iteration using a line graph or similar method.

[0216] Key Performance Indicators (KPIs) display area 1308 is an area that displays key performance indicators (e.g., estimated cost, total weight, predicted speed, energy efficiency) in numerical form for the current design proposal.

[0217] The progress display area 1310 is a bar or indicator that shows the overall progress of the optimization process (e.g., current number of iterations / maximum number of iterations).

[0218] The event log display area 1312 is an area that displays important events that occurred during the simulation (e.g., task completion, occurrence of physical interference, errors) in text format.

[0219] The pause / resume operation unit 1314 is an operating member that receives operations to pause or resume the optimization process that is currently running.

[0220] The cancellation operation unit 1316 is an operation member that accepts an operation to cancel the optimization process that is currently running and to finalize or discard the best design proposal at that time.

[0221] The simulation speed adjustment unit 1318 is an operating component (e.g., slider, dropdown) that accepts a specification for adjusting the drawing speed of the simulation viewer (e.g., normal speed, double speed).

[0222] The viewpoint control unit 1320 is a control (or control screen) for operating the viewpoint (camera angle, zoom) of the 3D viewer (simulation, hardware design proposal).

[0223] Figure 14 shows an example of the screen displaying the design results and the output screen.

[0224] The design result confirmation / output screen 1400 is used to confirm the final hardware configuration proposal obtained after optimization processing and to output various data.

[0225] The final hardware design display area 1402 is an interactive viewer (or area for displaying a 3D model) that displays a 3D model of the optimized final robot configuration.

[0226] The specifications list display area 1404 is an area that displays the main specifications of the final design (dimensions, weight, list of components used, and cost) in a table format.

[0227] The predictive performance report display area 1406 is an area that displays detailed performance evaluations based on simulation results (task completion rate, durability, energy efficiency analysis, etc.).

[0228] The design rationale report display area 1408 is the area that displays a report (XAI) that explains why the AI ​​selected this design and which constraints influenced the design.

[0229] The download link list display area 1410 is an area that displays download links to various exported data (CAD, software, BOM, etc.).

[0230] The CAD data output operation unit 1412 is an operation component that accepts an operation to perform an export process of hardware configuration data in a specified format (e.g., STEP, STL).

[0231] The software package output operation unit 1414 is an operation component that accepts an operation to execute an export process for an optimized control policy (trained model, ROS package, etc.).

[0232] The manufacturing instruction data generation operation unit 1416 is an operation component that accepts operations to generate and output manufacturing instruction data such as bill of materials (BOM) and 3D printing data.

[0233] The project save operation unit 1418 is an operating component that accepts operations to save the design results and the entire process as a project.

[0234] The requirements modification / re-execution operation unit 1420 is an operation component that accepts an operation to transition to the requirements input screen in order to modify the requirements based on the current results and execute the optimization process again.

[0235] <Variation>

[0236] (1) Information processing system that performs language processing in response to prompt input In the above description of the embodiment, as an example of an information processing system that performs language processing in response to prompt input, an example was described in which a prompt is sent to a server 95 of a large-scale language model service, which is an external information processing system, and the result generated by the server 95 of the large-scale language model service in response to the prompt is received.

[0237] Alternatively, instead of using an external information processing system, a large-scale language model may be run on terminal 10 to perform processing in response to prompts. Alternatively, the large-scale language model may be run on server 20, which holds the information to be included in the prompts.

[0238] As described above, the information processing system that performs language processing in response to prompt input may be an external information processing system different from the service provided by server 20, server 20 may have the functionality of the information processing system, or it may be run on terminal 10. Terminal 10 may have a processor such as a GPU (Graphics Processing Unit) for running a large-scale language model, and this processor may be used to perform the functionality of the large-scale language model that performs language processing in response to prompt input. For example, server 20 may provide a large-scale language model to run on terminal 10, and terminal 10 may be configured to build an information processing system that performs language processing.

[0239] (2) Variations utilizing specific technical resources The system of the present invention can further enhance its value by integrating with specific existing technological resources and platforms. The following describes embodiments of integration in key technological areas.

[0240] (Modification 2-1: Integration with a high-performance simulation platform) High-fidelity physical simulations present challenges such as high computational costs and time-consuming optimization loop execution. To address these challenges, a high-performance physical simulation platform and large-scale GPU resources can be utilized as the foundation for the simulation execution unit 2037 and optimization execution unit 2038 of the present invention.

[0241] In this configuration, the optimization execution unit 2038 may perform the following advanced optimization techniques to improve computational efficiency.

[0242] Firstly, it employs adaptive multifidelity optimization. Low-fidelity, fast simulations are used in the initial stages of the optimization loop, and then a high-fidelity simulation is switched to in the later stages as the design approaches convergence.

[0243] Secondly, we utilize neural surrogate models. By automatically generating lightweight AI models (neural surrogate models) that have learned from the results of high-fidelity simulations and using them as a substitute for costly physics calculations, we can speed up the entire optimization loop.

[0244] Thirdly, there is the use of scalable differentiable physics simulations. By utilizing large-scale GPU resources and employing differentiable physics simulators that can handle numerous agents and complex physical phenomena (fluid dynamics, flexible materials, etc.), simultaneous design of the entire group (co-design) becomes possible.

[0245] (Modification 2-2: Swarm control platforms and applications in the defense sector) In the defense sector and other fields, there is a need to balance performance with cost and mass production feasibility, as well as to integrate with existing assets. To address this challenge, for example, a configuration that integrates with swarm control and command and control systems can be adopted.

[0246] In this configuration, the request reception / dialogue unit 2034 accepts "expected consumption rate" and "target unit price" as constraints. The optimization execution unit 2038 simultaneously optimizes the overall configuration of the heterogeneous group, which combines a small number of high-performance machines with inexpensive "attritable" machines, based on mission achievement and total cost.

[0247] Alternatively, the constraint interpretation unit 2035 may accept specifications of existing assets already owned by the customer (e.g., assets managed by a group control platform) as input, and the optimization execution unit 2038 may generate new robots that complement the capabilities of these existing assets. In this case, the result output unit 2039 also outputs an interface module for integration into the existing system.

[0248] Furthermore, the simulation execution unit 2037 may simulate an adversarial environment (jamming signals, hostile drones), and the optimization execution unit 2038 may optimize robustness using adversarial learning.

[0249] (Variation 2-3: Integration with manufacturing and PLM systems) In the industrial sector, balancing customizability with production efficiency and maintainability is a challenge. To address this challenge, configurations can be implemented that integrate with PLM (Product Lifecycle Management) systems or digital twin environments for production lines.

[0250] In this configuration, the constraint interpretation unit 2035 accepts digital twin information of the customer's entire existing production line and information from the standard parts library managed by the PLM system as input.

[0251] The design and control generation unit 2036 refers to this information and prioritizes generating designs that utilize common modules as much as possible (modularization constraints) and differential designs based on existing design assets. This derives a design that balances task optimization with production and maintenance efficiency.

[0252] Furthermore, the optimization execution unit 2038 may be configured to use the overall throughput of the production line as its objective function and simultaneously generate and verify the optimal robot configuration, placement location, and motion plan within spatial constraints.

[0253] (Variation 2-4: Integration with large-scale AI models) The challenges lie in achieving both the flexibility of natural language and engineering rigor, as well as improving the innovativeness of the design. To address these challenges, for example, a configuration can be adopted that integrates with large-scale language models (LLMs) provided by companies such as Google® and OpenAI (e.g., Gemini®, GPT®) and underlying modeling technologies.

[0254] In this configuration, the request reception / interaction unit 2034 and the constraint interpretation unit 2035 function as advanced interactive interfaces using LLM. In response to ambiguous user instructions (e.g., "Make it more stable"), the system responds with questions about specific engineering parameters (e.g., "We will lower the battery mounting position to improve stability, but this will reduce the minimum ground clearance by 5 cm. Is that alright?"), thereby gradually concretizing and quantifying the requirements.

[0255] Alternatively, the result output unit 2039 may be configured to automatically generate a design rationale report (Explainable AI: XAI) in which the LLM analyzes the optimization process (how each constraint affected the design) and explains in natural language why the final design was selected.

[0256] Furthermore, the design and control generation unit 2036 may be configured to generate design proposals using a "robotics base model" that has been pre-trained on physical laws and a vast amount of past robot design data. This makes it possible to generate innovative designs faster and with higher accuracy than searching from scratch.

[0257] (Variation 3: Application to space exploration and in-situ resource utilization (ISRU)) The system of the present invention is applicable not only on Earth but also to exploration and base construction activities in outer space, such as on the lunar surface or Mars. In space development, the cost of transporting supplies from Earth is extremely high, making it inefficient to design, manufacture, and launch a dedicated robot for each specific mission. Therefore, there is a need for technology that utilizes locally available resources (ISRU: In-Situ Resource Utilization) and pre-deployed manufacturing equipment (e.g., 3D printers) to manufacture necessary robots and tools on demand. In this modified example, the system of the present invention is configured as a robot generation platform based on ISRU and on-site manufacturing.

[0258] The first stage of the process in this modified version is sensing the local conditions and building / updating the digital twin. First, existing probes and installed sensors operating in the local area (e.g., the lunar surface) collect local environmental data (e.g., detailed topography, geology, temperature distribution, radiation levels). The collected local data is input into the system via the real-world feedback unit 2041.

[0259] The simulation execution unit 2037 uses this data to update the virtual space (digital twin environment) with high precision to match the actual conditions on site. This digital twin environment faithfully reproduces not only the 3D terrain model of the target area, but also physical parameters that affect the robot's movement, such as the microgravity of the lunar surface, the vacuum, and the physical properties of the regolith (lunar sand) (friction coefficient, shear strength, etc.).

[0260] The second stage involves managing available local resources. Resource data obtained through on-site exploration (e.g., regolith composition, presence of ice) and information on materials stored in local depots (warehouses) (e.g., stock of resins and metal powders for 3D printers, standard electronic components) are collected and managed.

[0261] These resource data are registered in the Knowledge Base / Model Management Unit 2040 (or a dedicated ISRU resource database). This database stores the physical properties of locally available materials (strength, density, heat resistance, etc.), available quantities (stock levels), and specifications of available locally manufactured equipment (build size, precision, speed, energy consumption).

[0262] The third stage is the optimization of the design based on the ISRU. The user (e.g., a control center on Earth or an astronaut on site) inputs a new mission requirement, such as "collect a sample from a specific crater," into the Request Reception / Dialogue Unit 2034. When interpreting this requirement, the Constraint Interpretation Unit 2035 defines "the quality and quantity of available local resources" and "the capacity of the local manufacturing equipment" as the main constraints.

[0263] Based on these constraints, the design and control generation unit 2036 generates hardware configuration proposals that maximize the use of local resources. For example, it prioritizes generating designs that assume the main structural components of the robot are 3D printed on-site using lunar regolith as the raw material. In this process, the principles of Design for Additive Manufacturing (DfAM) are applied, minimizing the use of expensive components transported from Earth.

[0264] The optimization execution unit 2038 iteratively performs performance evaluations on the constructed high-precision digital twin environment of the lunar surface. In this process, the objective function is set to maximize mission success while minimizing resource consumption (especially Earth-derived materials), manufacturing time, and energy consumption during manufacturing.

[0265] The final optimized hardware configuration data is converted by the results output unit 2039 into manufacturing instruction data (e.g., G-code for 3D printing, assembly instructions) that can be interpreted by local manufacturing equipment, and output. This makes it possible to quickly procure optimized robots and tools on-site without waiting for transport from Earth in the event of unexpected situations or new missions.

[0266] (Modification 4: Application to function absorption (add-on function expansion) in spacecraft) The system of the present invention can also be applied to a "function absorption" approach in which the functions of a spacecraft such as a space station or artificial satellite (hereinafter referred to as the host spacecraft) are later extended or replaced by a robot. In conventional space development, it was necessary to install various subsystems such as environmental control, communication, attitude control, and observation on the host spacecraft itself, which led to system complexity, prolonged development periods, and increased launch costs. Furthermore, the functions of a spacecraft once launched become fixed, making it difficult to adapt to new missions or replace faulty subsystems later on.

[0267] In this modified version, the initial configuration of the host spacecraft is intentionally made simple and lightweight (for example, having only a basic structure and power supply) to reduce launch costs. Subsequently, robots that perform the necessary functions (hereinafter referred to as "function-absorbing robots") are transported separately or manufactured on-site and deployed to the host spacecraft. These function-absorbing robots function as subsystems of the host spacecraft, making it possible to flexibly add and modify the functions of the spacecraft. The system of the present invention is used to optimally design and produce these function-absorbing robots to suit a specific host spacecraft and mission.

[0268] In this modified example, the request reception / dialogue unit 2034 receives requests from the user regarding tasks to be performed or functions to be delegated to the function absorption robot. For example, requests such as "continuously monitor the environment inside the space station (temperature, humidity, CO2 concentration, radiation level) and issue an alert if an anomaly occurs," "understand and optimize the inventory layout inside the ship," and "assist with the attitude control of a specific satellite" may be input.

[0269] In addition to these requirements, the constraint interpretation unit 2035 accepts specification information of the host spacecraft in question as input. This includes information about the host spacecraft's geometry (e.g., a 3D model of the station interior), available resources (e.g., power supply, communication interfaces), and the capabilities of existing subsystems.

[0270] The simulation execution unit 2037 constructs a digital twin of the host spacecraft, including its internal or external environment, based on the host spacecraft's specifications. For example, inside a space station, it simulates the behavior of objects and airflow under microgravity (zero gravity) conditions.

[0271] The design and control generation unit 2036 and the optimization execution unit 2038 use this digital twin environment to optimize the robot configuration that can most efficiently perform the requested function absorption task. For example, when performing environmental monitoring while moving inside a station, the configuration of the propulsion mechanism (e.g., small thrusters, control moment gyro (CMG), or wall-gripping arm), the placement of various sensors, and the movement control policy under microgravity are simultaneously optimized (co-designed) to efficiently move without colliding with structures inside the station. In this process, the objective function is set to minimize the robot's mass (which directly impacts launch costs) and power consumption, in addition to the degree of task achievement.

[0272] The optimized design data of the function-absorbing robot is output from the result output unit 2039. Based on this data, it is possible to manufacture and launch the robot on the ground, or to combine it with Modification 3 (ISRU) and manufacture it on-site using a 3D printer or the like deployed in outer space.

[0273] Furthermore, the system of the present invention is also capable of generating a group (swarm) in which a plurality of function-absorbing robots cooperate (see Figure 11). For example, it is possible to optimize the entire system that realizes advanced cooperative operations, such as "automatically evacuating important supplies from an area with increased radiation dose to a safe area", by linking a group of robots responsible for environmental monitoring and a group of robots responsible for logistics management. In addition, the system centrally manages the information of a plurality of host spacecraft existing in outer space and the function-absorbing robots deployed thereon, and it is also possible to generate a resource optimization plan for the entire outer space, such as transferring and reconfiguring a robot that is no longer needed on one spacecraft to another spacecraft for use.

[0274] (Modification 5: Application to dual-use design for normal times and emergency situations) The system of the present invention is applicable to the realization of "dual resilience" required in urban development (smart cities) and infrastructure management. Dual resilience is a concept of designing robots and infrastructures so that they can be used for both the purpose of improving efficiency and convenience in normal times (e.g., logistics, inspection, service provision) and the purpose of maintaining safety and functions in emergency situations (e.g., disaster response, defense, security). Conventionally, these purposes have different required performances (e.g., quietness in normal times and traversability in emergency situations), and are often in a trade-off relationship. In addition, there has been a problem that it is difficult to justify investment in advanced technologies based only on commercial returns in normal times, while systems dedicated to emergency situations have a low operation rate in normal times.

[0275] In this modified example, by using the system of the present invention, a robot with dual resilience that has a common hardware configuration and whose role can be changed (reversible) by switching software (control policy) according to the situation is automatically generated. As a result, investments in advanced technologies can be rationalized as "insurance" against the essential requirements of disaster prevention and national defense, while also enabling contributions to peacetime economic activities, thereby maximizing return on investment.

[0276] In this configuration, a request reception and interaction unit 2034 receives two or more types of requests, namely "peacetime missions" and "emergency missions", from a user. For example, for an autonomous mobile robot operated in an urban area, "efficient package delivery on paved roads" is input as a peacetime requirement, and "supply transportation and surrounding monitoring on uneven terrain with debris after an earthquake occurs" is input as an emergency requirement.

[0277] A constraint interpretation unit 2035 defines a plurality of objective functions based on these requests. Specifically, a first objective function (e.g., energy efficiency, quietness) for evaluating the performance of the peacetime mode, and a second objective function (e.g., uneven terrain traversability, durability, communication robustness) for evaluating the performance of the emergency mode are defined. In addition, constraints common to both modes and mode-specific constraints (e.g., dustproof and waterproof performance in the emergency mode) are also defined.

[0278] A simulation execution unit 2037 constructs or switches to use a digital twin environment capable of simulating both a peacetime scenario (e.g., a normal urban environment) and an emergency scenario (e.g., a disaster simulation environment).

[0279] An optimization execution unit 2038 comprehensively evaluates the performance in these multiple different scenarios and executes optimization. The comprehensive evaluation is performed, for example, by a weighted sum obtained by multiplying the achievement level of each objective function by a weighting factor corresponding to the importance of peacetime and emergency, or by searching for a Pareto optimal solution. Then, updates of the hardware configuration plan and the control policy plan are iterated so as to improve this comprehensive evaluation.

[0280] This optimization process derives a balanced common hardware configuration for both missions. Simultaneously, the optimization execution unit 2038 generates and optimizes control policies for normal operation (e.g., efficiency-prioritizing mode) and emergency operation (e.g., off-road capability-prioritizing mode) that operate on this common hardware. For example, even with the same wheel and motor configuration, the normal operation policy learns to perform smooth speed control to conserve energy, while the emergency operation policy learns to extract maximum torque to overcome obstacles.

[0281] The result output unit 2039 outputs optimized common hardware configuration data and a software package containing multiple control policies. This software package may include a management module for automatically and safely switching control policies in response to external instructions or environmental changes (e.g., earthquake detection). This enables the realization of a robot whose role can be reversibly changed simply by switching the software (brain) without changing the hardware, significantly improving the return on investment.

[0282] <Other> In the above description, "processor" refers to one or more processors. At least one processor is typically a microprocessor such as a CPU (Central Processing Unit), but may be another type of processor such as a GPU (Graphics Processing Unit). At least one processor may be single-core or multi-core.

[0283] Furthermore, at least one processor may be a broad-sense processor, such as a hardware circuit that performs some or all of the processing (e.g., an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)).

[0284] Furthermore, in the above explanation, the term "xxx table" is sometimes used to describe information that yields an output for a given input. This information can be data with any structure, or it can be a learning model such as a neural network that generates an output for a given input. Therefore, "xxx table" can be referred to as "xxx information."

[0285] Furthermore, the above description is merely an example of the structure of each table; one table may be divided into two or more tables, or all or part of two or more tables may constitute a single table.

[0286] Furthermore, while the above explanation sometimes uses "program" as the subject to describe the process, a program is executed by a processor and performs defined processes using the memory and / or interface as appropriate. Therefore, the subject of the process may also be the processor (or a device such as a controller that has that processor).

[0287] The program may be installed on a device such as a computer, or it may reside on a program distribution server or a computer-readable (e.g., non-temporary) recording medium. Furthermore, in the following description, two or more programs may be implemented as a single program, or one program may be implemented as two or more programs.

[0288] A network consists of various mobile communication systems, such as the internet, LANs, and wireless base stations. For example, a network includes 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks that can connect to the internet via designated access points (e.g., Wi-Fi®). When connecting wirelessly, communication protocols include, for example, Z-Wave®, ZigBee®, and Bluetooth®. When connecting via a wired connection, the network also includes connections made directly via USB (Universal Serial Bus) cables, etc.

[0289] Furthermore, by distributing all or part of each hardware configuration across multiple computers and connecting them to each other via a network, a computer can be virtually realized. Thus, the concept of a computer includes not only computers housed in a single enclosure or case, but also virtualized computer systems.

[0290] Furthermore, each of the above-mentioned configurations, functions, processing units, processing means, etc., may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. The present invention can also be implemented by software program code that realizes the functions of the embodiment. In this case, a storage medium on which the program code is recorded is provided to a computer, and the processor of that computer reads the program code stored in the storage medium. In this case, the program code read from the storage medium itself realizes the functions of the embodiment described above, and the program code itself and the storage medium on which it is stored constitute the present invention. Examples of storage media used to supply such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs, optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, ROMs, and the like.

[0291] Furthermore, the program code that implements the functions described in this embodiment can be implemented in a wide range of programming or scripting languages, such as assembler, C / C++, Perl, Shell, PHP, and Java (registered trademark).

[0292] Furthermore, the program code for the software that implements the functions of the embodiment may be distributed via a network and stored in a storage means such as a computer's hard disk or memory, or in a storage medium such as a CD-RW or CD-R, and the computer's processor may read and execute the program code stored in the storage means or storage medium.

[0293] The functions realized by the components described herein may be implemented in a circuit or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the functions described herein. A processor is considered to be a circuit or processing circuitry, including transistors and other circuits. A processor may be a programmed processor that executes a program stored in memory.

[0294] In this specification, circuitry, unit, and means are hardware programmed to perform or execute the functions described herein. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to perform or execute the functions described herein.

[0295] When the hardware is a processor that is considered to be of the circuitry type, the circuitry, means, or unit is a combination of hardware and software used to configure the hardware and / or the processor.

[0296] While several embodiments of the present disclosure have been described above, these embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the gist of the invention. These embodiments and their modifications shall be included in the scope and gist of the invention, and shall also be included in the scope of the invention described in the claims and its equivalent range.

[0297] In the above embodiments, each device (terminal device, server, etc.) can also be regarded as an information processing device. That is, an aggregate of respective devices can be regarded as a single "information processing device", and the system may be formed as an aggregate of a plurality of devices. The method of distributing the plurality of functions required to implement the system according to the present embodiment for one or a plurality of pieces of hardware can be appropriately determined in view of the processing capability of each piece of hardware and / or the specifications required for the system, etc.

[0298] In the above embodiments, in the service provided by the server, a program to be executed on the terminal may be distributed by the server or the like, and the terminal may perform processing in a state where the program is installed, or the processing may be appropriately shared between the terminal and the server. For example, each process of the above embodiments can be performed on the terminal or on the server.

[0299] The above embodiments do not unreasonably limit the content of the present disclosure described in the claims. In addition, not all the constituent elements shown in the embodiments are necessarily essential constituent elements of the present disclosure. Each drawing is a schematic diagram and is not necessarily strictly illustrated.

[0300] Furthermore, while identification numbers are used as identification information for various objects in the above explanation, other types of identification information (for example, identifiers including letters or symbols) may also be used.

[0301] Furthermore, in the above explanation, when describing similar elements without distinction, a reference code (or a common code among reference codes) may be used, and when describing similar elements with distinction, the element's identification number (or reference code) may be used.

[0302] Furthermore, in the above explanation, the control lines and information lines shown are those deemed necessary for the explanation, and do not necessarily represent all control lines and information lines in the actual product. All components may be interconnected.

[0303] (Note) The details described in each of the above embodiments are noted below.

[0304] (Note 1) A system for generating robots, comprising: a requirements receiving unit that receives requests for robots from users in a format including natural language; an interpretation unit that defines physical or engineering constraints and an objective function for evaluating the robot's performance based on the requirements; a design generation unit that generates proposed hardware configurations for the robot based on the constraints; a simulation execution unit that performs physical calculations in a virtual space using the proposed hardware configurations and evaluates the robot's performance based on the objective function; an optimization execution unit that iteratively performs processing to optimize the proposed hardware configurations using the design generation unit and the simulation execution unit so as to improve the degree of achievement of the objective function based on the evaluation results from the simulation execution unit; and a result output unit that outputs optimized hardware configuration data obtained through the iterative processing by the optimization execution unit.

[0305] (Note 2) The design generation unit is the system described in Appendix 1, which further generates control policies corresponding to the proposed hardware configuration.

[0306] (Note 3) The system described in Appendix 2 includes a simulation execution unit that performs physical calculations using both the proposed hardware configuration and the control policy, an optimization execution unit that iteratively performs a process of simultaneously optimizing the proposed hardware configuration and the control policy, and a results output unit that outputs the optimized hardware configuration data and the optimized control policy.

[0307] (Note 4) The optimization execution unit is a system described in any of the appendices 1 to 3, which calculates gradient information using differentiable physical simulations and executes a gradient-based optimization algorithm.

[0308] (Note 5) The optimization execution unit generates a surrogate model that has learned the results of physical calculations, and accelerates the optimization process by using the surrogate model instead of the physical calculations performed by the simulation execution unit, as described in any of the appendices 1 to 4.

[0309] (Note 6) The robot is a group of robots consisting of multiple robots, and the objective function is defined to evaluate the overall mission achievement of the robot group, as described in any of the appendices 1 to 5.

[0310] (Note 7) The robot group is a heterogeneous group of robots with different functions or forms, and the optimization execution unit optimizes the overall configuration of the robot group, including the division of roles among the robots, as described in Appendix 6.

[0311] (Note 8) The system is a group of robots consisting of multiple robots, the objective function evaluates the overall mission achievement of the robot group, the simulation execution unit simulates an environment where external positioning information is blocked or limited, and the optimization execution unit optimizes the control policy and proposed hardware configuration, including sensor configuration, so that the individual robots in the group cooperatively estimate their own positions based on their relative position information and maintain the navigation of the entire robot group, as described in any of Appendix 3 to 7.

[0312] (Note 9) The system is a heterogeneous group of robots with different functions or forms, including a dedicated replenishment robot with an energy replenishment function, the objective function evaluates the mission achievement of the entire robot group, the optimization execution unit includes monitoring the remaining energy level of the entire robot group and mission continuity in the objective function, and optimizes a control policy including automatic return to the dedicated replenishment robot and energy exchange or replenishment sequences, and a proposed hardware configuration including a replenishment mechanism, as described in any of the appendices 3 to 8.

[0313] (Note 10) The system further includes a database that stores the specifications of available existing components, and the design generation unit refers to the database and combines existing components to generate hardware configuration proposals, as described in any of the appendices 1 to 9.

[0314] (Note 11) The requirements reception unit is a system described in any of Appendix 1 to 10, which has an interactive interface and progressively concretizes or quantifies requirements through dialogue with the user.

[0315] (Note 12) The constraints include an environmental model that simulates a specific environment, and the optimization execution unit optimizes robustness under that environment, as described in any of the appendices 1 to 11.

[0316] (Note 13) The simulation execution unit is a system described in any of the appendices 1 to 12, which automatically generates synthetic sensor data used for training a recognition AI model in a virtual space based on the proposed hardware configuration.

[0317] (Note 14) The results output unit is a system described in any of the appendices 1 to 13, which automatically generates and outputs manufacturing instruction data based on optimized hardware configuration data.

[0318] (Note 15) The system described in any of Appendix 1 to 14, further comprising a feedback unit that collects data obtained from actual operation and updates the parameters of the virtual space used by the simulation execution unit or the generation model used by the design generation unit based on said data.

[0319] (Note 16) A method for generating a robot to be executed by a computer having one or more computer processors, the method comprising: a process in which one or more computer processors receive a request from a user regarding the robot in a form including natural language; a process in which, based on the request, physical or engineering constraints and an objective function for evaluating the robot's performance are defined; a process in which, based on the constraints, a proposed hardware configuration for the robot is generated; a process in which physical calculations are performed in a virtual space using the proposed hardware configuration and the robot's performance is evaluated based on the objective function; a process in which, based on the results of the evaluation process, processes are iteratively executed using the generation process and the evaluation process to optimize the proposed hardware configuration so as to improve the degree of achievement of the objective function; and a process in which optimized hardware configuration data obtained through the iterative process is output.

[0320] (Note 17) A program executed by a computer having one or more computer processors, the program causing one or more computer processors to perform the following: a process of receiving requests from a user regarding a robot in a form including natural language; a process of defining physical or engineering constraints and an objective function for evaluating the robot's performance based on the requests; a process of generating proposed hardware configurations for the robot based on the constraints; a process of performing physical calculations in a virtual space using the proposed hardware configurations and evaluating the robot's performance based on the objective function; a process of iteratively executing processes to optimize the proposed hardware configurations using the generation process and the evaluation process so as to improve the degree of achievement of the objective function based on the results of the evaluation process; and a process of outputting optimized hardware configuration data obtained through the iterative process.

Claims

1. A system for generating robots, A requirements reception unit that receives requests regarding robots from users in a format that includes natural language, An interpreter defines physical or engineering constraints and an objective function for evaluating the robot's performance based on the aforementioned requirements. A design generation unit that generates a proposed hardware configuration for the robot based on the aforementioned constraints, A simulation execution unit that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the evaluation results from the simulation execution unit, an optimization execution unit iteratively performs processing to optimize the proposed hardware configuration using the design generation unit and the simulation execution unit so as to improve the degree of achievement of the objective function. A result output unit outputs optimized hardware configuration data obtained through iterative processing by the optimization execution unit, Equipped with, The aforementioned robot is a group of robots consisting of multiple robots, The objective function is defined to evaluate the overall mission achievement of the robot swarm in the system.

2. The aforementioned group of robots is a heterogeneous mixed group with different functions or forms. The system according to claim 1, wherein the optimization execution unit optimizes the overall configuration of the robot group, including the division of roles among the robots.

3. A system for generating robots, A requirements reception unit that receives requests regarding robots from users in a format that includes natural language, An interpreter defines physical or engineering constraints and an objective function for evaluating the robot's performance based on the aforementioned requirements. A design generation unit that generates a proposed hardware configuration for the robot based on the aforementioned constraints, A simulation execution unit that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the evaluation results from the simulation execution unit, an optimization execution unit iteratively performs processing to optimize the proposed hardware configuration using the design generation unit and the simulation execution unit so as to improve the degree of achievement of the objective function. A result output unit outputs optimized hardware configuration data obtained through iterative processing by the optimization execution unit, Equipped with, The design generation unit further generates a control policy corresponding to the proposed hardware configuration. The simulation execution unit executes the physical calculations using both the proposed hardware configuration and the control policy. The optimization execution unit iteratively performs a process to simultaneously optimize the proposed hardware configuration and the control policy. The result output unit outputs the optimized hardware configuration data and the optimized control policy. The aforementioned robot is a group of robots consisting of multiple robots, The aforementioned objective function evaluates the overall mission achievement level of the robot group, The aforementioned simulation execution unit simulates an environment in which external positioning information is blocked or restricted. The optimization execution unit optimizes the proposed hardware configuration, including the control policy and sensor configuration, so that the individual robots in the group collaboratively estimate their own positions based on their relative position information and maintain the navigation of the entire group of robots.

4. A system for generating robots, A requirements reception unit that receives requests regarding robots from users in a format that includes natural language, An interpreter defines physical or engineering constraints and an objective function for evaluating the robot's performance based on the aforementioned requirements. A design generation unit that generates a proposed hardware configuration for the robot based on the aforementioned constraints, A simulation execution unit that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the evaluation results from the simulation execution unit, an optimization execution unit iteratively performs processing to optimize the proposed hardware configuration using the design generation unit and the simulation execution unit so as to improve the degree of achievement of the objective function. A result output unit outputs optimized hardware configuration data obtained through iterative processing by the optimization execution unit, Equipped with, The design generation unit further generates a control policy corresponding to the proposed hardware configuration. The simulation execution unit executes the physical calculations using both the proposed hardware configuration and the control policy. The optimization execution unit iteratively performs a process to simultaneously optimize the proposed hardware configuration and the control policy. The result output unit outputs the optimized hardware configuration data and the optimized control policy. The aforementioned robots are a heterogeneous group of robots with different functions or forms, and include a dedicated replenishment robot that has an energy replenishment function. The aforementioned objective function evaluates the overall mission achievement level of the robot group, The optimization execution unit is a system that includes monitoring the remaining energy level of the entire robot group and mission continuity in its objective function, and optimizes the control policy, which includes an automatic return to the dedicated replenishment robot and an energy exchange or replenishment sequence, and the proposed hardware configuration, which includes a replenishment mechanism.

5. A system for generating robots, A requirements reception unit that receives requests regarding robots from users in a format that includes natural language, An interpreter defines physical or engineering constraints and an objective function for evaluating the robot's performance based on the aforementioned requirements. A design generation unit that generates a proposed hardware configuration for the robot based on the aforementioned constraints, A simulation execution unit that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the evaluation results from the simulation execution unit, an optimization execution unit iteratively performs processing to optimize the proposed hardware configuration using the design generation unit and the simulation execution unit so as to improve the degree of achievement of the objective function. A result output unit outputs optimized hardware configuration data obtained through iterative processing by the optimization execution unit, Equipped with, The aforementioned constraints include an environmental model that simulates a specific environment, The optimization execution unit is a system that optimizes robustness under the given environment.

6. The design generation unit further generates a control policy corresponding to the proposed hardware configuration. The system according to any one of claims 1, 2, or 5.

7. The simulation execution unit executes the physical calculations using both the proposed hardware configuration and the control policy. The optimization execution unit iteratively performs a process to simultaneously optimize the proposed hardware configuration and the control policy. The system according to claim 6, wherein the result output unit outputs the optimized hardware configuration data and the optimized control policy.

8. The optimization execution unit calculates gradient information using differentiable physical simulation and executes a gradient-based optimization algorithm, according to any one of claims 1 to 5.

9. The system according to any one of claims 1 to 5, wherein the optimization execution unit generates a surrogate model that has learned the results of the physical calculations, and speeds up the optimization process by using the surrogate model instead of the physical calculations performed by the simulation execution unit.

10. It also includes a database that stores the specifications of available existing components, The system according to any one of claims 1 to 5, wherein the design generation unit refers to the database and generates the hardware configuration proposal by combining the existing components.

11. The system according to any one of claims 1 to 5, wherein the requirements receiving unit is equipped with an interactive interface and progressively concretizes or quantifies the requirements through dialogue with the user.

12. The system according to any one of claims 1 to 5, wherein the simulation execution unit automatically generates synthetic sensor data used for training a recognition AI model in the virtual space based on the proposed hardware configuration.

13. The system according to any one of claims 1 to 5, wherein the result output unit automatically generates and outputs manufacturing instruction data based on the optimized hardware configuration data.

14. The system according to any one of claims 1 to 5, further comprising a feedback unit that collects data obtained from actual operation and updates the parameters of the virtual space used by the simulation execution unit or the generation model used by the design generation unit based on said data.

15. A method for generating a robot that is executed by a computer having one or more computer processors, The above method involves one or more computer processors, A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting optimized hardware configuration data obtained through the aforementioned iterative processing is performed. The aforementioned robot is a group of robots consisting of multiple robots, The objective function is defined as a method for evaluating the overall mission achievement of the robot swarm.

16. A method for generating a robot to be executed by a computer having one or more computer processors, The above method involves one or more computer processors, A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting optimized hardware configuration data obtained through the aforementioned iterative processing is performed. The aforementioned generation process further generates a control policy corresponding to the proposed hardware configuration, The evaluation process described above executes the physical calculations using both the proposed hardware configuration and the control policy. The iterative process described above iteratively performs a process that simultaneously optimizes the proposed hardware configuration and the control policy. The output process outputs the optimized hardware configuration data and the optimized control policy. The aforementioned robot is a group of robots consisting of multiple robots, The aforementioned objective function evaluates the overall mission achievement level of the robot group, The evaluation process described above simulates an environment where external positioning information is blocked or restricted. The iterative process described above is a method for optimizing the proposed hardware configuration, including the control policy and sensor configuration, so that the individual robots in the group collaboratively estimate their own positions based on their relative positional information and maintain the navigation of the entire group of robots.

17. A method for generating a robot that is executed by a computer having one or more computer processors, The above method involves one or more computer processors, A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting optimized hardware configuration data obtained through the aforementioned iterative processing is performed. The aforementioned generation process further generates a control policy corresponding to the proposed hardware configuration, The evaluation process described above executes the physical calculations using both the proposed hardware configuration and the control policy. The iterative process described above iteratively performs a process that simultaneously optimizes the proposed hardware configuration and the control policy. The output process outputs the optimized hardware configuration data and the optimized control policy. The aforementioned robots are a heterogeneous group of robots with different functions or forms, and include a dedicated replenishment robot that has an energy replenishment function. The aforementioned objective function evaluates the overall mission achievement level of the robot group, A method for optimizing a proposed hardware configuration, including an automatic return to the dedicated replenishment robot and an energy exchange or replenishment sequence, and including a replenishment mechanism, with the objective function being energy level monitoring and mission continuity for the entire robot group.

18. A method for generating a robot that is executed by a computer having one or more computer processors, The above method involves one or more computer processors, A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting optimized hardware configuration data obtained through the aforementioned iterative processing is performed. The aforementioned constraints include an environmental model that simulates a specific environment, The aforementioned iteratively executed process is a method for optimizing robustness under the given environment.

19. A program that runs on a computer having one or more computer processors, The program is configured on one or more computer processors. A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting the optimized hardware configuration data obtained through the aforementioned iterative processing is executed. The aforementioned robot is a group of robots consisting of multiple robots, The objective function is a program defined to evaluate the overall mission achievement level of the robot group.

20. A program that is executed by a computer having one or more computer processors, The program is configured on one or more computer processors. A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting the optimized hardware configuration data obtained through the aforementioned iterative processing is executed. The aforementioned generation process further generates a control policy corresponding to the proposed hardware configuration, The evaluation process described above executes the physical calculations using both the proposed hardware configuration and the control policy. The iterative process described above iteratively performs a process that simultaneously optimizes the proposed hardware configuration and the control policy. The output process outputs the optimized hardware configuration data and the optimized control policy. The aforementioned robot is a group of robots consisting of multiple robots, The aforementioned objective function evaluates the overall mission achievement level of the robot group, The evaluation process described above simulates an environment where external positioning information is blocked or restricted. The iteratively executed process is a program that optimizes the proposed hardware configuration, including the control policy and sensor configuration, so that the individual robots in the group collaboratively estimate their own positions based on their relative positional information and maintain the navigation of the entire group of robots.

21. A program that is executed by a computer having one or more computer processors, The program is configured on one or more computer processors. A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting the optimized hardware configuration data obtained through the aforementioned iterative processing is executed. The aforementioned generation process further generates a control policy corresponding to the proposed hardware configuration, The evaluation process described above executes the physical calculations using both the proposed hardware configuration and the control policy. The iterative process described above iteratively performs a process that simultaneously optimizes the proposed hardware configuration and the control policy. The output process outputs the optimized hardware configuration data and the optimized control policy. The aforementioned robots are a heterogeneous group of robots with different functions or forms, and include a dedicated replenishment robot that has an energy replenishment function. The aforementioned objective function evaluates the overall mission achievement level of the robot group, The iteratively executed process is a program that includes monitoring the remaining energy level of the entire robot group and mission continuity as its objective function, and optimizes the control policy, which includes an automatic return to the dedicated replenishment robot and an energy exchange or replenishment sequence, and the proposed hardware configuration, which includes a replenishment mechanism.

22. A program that is executed by a computer having one or more computer processors, The program is configured on one or more computer processors. A process that receives requests from users regarding the robot in a format that includes natural language, Based on the above requirements, a process is performed to define physical or engineering constraints and an objective function for evaluating the performance of the robot. A process for generating a proposed hardware configuration for the robot based on the aforementioned constraints, A process that performs physical calculations in a virtual space using the aforementioned hardware configuration and evaluates the performance of the robot based on the aforementioned objective function, Based on the results of the evaluation process, a process for optimizing the proposed hardware configuration is iteratively executed using the generation process and the evaluation process so as to improve the degree of achievement of the objective function. The process of outputting the optimized hardware configuration data obtained through the aforementioned iterative processing is executed. The aforementioned constraints include an environmental model that simulates a specific environment, The aforementioned iteratively executed process is a program that optimizes robustness under the given environment.

Images